Content Driven Development
Ship AEM Edge Delivery sites by modeling content and authoring flows before block code so agents follow author-first EDS patterns.
Overview
Content Driven Development is an agent skill most often used in Build (also Validate, Ship) that guides AEM Edge Delivery work with an author-first, content-model-before-code methodology.
Install
npx skills add https://github.com/adobe/skills --skill content-driven-developmentWhat is this skill?
- Author-first philosophy: content reality and authoring UX lead design decisions
- AEM Edge Delivery content models, blocks, and authoring patterns as first-class artifacts
- CDD workflow integrates related EDS skills (e.g. da-auth) in a content-driven sequence
- Aligns reference docs with EDS spec to reduce orphan warnings and drift
- Semantic-release packaged skill for repeatable agent guidance on Adobe EDS builds
Adoption & trust: 601 installs on skills.sh; 122 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are building an EDS site but agents optimize for developer shortcuts instead of real authoring flows, content models, and block contracts authors need.
Who is it for?
Solo builders shipping marketing, docs, or content sites on AEM Edge Delivery who want agents to respect author workflows.
Skip if: Teams on non-AEM stacks or pure app SPAs with no document-centric authoring model.
When should I use this skill?
Starting or extending an AEM Edge Delivery site where content models, blocks, or authoring patterns must lead implementation.
What do I get? / Deliverables
You get a content-first plan and implementation pattern aligned to EDS—blocks, models, and authoring behavior defined before deep coding.
- Content-first block and model decisions
- EDS-aligned implementation steps for agents
- Authoring pattern documentation updates
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Edge Delivery work lands in Build when you turn content models and blocks into pages; CDD is the canonical shelf for that product work. Frontend subphase fits block structures, section composition, and live-site authoring patterns rather than generic backend APIs.
Where it fits
Define content types and section inventory before agents generate block boilerplate.
Implement a new hero block only after the author-facing fields and doc paths are fixed.
Update EDS reference folders so agent edits match spec and silence orphan doc warnings.
Walk authoring scenarios in preview to confirm blocks match how authors actually publish.
How it compares
Use instead of component-first scaffolding that ignores how authors actually publish in Edge Delivery.
Common Questions / FAQ
Who is content-driven-development for?
Indie and small-team builders using Claude Code or Cursor on Adobe AEM Edge Delivery who need agents to prioritize authors when designing blocks and content structures.
When should I use content-driven-development?
During Validate when scoping content types and IA, in Build when implementing blocks and models, and in Ship when verifying authoring matches spec—any time EDS structure is on the table.
Is content-driven-development safe to install?
Review the Security Audits panel on this Prism page before installing; the skill is procedural guidance and does not itself execute deployments.
SKILL.md
READMESKILL.md - Content Driven Development
{"extends": "../../../../../release.config.cjs"} ## [2.0.1](https://github.com/adobe/skills/compare/content-driven-development-v2.0.0...content-driven-development-v2.0.1) (2026-05-29) ### Bug Fixes * Update EDS skill intros to follow current best practices ([c728efe](https://github.com/adobe/skills/commit/c728efeba0b35135e7aa93bc114d0bfad7406278)) # [2.0.0](https://github.com/adobe/skills/compare/content-driven-development-v1.1.0...content-driven-development-v2.0.0) (2026-05-14) ### Bug Fixes * **aem-eds:** align references/ with spec and silence orphan warnings ([b48cf80](https://github.com/adobe/skills/commit/b48cf802a0974eccfa74fa85898113d66f29f64d)) # [1.1.0](https://github.com/adobe/skills/compare/content-driven-development-v1.0.0...content-driven-development-v1.1.0) (2026-04-27) ### Features * **da-auth:** add da-auth skill and surface DA auth in CDD workflow (#89) ([fc7a2e8](https://github.com/adobe/skills/commit/fc7a2e8c1dbcb37c65759ba907fe581f8a44e3c8)) # 1.0.0 (2026-04-16) { "name": "content-driven-development", "version": "0.0.0-semantically-released", "private": true } # Why Content-First Matters Content Driven Development isn't just a process—it's a philosophy that prioritizes author needs and content reality over developer convenience. ## Author Needs Come First **Authors are the primary users of the structures we create.** When building for AEM Edge Delivery, the content models, block structures, and authoring patterns we design directly impact how easily authors can create and maintain content. Content models must be: - **Intuitive**: Authors should understand what goes where without extensive training - **Easy to work with**: Creating content should feel natural, not like navigating a complex technical system - **Forgiving**: Common mistakes should be easy to spot and fix - **Flexible**: Authors need room for creativity within structure This often means more complex decoration code. That's okay. Developer convenience is secondary to author experience. ## Efficiency Through Preparation Creating or identifying test content before coding isn't "extra work"—it's a multiplier that makes everything else faster and better. ### Immediate Testing Capability When you have test content ready before you write code: - No need to stop development to create test scenarios - Test as you write, catching issues immediately - Faster iteration cycles - More confidence in your implementation ### Better PR Workflows Test content serves double duty: - Development testing during implementation - PR validation links for PSI checks (required for all PRs) - No scrambling to create content when you're ready to merge ### Living Documentation Well-structured test content often becomes: - Author-facing examples and documentation - Onboarding material for new team members - Reference implementations for similar blocks - Quality standards for content creation ### Fewer Assumptions **Code-first development is full of assumptions.** You assume: - How authors will structure content - What edge cases might appear - How content will actually be used - What reasonable defaults should be **Content-first development reveals reality.** Real content shows: - Actual author patterns and preferences - Edge cases you never imagined - Use cases that don't fit your assumptions - Where your elegant design breaks down ## The Cost of Skipping CDD Every shortcut has a price: **Skipping content discovery:** - Build against imagined requirements - Miss existing patterns and conventions - Create inconsistent experiences - Duplicate effort (content exists, you just didn't find it) **Skipping content modeling:** - Create developer-friendly but author-hostile structures - Require extensive author training - Generate support burden as authors struggle - Need redesigns when reality doesn't match assumptions **Skipping test content creation:** - Can't validate during development - Delay discovering issues until PR review - Creat