PLAN — Turn Intent Into a Structured Implementation Plan

What a PLAN is in this methodology

A PLAN takes the approved PRD and breaks it into a structured implementation plan with explicit checkpoints: an ordered sequence of steps, each one small enough to review, each one building on the last. It is your architectural map before any code exists.

A working PLAN typically defines:

• What gets built first, and why — dependency order, not arbitrary order
• Where the natural checkpoints are, so review happens before the codebase grows unreviewable
• Which parts of the PRD map to which implementation steps
• What "done" looks like for each step, not just for the whole feature

Why this comes before TASK. An agent asked to "just build the PRD" in one pass tends to produce a single large, hard-to-review diff. A PLAN forces the work into reviewable increments — the same discipline a senior engineer would apply to any non-trivial change.

What goes wrong without one

Skipping the PLAN and going straight from PRD to code is where architectural control is usually lost first. The agent makes sequencing decisions on its own — sometimes reasonably, sometimes not — and by the time a human reviews the result, undoing a wrong structural choice costs far more than catching it up front would have.

How this looks in practice

In AAM's methodology, the PLAN is usually generated collaboratively: you hand the agent the PRD and ask it to propose a plan, then you edit and approve it before any TASK begins. The plan itself becomes a checklist you and the agent both work through, one checkpoint at a time.