The Four Phases of Spec-Driven Development, Explained
The SDD workflow is a loop of four phases — Specify, Plan, Tasks, Implement — each producing a concrete artifact that feeds the next, each with a human review gate before proceeding. Tools name them slightly differently, but the shape is universal, and once you know it you can recognise it under any branding.
Phase 1 — Specify: the What
From a feature description you produce a specification: the user scenarios, the functional requirements, the acceptance criteria, the constraints, and the non-goals that bound the scope. The spec deliberately avoids implementation detail — it captures what the system must do and how you will know it does, not which library to use. A command often drafts it, but the value comes from your review.
Phase 2 — Plan: the How
The plan translates the spec into technical decisions: architecture, technology choices, data models, APIs, risks and dependencies. This is where your stack and conventions enter. Reviewing the plan is where architectural mistakes die cheaply — before a single line of code embodies them.
Phase 3 — Tasks: the Steps
The plan breaks into small, verifiable work items with explicit ordering and dependencies — models before services, services before endpoints — each with validation criteria and the file paths it touches. An agent executing one atomic task at a time is far more reliable than one told to "build the feature."
Phase 4 — Implement: the Code, Checked
Only now does code get written. The agent executes tasks in order, validating each against its criteria, and the output is checked against the spec's acceptance criteria. When something is wrong, the fix flows upstream: wrong requirement means editing the spec, wrong architecture means editing the plan, only a wrong expression means editing code.
The Gates Are the Method
Each phase ends with a human review before the next begins. Skip the gates and you have vibe coding with extra files. The artifacts exist to make review possible at the moment errors are cheapest to fix — that review is where SDD earns its keep. The loop runs as a cycle, too: implementation reveals a gap in the plan, the plan reveals an ambiguity in the spec, you edit upstream and regenerate downstream.