The four phases of Spec-Driven Development

Four artifacts, four gates

SPECIFY   -> spec.md   scenarios, requirements, acceptance, non-goals
PLAN      -> plan.md   architecture, data models, risks, dependencies
TASKS     -> tasks.md  atomic, ordered, verifiable, file paths
IMPLEMENT -> code      task by task, validated against the spec

What each phase is for

• Specify — the what. No implementation detail; capture what the system must do and how you'll know it does.
• Plan — the how. Where your stack and conventions enter. Reviewing it is where architectural mistakes die cheaply.
• Tasks — the steps. One atomic, verifiable task at a time beats "build the feature" by a mile.
• Implement — the code, checked against acceptance criteria written before any code existed.

The gates are the method

Each phase ends with a human review before the next begins. Skip them and you've got vibe coding with extra files. The artifacts exist to make review possible when errors are cheapest to fix.

It's a loop, not a line

Implementation reveals a gap in the plan; the plan reveals an ambiguity in the spec. Edit upstream, regenerate downstream. However your tool names the phases, the invariant is the loop.

---

Free cheat sheet: the whole method on a few pages — the loop, spec anatomy, EARS, right-sizing — SDD Cheat Sheet.

Go deeper: the full reference — every phase, the tool landscape, three walkthroughs — Spec-Driven Development: The Complete Guide.

Which phase does your team skip most — and has it burned you yet? 👇