Using Content Driven Development by adobe/helix-website
npx skills add https://github.com/adobe/helix-website --skill 'Using Content Driven Development'内容驱动开发是 AEM Edge Delivery Services 开发的强制性流程,它优先考虑内容和作者需求,而非开发者的便利性。此技能协调开发工作流,确保代码基于真实内容构建,并采用对作者友好的内容模型。
作者需求优先于开发者需求。 在为 AEM Edge Delivery 构建时,作者是我们所创建结构的主要使用者。内容模型必须直观且易于使用,即使这意味着需要编写更复杂的装饰代码。
通过准备提高效率。 在编码前创建或识别测试内容可以提供:
切勿在未首先识别或创建用于测试更改的内容之前,开始编写或修改代码。
将内容驱动开发原则应用于所有 AEM 开发任务:
仅在以下情况下可跳过 CDD:
如有疑问,请遵循 CDD 流程。投入的时间将在质量和效率上获得回报。
此技能在适当阶段协调其他技能:
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
按顺序遵循以下阶段。不要跳过步骤。
第一阶段确定您正在处理的内容,并确保内容模型对作者友好。
对于新块:
跳至步骤 1.2(内容模型设计)。搜索不存在的内容是浪费时间。
对于修改现有块:
询问用户:"是否存在使用此块的现有内容可供我们测试?"
是 → 识别现有内容用于测试
scripts/find-block-content.js 脚本搜索包含该块的页面无现有内容 → 进入步骤 1.2
以下情况需要:
询问用户: "这需要一个新内容模型。您希望我现在使用 content-modeling 技能来设计一个对作者友好的内容模型吗?"
是 → 调用 content-modeling 技能
否 → 用户可能希望自行定义
一旦内容模型定义完成(来自步骤 1.2),您需要测试内容。
询问用户: "我们需要用于开发和验证的测试内容。此内容将服务于多个目的:
您希望:
选项 1:CMS 内容(推荐)
选项 2:本地 HTML 文件(临时)
drafts/ 文件夹中创建符合内容模型结构的 HTML 文件aem up --html-folder drafts"测试内容通常可以兼作面向作者的文档,从而节省时间并保持文档最新。在创建测试内容时请考虑这一点:
当测试内容足以作为作者文档时:
当需要单独的作者文档时:
构建测试内容以同时服务于两个目的:
/tools/sidekick/library/ 或适当的库位置创建/drafts/docs/ 或 /drafts/library/询问用户关于文档的方法: "此测试内容是否也应作为作者文档?如果是,我们可以相应地构建它,并将其放置在适当的位置(例如,/drafts/library/{block-name} 或您项目的库系统)。"
如果是,则在创建内容时考虑文档需求。如果不是,则继续创建以测试为重点的内容,并注意稍后将需要作者文档。
关键:在确认测试内容存在且可访问之前,切勿开始阶段 2。
现在测试内容已存在,继续实现:
调用 building-blocks 技能:
遵循标准开发实践:
最后阶段确保实现与真实内容正确配合。
强制性测试:
在认为实现完成之前必需:
npm run lint
如果代码检查失败,使用以下命令修复问题:
npm run lint:fix
building-blocks 技能会自动调用 testing-blocks 技能 进行块开发。
对于其他代码更改,或需要额外的测试指导,调用 testing-blocks 技能,它提供:
在提交 PR 之前,确保:
测试内容 URL 将用作 PR 验证链接。
常见错误:
CDD 流程快速参考:
1. 内容发现
└─ 存在现有内容? → 使用它
└─ 新块/结构? → 设计内容模型 → 创建测试内容
2. 实现
└─ 基于真实内容模型构建代码
└─ 持续使用实际内容进行测试
3. 验证
└─ 使用测试内容进行全面测试
└─ 质量检查(代码检查、可访问性)
└─ 使用测试 URL 准备 PR
关键规则:没有测试内容,绝不进入实现阶段
使用提供的脚本搜索包含特定块的页面:
# 在 localhost 上搜索(默认)
node .claude/skills/content-driven-development/scripts/find-block-content.js <block-name>
# 搜索特定变体
node .claude/skills/content-driven-development/scripts/find-block-content.js <block-name> localhost:3000 <variant>
# 在实时站点上搜索
node .claude/skills/content-driven-development/scripts/find-block-content.js <block-name> main--repo--owner.aem.live
# 在预览中搜索变体
node .claude/skills/content-driven-development/scripts/find-block-content.js <block-name> main--repo--owner.aem.page <variant>
示例:
node .claude/skills/content-driven-development/scripts/find-block-content.js hero
node .claude/skills/content-driven-development/scripts/find-block-content.js hero localhost:3000 dark
node .claude/skills/content-driven-development/scripts/find-block-content.js cards main--site--owner.aem.live three-up
此脚本查询站点的 query-index 以查找包含指定块(及可选变体)的所有页面,并返回其 URL。该脚本使用适当的 DOM 解析来准确识别块。
此技能充当 AEM 开发工作流的协调者:
在内容建模阶段: → 调用 content-modeling 技能进行对作者友好的设计
在实现阶段: → 调用 building-blocks 技能进行块开发 → 引用 block-collection-and-party 技能获取模式
在验证阶段: → 引用 testing-blocks 技能进行全面测试
遵循此协调确保所有开发都遵循内容优先原则。
每周安装次数
0
代码仓库
GitHub 星标数
40
首次出现时间
1970年1月1日
安全审计
Content 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.
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.
Efficiency through preparation. Creating or identifying test content before coding provides:
NEVER start writing or modifying code without first identifying or creating the content you will use to test your changes.
Apply Content Driven Development principles to ALL AEM development tasks:
Skip CDD only for:
When in doubt, follow the CDD process. The time invested pays dividends in quality and efficiency.
This skill orchestrates other skills at the appropriate stages:
Follow these phases in order. Do not skip steps.
The first phase establishes what content you're working with and ensures the content model is author-friendly.
For new blocks:
Skip to Step 1.2 (Content Model Design). Searching for content that doesn't exist is a waste of time.
For modifications to existing blocks:
Ask the user: "Does content using this block already exist that we can use for testing?"
YES → Identify existing content to test against
scripts/find-block-content.js script to search for pages containing the blockNO existing content → Proceed to Step 1.2
REQUIRED for:
Ask the user: "This requires a new content model. Would you like me to use the content-modeling skill to design an author-friendly content model now?"
YES → Invoke the content-modeling skill
NO → The user may want to define it themselves
Once the content model is defined (from Step 1.2), you need test content.
Ask the user: "We need test content for development and validation. This content will serve multiple purposes:
Would you like to:
Option 1: CMS Content (Recommended)
Option 2: Local HTML Files (Temporary)
drafts/ folder matching the content model structureaem up --html-folder drafts"Test content can often double as author-facing documentation, saving time and keeping documentation current. Consider this when creating test content:
When test content IS sufficient as author documentation:
When separate author documentation is needed:
Structuring test content to serve both purposes:
/tools/sidekick/library/ or appropriate library location/drafts/docs/ or /drafts/library/Ask the user about documentation approach: "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., /drafts/library/{block-name} or your project's library system)."
If yes, guide content creation with documentation in mind. If no, proceed with test-focused content and note that author documentation will be needed later.
CRITICAL: Do not begin Phase 2 until you have confirmed test content exists and is accessible.
Now that test content exists, proceed with implementation:
Invoke the building-blocks skill:
Follow standard development practices:
The final phase ensures the implementation works correctly with real content.
Mandatory testing:
Required before considering implementation complete:
npm run lint
If linting fails, fix issues with:
npm run lint:fix
The testing-blocks skill is automatically invoked by building-blocks for block development.
For other code changes, or for additional testing guidance, invoke the testing-blocks skill which provides:
Before raising a PR, ensure:
The test content URL will be used as the PR validation link.
Common mistakes:
Quick reference for the CDD process:
1. CONTENT DISCOVERY
└─ Existing content? → Use it
└─ New block/structure? → Design content model → Create test content
2. IMPLEMENTATION
└─ Build code against the real content model
└─ Test continuously with actual content
3. VALIDATION
└─ Comprehensive testing with test content
└─ Quality checks (linting, accessibility)
└─ PR preparation with test URL
KEY RULE: Never proceed to implementation without test content
Use the provided script to search for pages containing a specific block:
# Search on localhost (default)
node .claude/skills/content-driven-development/scripts/find-block-content.js <block-name>
# Search for specific variant
node .claude/skills/content-driven-development/scripts/find-block-content.js <block-name> localhost:3000 <variant>
# Search on live site
node .claude/skills/content-driven-development/scripts/find-block-content.js <block-name> main--repo--owner.aem.live
# Search on preview with variant
node .claude/skills/content-driven-development/scripts/find-block-content.js <block-name> main--repo--owner.aem.page <variant>
Examples:
node .claude/skills/content-driven-development/scripts/find-block-content.js hero
node .claude/skills/content-driven-development/scripts/find-block-content.js hero localhost:3000 dark
node .claude/skills/content-driven-development/scripts/find-block-content.js cards main--site--owner.aem.live three-up
This 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.
This skill acts as the orchestrator for AEM development workflows:
At Content Modeling stage: → Invoke content-modeling skill for author-friendly design
At Implementation stage: → Invoke building-blocks skill for block development → Reference block-collection-and-party skill for patterns
At Validation stage: → Reference testing-blocks skill for comprehensive testing
Following this orchestration ensures all development follows content-first principles.
Weekly Installs
0
Repository
GitHub Stars
40
First Seen
Jan 1, 1970
Security Audits
React 组合模式指南:Vercel 组件架构最佳实践,提升代码可维护性
109,600 周安装