/content-driven-development

name: content-driven-development
description: Apply a Content Driven Development process to AEM Edge Delivery Services development. Use for ALL code changes - new blocks, block modifications, CSS styling, bug fixes, core functionality (scripts.js, styles, etc.), or any JavaScript/CSS work that needs validation.
license: Apache-2.0
metadata:
  version: "2.0.1"

Content Driven Development (CDD)

Orchestrate the Content Driven Development workflow for AEM Edge Delivery Services. This workflow ensures code is built against real content with author-friendly content models.

**CRITICAL: Never start writing or modifying code without first identifying or creating the content you will use to test your changes.**

When to Use This Skill

Use CDD for ALL AEM development tasks:

• ✅ Creating new blocks
• ✅ Modifying existing blocks (structural or functional changes)
• ✅ Changes to core decoration functionality
• ✅ Bug fixes that require validation
• ✅ Any code that affects how authors create or structure content

Do NOT use for:

• Documentation-only changes
• Configuration changes that don't affect authoring
• Research tasks that don't require making any code changes yet

Philosophy

Content Driven Development prioritizes creating or identifying test content before writing code. This ensures:

• Code is built against real content
• Author-friendly content models
• Validation throughout development

**Optional: Understanding CDD Principles**

Read [references/cdd-philosophy.md](references/cdd-philosophy.md) if:

• User asks "why" questions about content-first approach
• You need to understand reasoning behind CDD decisions
• You're unsure whether to prioritize author vs developer experience

Otherwise: Follow the workflow steps below

Step 0: Create TodoList

**FIRST STEP:** Use the TodoWrite tool to create a todo list with the following 8 tasks:

1. **Start dev server** (if not running)

• Success: Dev server running, can access http://localhost:3000

2. **Analyze & plan**

• Success: Clear understanding documented + acceptance criteria defined

3. **Design content model**

• Success: Content structure documented and validated

4. **Identify/create test content**

• Success: Test content accessible covering all scenarios

5. **Implement**

• Success: Functionality works across all viewports

6. **Lint & test**

• Success: All checks pass

7. **Final validation**

• Success: All acceptance criteria met, everything works

8. **Ship it**

• Success: PR created with preview link for validation

**Mark todo complete when:** Todo list created with all 8 tasks

---

Step 1: Start Dev Server

**Check if dev server is running:**

curl -s -o /dev/null -w "%{http_code}" http://localhost:3000

Expected: `200` (server running) or connection error (server not running)

**If not running, start it:**

aem up --no-open --forward-browser-logs

**Notes:**

• Run in background if possible (dev server needs to stay running)
• Requires AEM CLI installed globally: `npm install -g @adobe/aem-cli`
• Alternative: `npx -y @adobe/aem-cli up --no-open --forward-browser-logs`

**IMPORTANT:** Check the command output for errors. Common issues:

• Port 3000 already in use
• AEM CLI not installed
• Configuration errors

**After starting, verify it's running:**

curl -s -o /dev/null -w "%{http_code}" http://localhost:3000

Expected: `200`

**Success criteria:**

• ✅ Dev server running
• ✅ http://localhost:3000 returns 200
• ✅ No errors in server startup output

**Mark todo complete when:** Dev server confirmed running and accessible

---

Step 2: Analyze & Plan

**Invoke:** analyze-and-plan skill

**Provide:**

• Task description from user
• Screenshots, design files, or existing URLs to match design from (if available)

**The analyze-and-plan skill will:**

• Guide you through task-specific analysis
• Help define acceptance criteria
• Optionally analyze visual designs/mockups if provided
• Create documented analysis for reference

**Success criteria:**

• ✅ Requirements analyzed
• ✅ Acceptance criteria defined
• ✅ Analysis documented to file for later steps

**Mark todo complete when:** Analysis documented and acceptance criteria defined

---

Step 3: Design Content Model

**Skip if:** CSS-only changes that don't affect content structure

**Invoke:** content-modeling skill

**Provide:**

• Analysis from Step 2 (content requirements, author inputs)
• Block name and purpose

**The content-modeling skill will:**

• Design table structure (rows, columns, semantic formatting)
• Validate against best practices (4 cells/row, semantic formatting)
• Document content model for authors

**Success criteria:**

• ✅ Content model designed (table structure defined)
• ✅ Validated against best practices
• ✅ Content model documented

**Mark todo complete when:** Content model designed and documented

---

Step 4: Identify/Create Test Content

**Goal:** End this step with accessible test content URL(s) covering all test scenarios

**Choose the best path based on your situation:**

---

Option A: User Provided Test URL(s)

**When to use:** User already has content and provided URL(s)

**What to do:** 1. Validate URL loads: `curl -s -o /dev/null -w "%{http_code}" http://localhost:3000/path` 2. Expected: `200` status 3. Document URL(s) 4. Mark complete

---

Option B: New Block (No Existing Content)

**When to use:** Building a brand new block that doesn't exist yet

**What to do:** 1. Skip search (nothing exists yet to find) 2. Create test content using one of these approaches:

**Approach 1: CMS Content (Recommended)** 1. Ask user to create content in their CMS (Google Drive/SharePoint/DA/Universal Editor) 2. Provide content model from Step 3 as reference 3. Wait for user to provide URL(s) 4. Validate: `curl -s -o /dev/null -w "%{http_code}" http://localhost:3000/path` 5. Expected: `200` status

> **Using DA:** If you need to push HTML content programmatically to DA (rather