The Spec-Driven Playbook

The Playbook Is a Discipline

The spec-driven development playbook is nine lessons assembled into a single operating procedure. Each step has a defined input, a defined output, and a gate that must pass before the next step starts. The playbook is not a checklist you run once — it is a discipline that becomes automatic over 50 features.

The Eight Steps

The playbook flows in two arcs: the forward arc (Idea → PRD → Build → Ship) and the backward arc (Retro → Lessons → Memory → Better Spec). Most teams execute the forward arc and skip the backward arc. The backward arc is where the compounding value lives.

The Audit Lab

Use this checklist before declaring any PRD-driven feature done. Critical items block delivery. Non-critical items generate follow-on tickets.

The checklist has 25 items across five sections. Run it linearly. Do not skip sections in sequence. The most common skipped section is Post-Ship — and that is the section that makes the forward arc compound over time.

The Three Common Playbook Failures

Failure 1: Research-skipped PRD. The team writes acceptance criteria without querying Semantic memory layer. The PRD specifies building infrastructure that already exists. Implementation time doubles because the existing system must be refactored rather than extended. Prevention: Semantic memory layer-first before writing the first PRD line.

Failure 2: Spec-merged without impl ticket. The Phase A spec is reviewed and merged. Everyone assumes Phase A implementation is next. Context shifts. Three sprints later, Phase A is still unimplemented. Prevention: impl ticket created in the same conversation as the spec merge.

Failure 3: E2E verified on wrong machine. The feature works on localhost. CI is green. The PR merges. The Vercel frontend (new shape) calls the production server backend (old shape). Production breaks. Prevention: Gate 5 requires target-machine verification, not localhost verification.

All three failures are in the audit lab checklist. All three have known prevention rules. The checklist is the operationalization of the rules.

Connecting the Tracks

The spec-driven development track builds on two prior tracks:

context-engineering: CLAUDE.md architecture, progressive disclosure, and Semantic Memory Layer are the infrastructure that makes the Research step fast. Without Semantic memory layer, the research step requires manually grepping documentation. With it, memory_query("topic") surfaces relevant context in seconds.

parallel-agent-dispatch: The decompose step produces per-phase PRDs. The build step dispatches multiple agents in parallel. Without worktree isolation and scoped dispatch prompts (from the parallel-agent-dispatch track), the build phase runs serially and misses the leverage of the fleet.

Spec-driven development is the orchestrating layer. Context engineering and parallel dispatch are the infrastructure it runs on. Together, they represent the complete operational system: spec what you'll build, organize how you'll build it, dispatch who will build it, verify that it works.

What Compounds Over 50 Features

After 50 features with the full playbook running:

• Average spec-writing time decreases because Semantic Memory Layer surfaces existing patterns
• Average rework rate decreases because consumer contracts catch callers before implementation
• Average quality gate pass rate increases because test-first discipline catches bugs during build
• Average time-to-done decreases because retros prevent repeated mistakes

The compound curve is real. It is measurable. It requires every loop of the cycle to run — including the retro, including the lessons.md update, including the Semantic Memory Layer storage.

The practitioners who reach the highest leverage in AI-assisted development are not the ones who find the best models or the fastest tools. They are the ones who compound their learning across every session, every feature, every ship.

Track Complete

You have built the full spec-driven development stack: why specs beat vibe-coding, how to move from raw idea to structured PRD, the anatomy of a good spec, decomposition into parallelizable phases, the handoff contract that makes dispatch safe, the quality gates that define done, semantic review against the spec, the compounding loop that improves every future spec, and the end-to-end playbook with the audit lab.

The next track — documentation-is-king — extends the same spec-first discipline to every document in the repo: READMEs, agent context files, ADRs, and runbooks. The PRD is only the first artifact in the stack; the next track makes every doc work as hard as the spec, and adds the gates that keep them honest.