Kill ambiguity before it compounds
A misunderstood requirement found during spec review costs minutes. Found during QA, it costs days. Found in production, it costs customers. Specs move discovery to the cheapest possible moment.
Spec-Driven SDLC
Approved for build
Write the spec first.
Then build exactly what's asked.
Spec-driven development is a simple discipline: the written specification drives planning, the plan drives task breakdown, and the tasks drive implementation. No drifting prompts, no ambiguous tickets — every build traceable back to a line in a spec.
01 — Definition
What is spec-driven development?
Spec-driven development is a software delivery methodology where a written specification is the source of truth for everything that follows. Before a single line of code is written, the team — or a single developer working with an AI coding assistant — produces a precise document describing what will be built, why it matters, and how success will be verified.
The spec then drives a strict downstream chain: the specification produces an implementation plan, the plan is decomposed into reviewable tasks, and the tasks are executed one at a time. Each task is verifiable against the spec, so drift is caught the moment it happens — not at the demo.
It is especially powerful in the age of AI-assisted coding. An AI agent given a vague prompt improvises; given a rigorous spec, it executes. The spec is the interface between human intent and machine implementation.
Field note
A spec is not a requirements wish list and not a design doc. It is a contract: it states the problem, the constraints, the acceptance criteria, and the definition of done — with enough precision that two independent implementers would build the same thing.
The one rule
If it isn't in the spec, it doesn't get built. If the build needs it, the spec gets updated first. The document always leads; the code always follows.
02 — The lifecycle
The loop: spec → plan → tasks → build
Four stages, one direction of travel, one review gate at the end. Then the loop closes back on the spec.
STAGE 1
Specify
Define the problem, scope, constraints, and acceptance criteria in a written spec document.
STAGE 2
Plan
Derive an implementation plan from the spec: architecture, data flows, sequencing, risks.
STAGE 3
Decompose
Break the plan into small, independently verifiable tasks, each traceable to a spec section.
STAGE 4
Build
Implement task by task, verifying each against its acceptance criteria before moving on.
↩ REVIEW GATE — after build, verify the whole against the spec. Mismatches don't get patched; they get specified, and the loop runs again.
03 — Rationale
Why teams adopt it
Make AI agents reliable
AI coding assistants are superb implementers and terrible mind-readers. A spec converts fuzzy human intent into a machine-checkable contract, which is exactly the input agents perform best on.
Review the thinking, not the code
Reviewing a spec takes an hour; reviewing a wrong implementation takes a sprint. Specs let stakeholders approve direction when changing it is still cheap.
Parallel work without collisions
When the spec and plan are precise, tasks can be worked in parallel — by teammates or by multiple agents — because interfaces and boundaries are defined up front.
Onboarding becomes reading
New engineers (human or otherwise) start from the spec library instead of archaeology through Slack threads and commit messages. The "why" is written down.
Auditability by construction
Every task traces to a plan section, every plan section to a spec line. For regulated or high-stakes work, the trail of decisions is the deliverable — and it writes itself.
04 — Templates
Most used
Integrations
Incidents
Start from a proven template
Six annotated, copy-ready spec templates. Each one explains every section, shows when to use it, and copies to your clipboard in one click.
Feature spec
The full lifecycle template: problem, scope, acceptance criteria, plan, task breakdown. Use it for any new capability worth building carefully.
Open templateAPI spec
Endpoints, schemas, error contracts, versioning, and consumer impact. For any interface another team — or agent — will build against.
Open templateBugfix spec
Reproduction, root-cause hypothesis, fix strategy, and regression tests. Turns "fix the bug" into an investigation with a paper trail.
Open template
05 — Training
Learn the discipline
Writing good specs is a skill, not a talent. Our flagship course — Spec-Driven Development Foundations — takes you from blank page to a reviewed, build-ready spec in four modules.
- Module 1: The spec mindset — what belongs in a spec and what doesn't
- Module 2: Acceptance criteria that actually accept
- Module 3: From plan to task decomposition
- Module 4: Review loops and spec maintenance
Formats
Self-paced, live cohort, and private team workshops. Every format ends with the same deliverable: a real spec for your real project, reviewed against the rubric.
06 — Action
Your next build starts with a document.
Grab a template, write your first spec, and run the loop. The drafting table is open.
| Rev | Date | Author | Description |
|---|---|---|---|
| 1.0 | 2026-09-20 | Spec Kit | Initial publication of the home page. |