Spec-Driven Development (SDD)
An SDD (Spec-Driven Development spec) is an agent-ready execution contract. Where an FD answers what and why, an SDD answers how — with enough precision that an AI agent can implement the component autonomously.
FD answers: WHAT needs to be built, and WHY
SDD answers: HOW an agent should build one specific component
What an SDD contains
| Section | Purpose |
|---|---|
| Scope | Exactly what this SDD covers — and what it does not |
| Interfaces | Inputs, outputs, protocols this component must satisfy |
| Constraints | Language, framework, versions, security rules, denied patterns |
| Best Practices | Style and architecture conventions from the dev-guide |
| Test Requirements | What must be tested and at what level |
| Acceptance Criteria | Verifiable conditions for "done" |
| Context | Files to read, existing code to understand before starting |
| Constitution Check | Pre-filled compliance checklist |
| Work Log | Filled by the agent: executor, decisions, output, retrospective |
SDD lifecycle
planned → assigned → in-progress → done
- planned: generated by
/fd-sdd, not yet assigned - assigned: an agent is designated but hasn't started
- in-progress: agent is executing
- done: implementation complete, Work Log filled
One SDD per component
Each SDD covers exactly one component, service, or module. Isolation is intentional — it allows parallel execution and clear ownership. SDDs within the same FD define their interfaces explicitly so agents produce compatible code without reading each other's SDDs.
The integration wiring SDD
Every FD ends with an integration wiring SDD. Its job: wire everything together, trace the startup path from entry point to leaves, and run an end-to-end test covering the full user-facing flow.
Without this SDD, individual components may work in isolation but never connect.
Pages
- Generating SDDs —
/fd-sddfrom an approved FD - Executing SDDs — assigning to agents and running