Spec-driven development (AI)

A discipline for AI-assisted coding: agree on a written specification of what you’re building before the AI generates code, so the agent implements an agreed plan rather than improvising. Introduced to this wiki by spec-driven-ai-tools.

Why it exists

The motivating claim: AI coding tools deliver speed, but “speed without structure means shipping ambiguity at scale.” A spec is the structure — a reviewable artifact the human approves before implementation, and a reference the implementation can be checked against.

Recurring design elements (across the tools surveyed)

A source-of-truth spec that the project accumulates (e.g. OpenSpec’s archived delta specs; Spec-Kit’s project-wide “constitution”).
Explicit handling of unknowns (Spec-Kit’s NEEDS CLARIFICATION flags).
Phases (plan → implement) and, in the better tools, course correction and review gates between them.
Delivery as agent-skills / slash commands installed into the coding agent.

More instances (2026-06-01)

conductor extends the idea to context-driven-development: not just a spec before code but context as a managed, persistent artifact (Context → Spec & Plan → Implement), with a mandatory plan-review gate and git-aware revert by logical work unit. Google’s launch post names CDD as its own discipline — SDD widened from spec-before-code to context + spec before code.
BMAD (per claude-code-best-practices) is a spec-driven methodology a practitioner reserves for projects with real users / security surfaces — it surfaced 36 user flows + risks before coding, where lighter “plan mode” missed security issues. Concrete evidence the spec-first discipline pays off where stakes are real.
spec-kit (GitHub) — the reference SDD toolkit: six /speckit.* commands (constitution → specify → clarify → plan → tasks → implement), “specs as executable blueprints,” across 30+ agents. The canonical, tool-agnostic instance.
get-shit-done (GSD) — a Claude-Code system pairing context engineering with SDD; shows the discipline converging with conductor‘s “context as artifact” idea.

Mined context, not written context (2026-07-22)

corbell moves the discipline’s input from prose to extraction. Where the tools above have a human author the constitution, the clarifications, or the managed context, Corbell builds a knowledge graph of the existing codebase (tree-sitter call graphs, typed signatures, service dependencies, plus git change coupling) and generates the spec against that, across multiple repos, validating it against recorded architecture constraints. The spec is then grounded in what the system demonstrably does rather than in what someone documented — and two of its inputs, change coupling and infra detection, are signals nobody maintains by hand. Unevaluated (no benchmark), so read it as a design direction: derived context as the SDD input.

Connections

Sits alongside claude-financial-services and (cross-wiki) gbrain as another case of capability and process encoded as markdown an agent executes. (Reflexively, it mirrors how this very wiki was built — a brainstorm → spec → plan → execute loop — which is some weak corroboration that the structure-before-code instinct generalizes.)

spec-driven-ai-tools · conductor · claude-code-best-practices · agentic-coding-harness · agent-skills