PLAN: turn intent into structured work
A PLAN turns an approved PRD into a dependency-aware, reviewable implementation approach with explicit completion conditions and checkpoints. It explains what should happen in what order before the work is delegated to agents.
PLAN is the second Core phase of AI Architect Mastery's AI Driven Development Methodology. It connects approved intent to bounded TASKs.
Why this comes before TASK
An agent asked to "just build the PRD" in one pass can produce a large, hard-to-review diff. A PLAN divides the approach into reviewable increments and exposes architectural decisions before implementation makes them expensive to undo.
Skipping directly from intent to code leaves sequencing choices implicit. Even a reasonable local choice can conflict with constraints that the agent has not considered.
What a working PLAN defines
- What gets built first and why: dependency order, not arbitrary order.
- Which PRD requirements map to which planned steps.
- Where meaningful checkpoints occur before downstream work depends on a decision.
- What done means for each step, not only for the whole feature.
Inputs, output and responsibility
Input: the approved PRD and relevant architecture and code context. Output: a reviewed implementation approach with steps and completion conditions. Owner: the Human Architect reviews and approves the approach; the agent may propose it.
In practice, the human can ask an agent to propose a plan, then edit and approve it before TASKs begin. Plan review checks coverage, dependencies, scope and verification, not merely whether the list sounds plausible.
Constructed example: sequence an authorization change
The approved PRD requires owner-only export. The PLAN identifies the existing authorization helper, sequences the scoped handler change and specifies allowed/denied request checks plus output-format regression evidence. It does not bundle an unrelated reporting rewrite into the first step.
- P1, confirm the approach: against example PRD E1, locate the helper and single-owner policy. Completion requires a supported owner/denial path; missing support blocks P2.
- P2, make the bounded change: update the handler and its tests together. Completion requires owner-success, non-owner-no-data and unchanged-format evidence for the same revision.
- P3, human checkpoint: evaluate the diff, results and limitations before acceptance; passing one request is insufficient.
Illustrative decision and artifact: approve example PLAN E2 because P1 gates P2 and verification accompanies the change, not a later optional task. Revise E2 if helper reuse cannot meet E1. These are constructed plan entries and decisions, not claims of executed work.
Planning is not a guarantee
Implementation can reveal that the approach cannot satisfy an approved constraint. The human directs a controlled return to PLAN, reviews the revised approach and refreshes dependent TASKs and verification. Revalidate the affected behavior before acceptance. Do not let an obsolete plan justify unapproved agent improvisation.
Related concepts
Watch the PLAN methodology overview on YouTube (optional video; this text is the current reference).