spec-driven-development

name	spec-driven-development
description	Design and run a Spec-Driven Development (SDD) pipeline for AI software factories — where structured specifications are the input, AI agents generate the code, and quality gates enforce correctness at each phase: SPECIFY → DECOMPOSE → IMPLEMENT → VERIFY → DELIVER. Use when building or refining a spec-driven pipeline any AI coding tool (Claude Code, Cursor, Hermes Agent, Devin, OpenHands, droid) can follow, or when you need spec quality gates, phase-gate verdicts, NFR encoding, or format translation. Do not use for a single small change with a clear goal (classify first via bmad), for the control-plane protocol of intent contracts, autonomy gating, and failure routing around a pipeline (bmad), or for unvalidated problems (product-discovery).
license	MIT
compatibility	Tool-agnostic — methodology applies to any AI coding agent. Templates use markdown and Gherkin. Scripts require bash.
metadata	{"source":"https://github.com/magnus919/agent-skills/spec-driven-development","spec-version":"1.2.0"}

Spec-Driven Development for AI Software Factories

A methodology for building software where specifications are the executable input to an AI code generation pipeline. The factory model: specs are blueprints, AI agents are the assembly line, verification is quality control, and gates catch defects before they compound.

Pipeline Overview

INCEPTION → [SPECIFY] → REVIEW → [DECOMPOSE] → REVIEW → [IMPLEMENT] → REVIEW → [VERIFY] → DELIVER
                 ↑         ↑          ↑            ↑           ↑           ↑          ↑         ↓
            Phase 1    Gate 1    Phase 2       Gate 2    Phase 3      Gate 3    Phase 4   Gate 4

Each phase passes through a gate before the next begins. A defect caught at Gate 1 costs minutes to fix; the same defect found at Gate 4 costs hours.

SDD Core Principles

1. Precision over clarity. A precise-but-dense spec is better than a readable-but-ambiguous one. The AI cannot ask for clarification — it implements one interpretation at random.
2. Completeness over brevity. Every missing acceptance criterion is a missing feature. Specifying an edge case upfront costs minutes; discovering it in production costs hours or days.
3. Testability over descriptiveness. An AC that cannot produce CLEAR PASS or CLEAR FAIL is not an AC — it's a hope.
4. Gates catch defects early. A Gate 1 (spec review) fix costs minutes. A Gate 4 (acceptance review) fix costs hours — the entire implementation may need to be discarded.
5. Spec is the single source of truth. Every downstream artifact traces back to the spec. Deviations are defects unless explicitly documented.
6. Spec IS the test (when possible). Gherkin-style ACs serve double duty as test cases. No separate test writing required.

Loading Guide

Reference	Load when	File
SDD Overview & Philosophy	You need to understand the why — the software factory metaphor, how SDD differs from traditional requirements, the core principle that specs are executable inputs not communication artifacts	references/sdd-overview.md
The AI Factory Pipeline	You need the full 5-phase pipeline with phase inputs, outputs, and transition rules — or you're designing a new pipeline from scratch	references/ai-factory-pipeline.md
Spec Quality Gates	You've written a SPEC.md and need to validate it before Gate 1 — the 7 gates that separate a good spec from a vague one	references/spec-quality-gates.md
Phase Gate Methodology	You're running a review gate (any of the 4) and need the decision criteria, verdict format, and escalation path	references/phase-gate-methodology.md
Methodology Selection Matrix	You're deciding which spec methodology (BDD, Formal, DbC, OpenAPI, ADRs) fits your context — when each applies and their AI-readiness ratings	references/methodology-matrix.md
NFR Encoding for AI Specs	You need to express non-functional requirements (performance, security, observability) in machine-readable format	references/nfr-encoding.md
Format Translation	You need to map between spec formats — Gherkin ↔ OpenAPI ↔ SPEC.md ↔ JSON Schema — or translate a human PRD into an AI-ready spec	references/format-translation.md
Critiques & Tradeoffs	You need to decide when not to use SDD — the honest limitations: spec bottleneck, GIGO, drift, over/under-specification, the formal methods tax	references/critiques-and-tradeoffs.md
Worked Example — Complete SPEC.md	You want to see a fully-realized specification to calibrate your output depth — shows proper AC format, edge case enumeration, NFR thresholds, data contracts, and assumptions for a password reset feature	references/example-spec.md

Methodology Quick-Pick

Not sure which spec methodology fits your situation? Use this quick reference table (load references/methodology-matrix.md for full depth):

Concern	Reach For	AI-Readiness	Format Produces
REST API contracts	OpenAPI	VERY HIGH	YAML/JSON specification
Event/message schemas (Kafka, RabbitMQ)	AsyncAPI	HIGH	YAML/JSON channel specs
Behavioral requirements (what the system does)	BDD / Gherkin	HIGH	.feature files with Given/When/Then
Interface correctness (pre/post/invariants)	Design by Contract	VERY HIGH	Assertions in code
Distributed system correctness (consensus, protocols)	TLA+ / Alloy	VERY HIGH (narrow scope)	Mathematical model
Architecture decisions (why we chose X)	ADRs	MEDIUM	Structured markdown
System structure (boxes-and-lines)	C4 Model	MEDIUM-HIGH	PlantUML / structured text
Raw stakeholder intent	User Stories	LOW (needs refinement)	"As a... I want..."

Composite approach: Most systems need 3-4 of these working together. REST APIs get OpenAPI, event streams get AsyncAPI, critical behavior gets Gherkin scenarios, and cross-team interface boundaries get DbC assertions.

Templates

Template	Pipeline Phase	File
SPEC.md	Phase 1 — Spec Authoring (SPECIFY). Write this first: problem, scope, user stories, ACs, edge cases, NFRs, data contracts	templates/SPEC.md
REVIEW.md	Gate 1-4 — Phase-Gate Review. Use at every gate transition: spec review, plan review, implementation review, acceptance review	templates/REVIEW.md
TASK-PLAN.md	Phase 2 — Work Decomposition (DECOMPOSE). Extract from an approved spec: task groups, dependency graph, per-task ACs, implementation directives	templates/TASK-PLAN.md
VERIFICATION.md	Phase 4 — Verification (VERIFY). After implementation: AC pass/fail matrix, compliance score, failure dossiers with remediation	templates/VERIFICATION.md

Scripts

Script	When to run	File
spec-quality-check.sh	After writing or editing a SPEC.md — validates all required sections exist (problem statement, scope, ACs, edge cases, NFRs, assumptions)	scripts/spec-quality-check.sh
spec-to-tasks.sh	After writing a TASK-PLAN.md — validates every spec AC has a covering task reference	scripts/spec-to-tasks.sh

Trigger Conditions

Load this skill when:

• You're building a software factory — a system where AI agents produce code from structured specifications through a gated pipeline
• You're designing or refining an AI code generation pipeline where specs drive implementation
• You need to write a specification that an AI agent (not just a human) will consume
• You're evaluating spec methodologies (BDD, Formal, OpenAPI-first) for a project
• You need templates for SPEC.md, TASK-PLAN.md, REVIEW.md, or VERIFICATION.md
• You're reviewing or verifying AI-generated code against its specification

Quick Reference: Pipeline Steps

Step	Action	Load This Reference	Produces
1	Write SPEC.md from template — problem, scope, stories, ACs, edge cases, NFRs	references/spec-quality-gates.md (validate before Gate 1)	SPEC.md
2	Run spec-quality-check.sh on SPEC.md	—	Validation report
3	Gate 1 — Review spec against quality gates, produce REVIEW.md	references/spec-quality-gates.md, references/phase-gate-methodology.md	REVIEW.md (APPROVED/CONDITIONS/REJECTED)
4	Decompose approved spec into TASK-PLAN.md — each task traces to a spec section	references/ai-factory-pipeline.md (Decompose phase)	TASK-PLAN.md
5	Gate 2 — Review task plan for dependency honesty, spec coverage	references/phase-gate-methodology.md	REVIEW.md
6	Implement each task — one task per agent session	—	Code/PR
7	Gate 3 — Verify implementation against spec (not code style)	references/phase-gate-methodology.md	REVIEW.md
8	Run verification against all ACs — produce VERIFICATION.md	—	VERIFICATION.md
9	Gate 4 — Review verification report, deliver only if no BLOCKING failures	references/phase-gate-methodology.md	Final approval

For deeper methodology context, load references/sdd-overview.md (philosophy) or references/ai-factory-pipeline.md (full pipeline detail with parallel execution).

Pipeline Mode & Entry Points

Where to Enter the Pipeline

You don't always start at SPECIFY. Enter at the phase matching what you already have:

You Have This	Enter At	Start With
A vague idea, conversation, or PRD	Phase 1 — SPECIFY	templates/SPEC.md + references/format-translation.md
Approved product scope with interaction contracts	Phase 1 — SPECIFY	product-design-and-ux handoff + templates/SPEC.md
A clear, approved specification	Phase 2 — DECOMPOSE	templates/TASK-PLAN.md + references/ai-factory-pipeline.md
A spec + approved task plan	Phase 3 — IMPLEMENT	Task cards with per-task directives
Existing code needing verification	Phase 4 — VERIFY	templates/VERIFICATION.md

Which Pipeline Mode to Use

Not every change needs all 4 gates. Choose your mode:

Mode	When to Use	Gates to Run	Spec Depth
Full	Greenfield feature, multi-agent work, high-risk change, complex interfaces	All 4 gates	Full SPEC.md with ACs, NFRs, data contracts, edge cases
Lightweight	Simple bug fix, well-understood change, single-file edit	Gate 1 (light) → Implement → Gate 4 (light)	Single user story, 1-3 ACs, abbreviated NFRs
Minimal	Prototype, spike, exploration, throwaway code	None — skip formal gates	Mini-spec: 1 paragraph + 3 ACs. No NFR table, no contracts

Rule of thumb: If you know the fix in under 60 seconds and it touches one file, use Lightweight mode. If you're not sure what the right solution is, use Full mode — the gates will catch your mistakes early.

Gate Recovery & Revision

What happens when a gate rejects your artifact? The pipeline doesn't stop — it iterates.

The Revision Loop

Artifact submitted → Gate review → REJECTED or CONDITIONS
                                         ↓
                              Return to current phase
                                         ↓
                              Patch specific findings
                                         ↓
                              Resubmit for re-review
                                         ↓
                              APPROVED → next phase

How to Patch, Not Rewrite

Each finding identifies a narrow, fixable defect. Patch at the finding's location:

Finding Severity	Action	Example
BLOCKING	Fix immediately — gate cannot pass until resolved	Rewrite untestable AC with binary PASS/FAIL condition
CRITICAL	Must fix. Gate may pass with documented exception if ≤2 findings	Add missing edge cases to User Stories section
MINOR	Fix before next phase if feasible. Gate can pass with remediation plan	Add request/response schemas to Data Contracts
INFO	Note for future improvement. No action required for gate pass	Suggestion for alternative field naming

Re-Review Scope

After patching, the reviewer determines scope:

• Full re-review: Required when REJECTED verdict. The entire artifact is re-evaluated, not just patched sections.
• Targeted re-review: Possible with CONDITIONS verdict. Only the affected findings and surrounding context are reviewed.

Risk of partial fixes: Fixing only BLOCKING findings and ignoring CRITICAL ones guarantees re-rejection at the same gate. The CRITICAL findings that cost minutes to fix at Gate 1 will cost hours if caught at Gate 4.

Common Revision Patterns

Failure Pattern	Fix Strategy	Prevention
Untestable ACs (vague language like "should handle", "should be efficient")	Rewrite each AC with explicit Given/When/Then and binary outcome	Apply Gate 1 check before submitting
Missing edge cases	Add edge case enumeration per story — 3 minimum per story	Use the "five things that could go wrong" test from spec-quality-gates
Vague NFRs ("should be fast", "should be secure")	Replace with specific threshold + verification method	Use the "can I write a test for this?" test from nfr-encoding reference
Incomplete contracts (endpoint listed but no schemas)	Add full request/response schemas for every endpoint	Check Gate 5 before submitting
Scope creep (ambiguous in-scope items)	Tighten scope description and expand Out of Scope	Apply the "would someone include more than intended?" test

When not to use

• A single small change with a clear goal — skip the spec pipeline and implement directly; classify the work first (see bmad).
• You need the control-plane protocol around a pipeline — who owns intent, how work is classified, when autonomy is safe, how failure routes between layers: use bmad for intent contracts, work classification, autonomy gating, and failure routing. SDD supplies the spec format and gate mechanics; bmad supplies the protocol that runs the whole effort.
• The problem itself is unvalidated — route to product-discovery before authoring a spec on top of an unexamined idea.

Tool-Agnostic Design

This skill describes the methodology, not a specific tool. The pipeline works with:

• Claude Code — use CLAUDE.md as spec context, plan-then-implement mode
• Cursor — Plan Mode + .cursorrules for spec context, Agent Mode for implementation
• Hermes Agent — native SDD pipeline (authoring → review → decomposition → verification)
• Devin / OpenHands — task-based implementation from spec-derived task plans
• GitHub Copilot Workspace — issue-driven with spec as structured issue body
• droid (Factory) — task cards from spec decomposition

The templates are format-agnostic (markdown). Adapt the handoff mechanism (CLAUDE.md, .cursorrules, AGENTS.md) to your tool.