Analyze & Plan

Analyze what you're building and define clear acceptance criteria before writing code. This skill provides task-specific analysis guidance for different types of AEM development work.

When to Use This Skill

Invoked by: content-driven-development skill (Step 2)

Use this skill to:

•Analyze visual designs/mockups (if provided)
•Understand requirements for the task
•Define what success looks like
•Document analysis for reference throughout development

Workflow

Follow these steps in order:

Step 1: Visual Analysis (if provided)

Skip if: No screenshots, design files, or reference URLs provided

If visual materials provided:

See resources/visual-analysis.md for complete visual analysis guidance covering:

•Visual elements - Layout, typography, colors, spacing, borders, shadows, effects, icons, imagery
•Interactive elements - Components, states (hover/focus/active), animations, transitions
•Dynamic UI patterns - Modals, tooltips, dropdowns, accordions, carousels
•Content structure - Hierarchy, repeating patterns, content types
•Responsive behavior - Mobile, tablet, desktop variations
•Systematic mapping - Page vs component, existing patterns, block model classification

What to do:

•Gather all visual materials (screenshots, designs, URLs)
•Use visual-analysis.md guide to systematically analyze
•Document findings using the provided template
•Extract key requirements for next steps

Output: Visual requirements documented for use in next steps

Step 2: Understand Requirements

What to do:

•Think about what you are building/fixing/modifying?
•Consider why this is needed?
•What's the context surrounding these changes?
•Consider all viewports (mobile, tablet, desktop)
•Think about the author experience and how that impacts what we do

Ask the user questions if needed:

•Clarify unclear requirements
•Understand edge cases
•Confirm assumptions
•Get missing information

Use task-specific guidance:

•See "Task-Specific Analysis Guidance" section below
•Apply appropriate guidance based on task type

Output: A clear understanding of all requirements

Step 3: Define Acceptance Criteria

What to define:

•What does "done" look like?
•How will you validate success?
•What should NOT break (regressions)?

Include:

•Visual match (if designs provided)
•Functional requirements
•Responsive behavior
•Author experience
•Performance considerations

Use task-specific guidance:

•See acceptance criteria guidelines in "Task-Specific Analysis Guidance" below

Output: Specific, testable acceptance criteria

Step 4: Document Analysis

Create markdown file at: drafts/tmp/{block-name}-analysis.md

•Use the block name being worked on (e.g., drafts/tmp/hero-analysis.md)
•For non-block work, use descriptive name (e.g., drafts/tmp/navigation-fix-analysis.md)

File should include:

•Task description and context
•Visual analysis (if applicable)
•Requirements identified
•Acceptance criteria defined
•Any open questions or assumptions

Notes:

•This is a working artifact, not committed to git
•Used for reference throughout development (especially in Step 7: Final Validation)
•Allows multiple analyses to coexist in drafts/tmp/

Output: Analysis file at drafts/tmp/{block-name}-analysis.md

Task-Specific Analysis Guidance

Building a new block

Must analyze:

•
Author inputs (list what content authors will provide: e.g., "image, title, description, link")
- •What's required vs optional?
- •What can be inferred or auto-generated?
•What variations do we need to support?
•Styling and layout expectations
•Interactive behavior requirements
•Responsive behavior across viewports

DON'T design at this stage:

•❌ Table structure (how many columns/rows)
•❌ Cell layout (which content goes in which cell)
•❌ Block variant classes or naming
•❌ Exact authoring format or field names
•❌ Authoring experience or ease-of-use (always the goal, addressed in Step 3)

Note: At this stage, focus on WHAT content is needed, not HOW it's structured. Detailed content model design (table structure, cells, variants, authoring UX) happens in the content-modeling skill (CDD Step 3).