spec-driven-dev

An autonomous, spec-first, test-driven development pipeline for Claude Code.

One command — /sdd:ship "build feature X" — takes a feature from a grilled-out spec all the way to shipped code: it interviews you until the design is pinned, freezes that into a spec, writes a PRD, slices it into independent issues, then builds every slice test-first across parallel isolated git worktrees and auto-merges each to main.

It's the anti-"vibe-coding" workflow: nothing gets built until the decisions are nailed down and a failing test demands it.

Install

/plugin marketplace add T-Rzeznik/spec-driven-dev
/plugin install sdd@spec-driven-dev

The pipeline

/sdd:ship chains the skills below. There is exactly one human gate — the grill — at the very front. Everything after the frozen spec runs unattended.

detect setup → grill → freeze spec → PRD → slice into issues
            → parallel test-driven build (isolated worktrees, DAG-ordered)
            → auto-merge each slice to main

Skills

Skill	What it does
sdd:ship	The orchestrator. Runs the whole pipeline end-to-end from one command.
sdd:grill	Interviews you relentlessly, one question at a time, until every design decision is resolved. The single human gate.
sdd:prd	Turns the frozen spec into a PRD and publishes it to the issue tracker.
sdd:to-issues	Breaks the PRD into independent, end-to-end vertical slices (one issue each) with a blocked-by dependency graph.
sdd:tdd	Implements a slice test-first via red → green → refactor.
sdd:improve-codebase-architecture	Standalone codebase recon: surfaces inconsistencies, bad practices, and deepening opportunities. Run it before building to prime the work.
sdd:setup	One-time per-repo config: wires up the issue tracker, triage labels, and domain docs the pipeline relies on. Run automatically by ship if missing.

How ship works

1. Detect setup — if the repo isn't configured yet, run sdd:setup first (one-time).
2. Grill — the only interactive step; resolve every branch of the design.
3. Freeze spec — decisions written to .sdd/spec-<slug>.md (gitignored scaffolding; deleted on success, kept on failure so a run can resume).
4. PRD — published as a ready-for-agent issue: the durable record of intent.
5. Slice — one issue per vertical slice, with blocked-by dependencies.
6. Build — each slice runs in its own worktree as a parallel subagent, test-first; blocked slices wait, then rebase on main.
7. Land — each green slice opens a PR and is squash-merged to main.
8. Failure — a slice that can't go green is retried once, then left as an open PR labeled ready-for-human; the rest of the run continues.

Caveats (by design)

• Auto-merge to main is gated only by the slice's local test run — there is no CI backstop. Main's integrity rests entirely on the test suite. Use it on repos where you trust the tests.
• The parallel-swarm build is powerful and aggressive. It opens worktrees, builds concurrently, and merges autonomously. Point it at a repo where that's welcome.

License

MIT © T. Rzeznik