Spec-Driven Development

The spec
ships the
software.

A structured methodology where machine-readable
specifications drive every implementation decision —
for humans and AI alike.

Explore the Process View on GitHub
sdd — spec layer
# generate from spec before writing any code $ sdd spec load ./specs/user-auth.spec.md ✦ Spec layer parsed — 12 requirements, 34 constraints $ sdd generate --from-spec --model claude-sonnet ✦ Mapping requirements to implementation plan... ✦ Validating edge cases against constraints... ✔ Code generated — spec coverage: 100% $

Code without
a spec is
a guess.

Modern LLMs generate code fast — but fast code that doesn't match the requirements is just technical debt in disguise.

SDD treats the specification as the contract. Every function, every edge case, every constraint is declared upfront — so what gets built is exactly what was agreed upon.

01.
Requirement drift Features get built based on vague prompts, diverging from what stakeholders actually needed before a line is reviewed.
02.
Untested edge cases Without explicit constraints, AI skips boundary conditions and failure modes — leaving silent bugs in production.
03.
No shared contract Developers, QA, and AI agents each operate from different assumptions, making review and handoff unreliable.
04.
Untraceable decisions When requirements change, there's no spec to diff — meaning broken behaviour is discovered in prod, not in planning.

Three pillars
of living specs.

SDD is built on a feedback loop where specifications, tests, and implementation remain in constant alignment — each informing and validating the others.

// 01

Spec as
Contract

Specifications are authored in structured, machine-readable markdown — versioned alongside code and treated as the canonical source of behavioural truth before any implementation begins.

// 02

Spec-First
Generation

Every AI prompt is grounded in the relevant spec — functional requirements, edge cases, and acceptance criteria — before a single line of implementation is generated.

// 03

Continuous
Spec Loop

Generated code is validated against the spec automatically. Approved deviations feed back into updated specifications — closing the loop and keeping intent and implementation in sync.

Four steps.
One living contract.

01

Write the
Spec First

Define behaviour before touching code. Capture functional requirements, constraints, edge cases, and acceptance criteria in structured markdown.

Learn how →
02

Generate
from Spec

Inject the spec into every AI prompt. Generate implementation, tests, and types that are traceable to specific requirements — not just syntactically correct.

Learn how →
03

Validate
Coverage

Run automated checks that map every generated artefact back to a spec requirement. Surface gaps before review, not after deployment.

Learn how →
04

Evolve the
Spec

When requirements change, update the spec first. Let the diff drive regeneration — ensuring every downstream artefact stays in lockstep with intent.

Learn how →

Spec in.
Spec out.

Requirements
──▶
Living Spec
──▶
Spec Layer
Spec Evolution
◀──
Coverage Check
◀──
AI Generation
Spec-Driven Development

A closed loop where specifications and code co-evolve — no drift, no guesswork.

Built in the open,
for everyone.

SDD is a community-driven methodology. Contribute spec templates, share your workflows, and help define how humans and AI build software together.