[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BX7BVPKWSH1C6ES182SWGN":3,"skill-same:01M6BX7BVPKWSH1C6ES182SWGN":84},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M6BX7BVPKWSH1C6ES182SWGN","Using Content Driven Development",null,"Apply a Content Driven Development process to AEM Edge Delivery Services development. Use for all development tasks, including building new blocks, modifying existing blocks, making changes to core decoration functionality, etc.","ddttom\u002Fallaboutv2","ddttom","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1929848?v=4","01M6BX6X3SP9HFP5NVP5148SG2","Tom Cranstoun","01M6BX6X8H7Y9RE377QF088DYG",2,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fddttom\u002Fallaboutv2\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcontent-driven-development\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[32,33,5,34,35,36,37,38],"development","content","tasks","core","https","edge","services","2026-11-10 10:12:30",false,"---\nname: Using Content Driven Development\ndescription: Apply a Content Driven Development process to AEM Edge Delivery Services development. Use for all development tasks, including building new blocks, modifying existing blocks, making changes to core decoration functionality, etc.\n\nmx:\n  canonicalUri: https:\u002F\u002Fraw.githubusercontent.com\u002Fddttom\u002Fallaboutv2\u002Fmain\u002F.claude\u002Fskills\u002Fcontent-driven-development\u002FSKILL.md\n---\n\n# Using Content Driven Development (CDD)\n\nContent Driven Development is a mandatory process for AEM Edge Delivery Services development that prioritizes content and author needs over developer convenience. This skill orchestrates the development workflow to ensure code is built against real content with author-friendly content models.\n\n## Why Content-First Matters\n\n**Author needs come before developer needs.** When building for AEM Edge Delivery, authors are the primary users of the structures we create. Content models must be intuitive and easy to work with, even if that means more complex decoration code.\n\n**Efficiency through preparation.** Creating or identifying test content before coding provides:\n\n- **Immediate testing capability**: No need to stop development to create test content\n- **Better PR workflows**: Test content doubles as PR validation links for PSI checks\n- **Living documentation**: Test content often serves as author documentation and examples\n- **Fewer assumptions**: Real content reveals edge cases code-first approaches miss\n\n**NEVER start writing or modifying code without first identifying or creating the content you will use to test your changes.**\n\n## When to Apply This Skill\n\nApply Content Driven Development principles to ALL AEM development tasks:\n\n- ✅ Creating new blocks\n- ✅ Modifying existing blocks (structural or functional changes)\n- ✅ Changes to core decoration functionality\n- ✅ Bug fixes that require validation\n- ✅ Any code that affects how authors create or structure content\n\nSkip CDD only for:\n\n- ⚠️ Trivial CSS-only styling tweaks (but still identify test content for validation)\n- ⚠️ Configuration changes that don't affect authoring\n\nWhen in doubt, follow the CDD process. The time invested pays dividends in quality and efficiency.\n\n## Related Skills\n\nThis skill orchestrates other skills at the appropriate stages:\n\n- **content-modeling**: Invoked when new content models need to be designed or existing models modified\n- **building-blocks**: Invoked during implementation phase for block creation or modification\n- **testing-blocks**: Referenced during validation phase for comprehensive testing\n- **block-collection-and-party**: Used to find similar blocks and reference implementations\n\n## The Content-First Process\n\nFollow these phases in order. Do not skip steps.\n\n### Phase 0: Verify Working Directory\n\n**⚠️ CRITICAL: Before starting ANY Content Driven Development work:**\n\nVerify you're in the project root directory:\n\n```bash\npwd\n# Should output: \u002FUsers\u002Ftomcranstoun\u002FDocuments\u002FGitHub\u002FallaboutV2\n```\n\nIf you're in a subdirectory, navigate to project root:\n\n```bash\ncd \u002FUsers\u002Ftomcranstoun\u002FDocuments\u002FGitHub\u002FallaboutV2\n```\n\nVerify project markers exist:\n\n```bash\nls -la | grep -E \"(\\.claude|blocks|package\\.json|CLAUDE\\.md)\"\n```\n\nAll four must exist. If not, you're in the wrong directory and must navigate to project root before proceeding.\n\n### Phase 1: Content Discovery and Modeling\n\nThe first phase establishes what content you're working with and ensures the content model is author-friendly.\n\n#### Step 1.1: Determine Content Availability\n\n**For new blocks:**\n\nSkip to Step 1.2 (Content Model Design). Searching for content that doesn't exist is a waste of time.\n\n**For modifications to existing blocks:**\n\nAsk the user: \"Does content using this block already exist that we can use for testing?\"\n\n- **YES** → Identify existing content to test against\n  - Use the `scripts\u002Ffind-block-content.js` script to search for pages containing the block\n  - Or ask the user: \"What are the path(s) to page(s) with this block?\"\n  - Validate the content loads correctly in your local dev environment\n  - Proceed to Phase 2 (skip content modeling if structure isn't changing)\n\n- **NO existing content** → Proceed to Step 1.2\n\n#### Step 1.2: Content Model Design\n\n**REQUIRED for:**\n\n- All new blocks\n- Structural changes to existing blocks (adding\u002Fremoving\u002Fmodifying sections, variants, or the authoring structure)\n\n**Ask the user:**\n\"This requires a new content model. Would you like me to use the content-modeling skill to design an author-friendly content model now?\"\n\n- **YES** → Invoke the **content-modeling** skill\n  - Follow the content modeling process completely\n  - Return to this skill when content model is defined\n  - Proceed to Step 1.3\n\n- **NO** → The user may want to define it themselves\n  - Ask: \"Please describe the content structure authors will use\"\n  - Document their description for reference\n  - Proceed to Step 1.3\n\n#### Step 1.3: Content Creation\n\nOnce the content model is defined (from Step 1.2), you need test content.\n\n**Ask the user:**\n\"We need test content for development and validation. This content will serve multiple purposes:\n\n- Testing during development\n- PR validation link for PSI checks\n- Author documentation and examples\n\nWould you like to:\n\n1. Create this content in the CMS now (Google Drive\u002FSharePoint\u002FDA\u002FUniversal Editor)\n2. Create temporary local HTML files for testing (will need CMS content before PR)\"\n\n**Option 1: CMS Content (Recommended)**\n\n- Guide the user through creating content in their CMS\n- Wait for user confirmation that content is created and published\n- Get the content URL(s) from the user\n- Validate content loads in local dev environment\n- Proceed to Phase 2\n\n**Option 2: Local HTML Files (Temporary)**\n\n- Create HTML file(s) in `drafts\u002F` folder matching the content model structure\n- Reference the [HTML Structure Guide](resources\u002Fhtml-structure.md) for proper file format\n- Remind user: \"Restart your dev server with: `aem up --html-folder drafts`\"\n- Note: \"You will need to create actual CMS content before raising a PR\"\n- Proceed to Phase 2\n\n##### Making Test Content Serve as Author Documentation\n\nTest content can often double as author-facing documentation, saving time and keeping documentation current. Consider this when creating test content:\n\n**When test content IS sufficient as author documentation:**\n\n- The block is straightforward with clear patterns\n- Test content shows all variants and use cases\n- Content demonstrates best practices authors should follow\n- Examples are realistic and relatable to actual use cases\n\n**When separate author documentation is needed:**\n\n- Block has complex configuration or many variants requiring explanation\n- There are edge cases or gotchas authors need to understand\n- Project standards require formal documentation in a specific location\u002Fformat\n- Block behavior isn't self-evident from examples alone\n\n**Structuring test content to serve both purposes:**\n\n1. **Create comprehensive examples**: Show all variants, edge cases, and common patterns\n2. **Use realistic content**: Avoid \"lorem ipsum\" or technical placeholders\n3. **Demonstrate best practices**: Structure content the way authors should\n4. **Consider location**: Place content where it can serve as documentation\n   - Sidekick Library projects: Consider creating in `\u002Ftools\u002Fsidekick\u002Flibrary\u002F` or appropriate library location\n   - Document Authoring: Place in DA Library structure\n   - Simple documentation: Use `\u002Fdrafts\u002Fdocs\u002F` or `\u002Fdrafts\u002Flibrary\u002F`\n   - Universal Editor: Follow project-specific documentation patterns\n\n**Ask the user about documentation approach:**\n\"Should this test content also serve as author documentation? If so, we can structure it accordingly and place it in an appropriate location (e.g., `\u002Fdrafts\u002Flibrary\u002F{block-name}` or your project's library system).\"\n\nIf yes, guide content creation with documentation in mind. If no, proceed with test-focused content and note that author documentation will be needed later.\n\n### Phase 2: Implementation\n\n**CRITICAL: Do not begin Phase 2 until you have confirmed test content exists and is accessible.**\n\nNow that test content exists, proceed with implementation:\n\n#### For Block Development\n\nInvoke the **building-blocks** skill:\n\n- Provide the skill with the content model and test content URL(s)\n- Follow the building-blocks process for implementation\n- Return to this skill when implementation is complete\n- Proceed to Phase 3\n\n#### For Core Functionality Changes\n\nFollow standard development practices:\n\n- Make changes to scripts, styles, or configuration\n- Test against the identified content throughout development\n- Ensure changes don't break existing blocks or content models\n- Proceed to Phase 3\n\n### Phase 3: Validation\n\nThe final phase ensures the implementation works correctly with real content.\n\n#### Step 3.1: Test with Real Content\n\n**Mandatory testing:**\n\n- ✅ View test content in local dev environment\n- ✅ Verify all variants render correctly\n- ✅ Check responsive behavior (mobile, tablet, desktop)\n- ✅ Test edge cases revealed by the actual content\n- ✅ Validate accessibility basics (keyboard navigation, screen reader friendly)\n\n#### Step 3.2: Run Quality Checks\n\n**Required before considering implementation complete:**\n\n```bash\nnpm run lint\n```\n\nIf linting fails, fix issues with:\n\n```bash\nnpm run lint:fix\n```\n\n#### Step 3.3: Comprehensive Testing\n\n**The testing-blocks skill is automatically invoked by building-blocks** for block development.\n\nFor other code changes, or for additional testing guidance, invoke the **testing-blocks** skill which provides:\n\n- Unit testing strategies for logic-heavy utilities\n- Browser testing with Playwright\u002FPuppeteer\n- Linting and code quality checks\n- Performance validation with GitHub checks\n- Guidance on keeper vs throwaway tests\n\n#### Step 3.4: PR Preparation\n\n**Before raising a PR, ensure:**\n\n- ✅ Test content exists in the CMS (not just local HTML)\n- ✅ Test content URL is accessible for PSI checks\n- ✅ All linting passes\n- ✅ Author documentation is updated (if applicable)\n\nThe test content URL will be used as the PR validation link.\n\n## Anti-Patterns to Avoid\n\n**Common mistakes:**\n\n- ❌ Starting with code before understanding the content model\n- ❌ Making assumptions about content structure without seeing real examples\n- ❌ Creating developer-friendly but author-hostile content models\n- ❌ Skipping content creation \"to save time\" (costs more time later)\n- ❌ Testing against imagined content instead of real content\n- ❌ Treating test content creation as separate from development workflow\n\n## Workflow Summary\n\n**Quick reference for the CDD process:**\n\n```\n1. CONTENT DISCOVERY\n   └─ Existing content? → Use it\n   └─ New block\u002Fstructure? → Design content model → Create test content\n\n2. IMPLEMENTATION\n   └─ Build code against the real content model\n   └─ Test continuously with actual content\n\n3. VALIDATION\n   └─ Comprehensive testing with test content\n   └─ Quality checks (linting, accessibility)\n   └─ PR preparation with test URL\n\nKEY RULE: Never proceed to implementation without test content\n```\n\n## Scripts and Tools\n\n### Finding Existing Block Content\n\nUse the provided script to search for pages containing a specific block:\n\n```bash\n# Search on localhost (default)\nnode .claude\u002Fskills\u002Fcontent-driven-development\u002Fscripts\u002Ffind-block-content.js \u003Cblock-name>\n\n# Search for specific variant\nnode .claude\u002Fskills\u002Fcontent-driven-development\u002Fscripts\u002Ffind-block-content.js \u003Cblock-name> localhost:3000 \u003Cvariant>\n\n# Search on live site\nnode .claude\u002Fskills\u002Fcontent-driven-development\u002Fscripts\u002Ffind-block-content.js \u003Cblock-name> main--repo--owner.aem.live\n\n# Search on preview with variant\nnode .claude\u002Fskills\u002Fcontent-driven-development\u002Fscripts\u002Ffind-block-content.js \u003Cblock-name> main--repo--owner.aem.page \u003Cvariant>\n```\n\n**Examples:**\n\n```bash\nnode .claude\u002Fskills\u002Fcontent-driven-development\u002Fscripts\u002Ffind-block-content.js hero\nnode .claude\u002Fskills\u002Fcontent-driven-development\u002Fscripts\u002Ffind-block-content.js hero localhost:3000 dark\nnode .claude\u002Fskills\u002Fcontent-driven-development\u002Fscripts\u002Ffind-block-content.js cards main--site--owner.aem.live three-up\n```\n\nThis script queries the site's query-index to find all pages containing the specified block (and optional variant) and returns their URLs. The script uses proper DOM parsing to accurately identify blocks.\n\n## Integration with Other Skills\n\nThis skill acts as the orchestrator for AEM development workflows:\n\n**At Content Modeling stage:**\n→ Invoke **content-modeling** skill for author-friendly design\n\n**At Implementation stage:**\n→ Invoke **building-blocks** skill for block development\n→ Reference **block-collection-and-party** skill for patterns\n\n**At Validation stage:**\n→ Reference **testing-blocks** skill for comprehensive testing\n\nFollowing this orchestration ensures all development follows content-first principles.\n","# Using Content Driven Development (CDD)\n\nContent Driven Development is a mandatory process for AEM Edge Delivery Services development that prioritizes content and author needs over developer convenience. This skill orchestrates the development workflow to ensure code is built against real content with author-friendly content models.\n\n## Why Content-First Matters\n\n**Author needs come before developer needs.** When building for AEM Edge Delivery, authors are the primary users of the structures we create. Content models must be intuitive and easy to work with, even if that means more complex decoration code.\n\n**Efficiency through preparation.** Creating or identifying test content before coding provides:\n\n- **Immediate testing capability**: No need to stop development to create test content\n- **Better PR workflows**: Test content doubles as PR validation links for PSI checks\n- **Living documentation**: Test content often serves as author documentation and examples\n- **Fewer assumptions**: Real content reveals edge cases code-first approaches miss\n\n**NEVER start writing or modifying code without first identifying or creating the content you will use to test your changes.**\n\n## When to Apply This Skill\n\nApply Content Driven Development principles to ALL AEM development tasks:\n\n- ✅ Creating new blocks\n- ✅ Modifying existing blocks (structural or functional changes)\n- ✅ Changes to core decoration functionality\n- ✅ Bug fixes that require validation\n- ✅ Any code that affects how authors create or structure content\n\nSkip CDD only for:\n\n- ⚠️ Trivial CSS-only styling tweaks (but still identify test content for validation)\n- ⚠️ Configuration changes that don't affect authoring\n\nWhen in doubt, follow the CDD process. The time invested pays dividends in quality and efficiency.\n\n## Related Skills\n\nThis skill orchestrates other skills at the appropriate stages:\n\n- **content-modeling**: Invoked when new content models need to be designed or existing models modified\n- **building-blocks**: Invoked during implementation phase for block creation or modification\n- **testing-blocks**: Referenced during validation phase for comprehensive testing\n- **block-collection-and-party**: Used to find similar blocks and reference implementations\n\n## The Content-First Process\n\nFollow these phases in order. Do not skip steps.\n\n### Phase 0: Verify Working Directory\n\n**⚠️ CRITICAL: Before starting ANY Content Driven Development work:**\n\nVerify you're in the project root directory:\n\n```bash\npwd\n# Should output: \u002FUsers\u002Ftomcranstoun\u002FDocuments\u002FGitHub\u002FallaboutV2\n```\n\nIf you're in a subdirectory, navigate to project root:\n\n```bash\ncd \u002FUsers\u002Ftomcranstoun\u002FDocuments\u002FGitHub\u002FallaboutV2\n```\n\nVerify project markers exist:\n\n```bash\nls -la | grep -E \"(\\.claude|blocks|package\\.json|CLAUDE\\.md)\"\n```\n\nAll four must exist. If not, you're in the wrong directory and must navigate to project root before proceeding.\n\n### Phase 1: Content Discovery and Modeling\n\nThe first phase establishes what content you're working with and ensures the content model is author-friendly.\n\n#### Step 1.1: Determine Content Availability\n\n**For new blocks:**\n\nSkip to Step 1.2 (Content Model Design). Searching for content that doesn't exist is a waste of time.\n\n**For modifications to existing blocks:**\n\nAsk the user: \"Does content using this block already exist that we can use for testing?\"\n\n- **YES** → Identify existing content to test against\n  - Use the `scripts\u002Ffind-block-content.js` script to search for pages containing the block\n  - Or ask the user: \"What are the path(s) to page(s) with this block?\"\n  - Validate the content loads correctly in your local dev environment\n  - Proceed to Phase 2 (skip content modeling if structure isn't changing)\n\n- **NO existing content** → Proceed to Step 1.2\n\n#### Step 1.2: Content Model Design\n\n**REQUIRED for:**\n\n- All new blocks\n- Structural changes to existing blocks (adding\u002Fremoving\u002Fmodifying sections, variants, or the authoring structure)\n\n**Ask the user:**\n\"This requires a new content model. Would you like me to use the content-modeling skill to design an author-friendly content model now?\"\n\n- **YES** → Invoke the **content-modeling** skill\n  - Follow the content modeling process completely\n  - Return to this skill when content model is defined\n  - Proceed to Step 1.3\n\n- **NO** → The user may want to define it themselves\n  - Ask: \"Please describe the content structure authors will use\"\n  - Document their description for reference\n  - Proceed to Step 1.3\n\n#### Step 1.3: Content Creation\n\nOnce the content model is defined (from Step 1.2), you need test content.\n\n**Ask the user:**\n\"We need test content for development and validation. This content will serve multiple purposes:\n\n- Testing during development\n- PR validation link for PSI checks\n- Author documentation and examples\n\nWould you like to:\n\n1. Create this content in the CMS now (Google Drive\u002FSharePoint\u002FDA\u002FUniversal Editor)\n2. Create temporary local HTML files for testing (will need CMS content before PR)\"\n\n**Option 1: CMS Content (Recommended)**\n\n- Guide the user through creating content in their CMS\n- Wait for user confirmation that content is created and published\n- Get the content URL(s) from the user\n- Validate content loads in local dev environment\n- Proceed to Phase 2\n\n**Option 2: Local HTML Files (Temporary)**\n\n- Create HTML file(s) in `drafts\u002F` folder matching the content model structure\n- Reference the [HTML Structure Guide](resources\u002Fhtml-structure.md) for proper file format\n- Remind user: \"Restart your dev server with: `aem up --html-folder drafts`\"\n- Note: \"You will need to create actual CMS content before raising a PR\"\n- Proceed to Phase 2\n\n##### Making Test Content Serve as Author Documentation\n\nTest content can often double as author-facing documentation, saving time and keeping documentation current. Consider this when creating test content:\n\n**When test content IS sufficient as author documentation:**\n\n- The block is straightforward with clear patterns\n- Test content shows all variants and use cases\n- Content demonstrates best practices authors should follow\n- Examples are realistic and relatable to actual use cases\n\n**When separate author documentation is needed:**\n\n- Block has complex configuration or many variants requiring explanation\n- There are edge cases or gotchas authors need to understand\n- Project standards require formal documentation in a specific location\u002Fformat\n- Block behavior isn't self-evident from examples alone\n\n**Structuring test content to serve both purposes:**\n\n1. **Create comprehensive examples**: Show all variants, edge cases, and common patterns\n2. **Use realistic content**: Avoid \"lorem ipsum\" or technical placeholders\n3. **Demonstrate best practices**: Structure content the way authors should\n4. **Consider location**: Place content where it can serve as documentation\n   - Sidekick Library projects: Consider creating in `\u002Ftools\u002Fsidekick\u002Flibrary\u002F` or appropriate library location\n   - Document Authoring: Place in DA Library structure\n   - Simple documentation: Use `\u002Fdrafts\u002Fdocs\u002F` or `\u002Fdrafts\u002Flibrary\u002F`\n   - Universal Editor: Follow project-specific documentation patterns\n\n**Ask the user about documentation approach:**\n\"Should this test content also serve as author documentation? If so, we can structure it accordingly and place it in an appropriate location (e.g., `\u002Fdrafts\u002Flibrary\u002F{block-name}` or your project's library system).\"\n\nIf yes, guide content creation with documentation in mind. If no, proceed with test-focused content and note that author documentation will be needed later.\n\n### Phase 2: Implementation\n\n**CRITICAL: Do not begin Phase 2 until you have confirmed test content exists and is accessible.**\n\nNow that test content exists, proceed with implementation:\n\n#### For Block Development\n\nInvoke the **building-blocks** skill:\n\n- Provide the skill with the content model and test content URL(s)\n- Follow the building-blocks process for implementation\n- Return to this skill when implementation is complete\n- Proceed to Phase 3\n\n#### For Core Functionality Changes\n\nFollow standard development practices:\n\n- Make changes to scripts, styles, or configuration\n- Test against the identified content throughout development\n- Ensure changes don't break existing blocks or content models\n- Proceed to Phase 3\n\n### Phase 3: Validation\n\nThe final phase ensures the implementation works correctly with real content.\n\n#### Step 3.1: Test with Real Content\n\n**Mandatory testing:**\n\n- ✅ View test content in local dev environment\n- ✅ Verify all variants render correctly\n- ✅ Check responsive behavior (mobile, tablet, desktop)\n- ✅ Test edge cases revealed by the actual content\n- ✅ Validate accessibility basics (keyboard navigation, screen reader friendly)\n\n#### Step 3.2: Run Quality Checks\n\n**Required before considering implementation complete:**\n\n```bash\nnpm run lint\n```\n\nIf linting fails, fix issues with:\n\n```bash\nnpm run lint:fix\n```\n\n#### Step 3.3: Comprehensive Testing\n\n**The testing-blocks skill is automatically invoked by building-blocks** for block development.\n\nFor other code changes, or for additional testing guidance, invoke the **testing-blocks** skill which provides:\n\n- Unit testing strategies for logic-heavy utilities\n- Browser testing with Playwright\u002FPuppeteer\n- Linting and code quality checks\n- Performance validation with GitHub checks\n- Guidance on keeper vs throwaway tests\n\n#### Step 3.4: PR Preparation\n\n**Before raising a PR, ensure:**\n\n- ✅ Test content exists in the CMS (not just local HTML)\n- ✅ Test content URL is accessible for PSI checks\n- ✅ All linting passes\n- ✅ Author documentation is updated (if applicable)\n\nThe test content URL will be used as the PR validation link.\n\n## Anti-Patterns to Avoid\n\n**Common mistakes:**\n\n- ❌ Starting with code before understanding the content model\n- ❌ Making assumptions about content structure without seeing real examples\n- ❌ Creating developer-friendly but author-hostile content models\n- ❌ Skipping content creation \"to save time\" (costs more time later)\n- ❌ Testing against imagined content instead of real content\n- ❌ Treating test content creation as separate from development workflow\n\n## Workflow Summary\n\n**Quick reference for the CDD process:**\n\n```\n1. CONTENT DISCOVERY\n   └─ Existing content? → Use it\n   └─ New block\u002Fstructure? → Design content model → Create test content\n\n2. IMPLEMENTATION\n   └─ Build code against the real content model\n   └─ Test continuously with actual content\n\n3. VALIDATION\n   └─ Comprehensive testing with test content\n   └─ Quality checks (linting, accessibility)\n   └─ PR preparation with test URL\n\nKEY RULE: Never proceed to implementation without test content\n```\n\n## Scripts and Tools\n\n### Finding Existing Block Content\n\nUse the provided script to search for pages containing a specific block:\n\n```bash\n# Search on localhost (default)\nnode .claude\u002Fskills\u002Fcontent-driven-development\u002Fscripts\u002Ffind-block-content.js \u003Cblock-name>\n\n# Search for specific variant\nnode .claude\u002Fskills\u002Fcontent-driven-development\u002Fscripts\u002Ffind-block-content.js \u003Cblock-name> localhost:3000 \u003Cvariant>\n\n# Search on live site\nnode .claude\u002Fskills\u002Fcontent-driven-development\u002Fscripts\u002Ffind-block-content.js \u003Cblock-name> main--repo--owner.aem.live\n\n# Search on preview with variant\nnode .claude\u002Fskills\u002Fcontent-driven-development\u002Fscripts\u002Ffind-block-content.js \u003Cblock-name> main--repo--owner.aem.page \u003Cvariant>\n```\n\n**Examples:**\n\n```bash\nnode .claude\u002Fskills\u002Fcontent-driven-development\u002Fscripts\u002Ffind-block-content.js hero\nnode .claude\u002Fskills\u002Fcontent-driven-development\u002Fscripts\u002Ffind-block-content.js hero localhost:3000 dark\nnode .claude\u002Fskills\u002Fcontent-driven-development\u002Fscripts\u002Ffind-block-content.js cards main--site--owner.aem.live three-up\n```\n\nThis script queries the site's query-index to find all pages containing the specified block (and optional variant) and returns their URLs. The script uses proper DOM parsing to accurately identify blocks.\n\n## Integration with Other Skills\n\nThis skill acts as the orchestrator for AEM development workflows:\n\n**At Content Modeling stage:**\n→ Invoke **content-modeling** skill for author-friendly design\n\n**At Implementation stage:**\n→ Invoke **building-blocks** skill for block development\n→ Reference **block-collection-and-party** skill for patterns\n\n**At Validation stage:**\n→ Reference **testing-blocks** skill for comprehensive testing\n\nFollowing this orchestration ensures all development follows content-first principles.\n",{"mx":44,"name":5,"description":7},{"canonicalUri":45},"https:\u002F\u002Fraw.githubusercontent.com\u002Fddttom\u002Fallaboutv2\u002Fmain\u002F.claude\u002Fskills\u002Fcontent-driven-development\u002FSKILL.md","main","94cac13323e3a1686d255ad6a4455bc0d2272b8c",".claude\u002Fskills\u002Fcontent-driven-development",0,"https:\u002F\u002Fgithub.com\u002Fddttom\u002Fallaboutv2","https:\u002F\u002Fgithub.com\u002Fddttom","Independent Technology Consultant at DIGITAL DOMAIN TECHNOLOGIES LIMITED","2026-11-03 20:58:57",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add ddttom\u002Fallaboutv2 --skill \"Using Content Driven Development\"",{"tool":60,"command":61},"bunx","bunx skills add ddttom\u002Fallaboutv2 --skill \"Using Content Driven Development\"",{"tool":63,"command":64},"pnpm","pnpm dlx skills add ddttom\u002Fallaboutv2 --skill \"Using Content Driven Development\"","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fddttom\u002Fallaboutv2\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcontent-driven-development\u002FSKILL.md",true,[68,74,80],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"resources\u002Fhtml-structure.md","REFERENCE","参考文档",14887,"https:\u002F\u002Fgithub.com\u002Fddttom\u002Fallaboutv2\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcontent-driven-development\u002Fresources\u002Fhtml-structure.md",{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"scripts\u002Ffind-block-content.js","SCRIPT","脚本",8063,"https:\u002F\u002Fgithub.com\u002Fddttom\u002Fallaboutv2\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcontent-driven-development\u002Fscripts\u002Ffind-block-content.js",{"path":81,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":82,"sourceHtmlUrl":83},"scripts\u002Fpackage.json",23,"https:\u002F\u002Fgithub.com\u002Fddttom\u002Fallaboutv2\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcontent-driven-development\u002Fscripts\u002Fpackage.json",[85,109,126,144,154,172],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":95,"publishedAt":39},"01M6BX9XTV2PTCX7CC2DS4NC9N","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","https:\u002F\u002Fgithub.com\u002Fddttom\u002Fallaboutv2\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[91,92],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":93,"categoryName":94,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[96,97,98,99,100,101,102,103,104,105,106,107,108],"testing","webapp testing","frontend","screenshots","playwright","web","debugging","toolkit","browser","license","ui","logs","applications",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":118,"publishedAt":39},"01M6BX9V12H31MGZ0YYXZJ6R05","theme-factory","Toolkit for styling artifacts with a theme. These artifacts can be slides, docs, reportings, HTML landing pages, etc. There are 10 pre-set themes with colors\u002Ffonts that you can apply to any artifact that has been creating, or can generate a new theme on-the-fly.","https:\u002F\u002Fgithub.com\u002Fddttom\u002Fallaboutv2\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftheme-factory\u002FSKILL.md",[115],{"categoryNo":116,"categoryName":117,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[119,120,105,121,103,122,123,124,125],"theme factory","artifacts","generate","SET","docs","fly","slides",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":134,"publishedAt":39},"01M6BX9QWNATVKD88BNQHVZ92A","Testing Blocks","Guide for testing code changes in AEM Edge Delivery projects including blocks, scripts, and styles. Use this skill after making code changes and before opening a pull request to validate functionality. Covers unit testing for utilities and logic, browser testing with Playwright\u002FPuppeteer, linting, performance validation, and guidance on which tests to maintain vs use as throwaway validation.","https:\u002F\u002Fgithub.com\u002Fddttom\u002Fallaboutv2\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftesting-blocks\u002FSKILL.md",[132,133],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[96,128,135,37,104,36,136,100,137,138,139,140,141,142,143],"projects","performance","validate","pull request","code","validation","puppeteer","pull","browser testing",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":151,"publishedAt":39},"01M6BX9PFJ1F4QSAXHGVPB4MB0","template-skill","Replace with description of the skill and when Claude should use it.","https:\u002F\u002Fgithub.com\u002Fddttom\u002Fallaboutv2\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftemplate-skill\u002FSKILL.md",[150],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[152,153,36],"template skill","template",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":166,"publishedAt":39},"01M6BX9K7A0AJM3RQJ70G3XNX9","slack-gif-creator","Toolkit for creating animated GIFs optimized for Slack, with validators for size constraints and composable animation primitives. This skill applies when users request animated GIFs or emoji animations for Slack from descriptions like \"make me a GIF for Slack of X doing Y\".","https:\u002F\u002Fgithub.com\u002Fddttom\u002Fallaboutv2\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fslack-gif-creator\u002FSKILL.md",[160,163],{"categoryNo":161,"categoryName":162,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000005","邮件与沟通",{"categoryNo":164,"categoryName":165,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[167,168,169,170,103,105,171],"slack","slack gif creator","constraints","composable","Animation",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":183,"publishedAt":39},"01M6BX9G4PJA81VK9ZNQENT3B2","skill-developer","Create and manage Claude Code skills following Anthropic best practices. Use when creating new skills, modifying skill-rules.json, understanding trigger patterns, working with hooks, debugging skill activation, or implementing progressive disclosure. Covers skill structure, YAML frontmatter, trigger types (keywords, intent patterns, file paths, content patterns), enforcement levels (block, suggest, warn), hook mechanisms (UserPromptSubmit, PreToolUse), session tracking, and the 500-line rule.","https:\u002F\u002Fgithub.com\u002Fddttom\u002Fallaboutv2\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fskill-developer\u002FSKILL.md",[178,179,180],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":181,"categoryName":182,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师",[184,185,102,186,139,187,33,36,188,189,190,191],"skill developer","developer","create","best practices","file","yaml","json","claude code skills"]