analyze-and-plan

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).