v1.13.0 · a dogfooded spec · for humans & AI agents

GUIDE
SDD

The spec is the prompt. The code conforms. One copyable method that drops into any project and makes intent drift very hard to ship — token-efficient, persona-split, gated end to end.

the whole thing in two ideas

Why it works

Everything else is a consequence of taking two ideas seriously.

idea 01

The spec is the source of truth

Behaviour is decided in the spec first; the code conforms. When the spec and the code disagree, the code is the bug — never the other way around.

idea 02

Split the mind for risky work

One author writing spec + tests + code transcribes a single misread into all three. So independently-scoped agents write each — a misread has to survive more than one reader to ship.

spec-first, action-second

The loop, gated end to end

Eight small stages. Each one is loaded on its own, does its work, passes a gate, and hands back. You never hold the whole thing in your head at once.

stage 0
Triage
right-size · 2×2
stage 1–2
Design + recon
PM approves
stage 3
Spec-first (EARS)
link_check + prose_check
stage 4
Test plan
coverage_check
stage 4b
Build plan
read ledger · tokens
stage 5
QA · spec-only
red, frozen
stage 6
Engineer
test_edit_ban
stage 7
Gates + ship
run_all · validate
on done
Fold + pin
spec = fold(ships)
spec phase test phase ship phase QA writes tests blind to the code · the Engineer can't edit them

don't pay for ceremony you don't need

Match ceremony to risk

Decided once, in Triage. The full persona loop is for work where a misread is expensive and not self-evident — not for a typo fix.

misread cheap / obvious
misread expensive / non-obvious
not decomposable
Mechanicalsingle context · 0→3→4→4b→7
Coupled + riskyfull persona loop · 0–7
decomposable
Independent + simpleparallel worktree workers
Independent + riskyparallel · persona loop each

the headline feature

It never loads itself wholesale

The only thing in context on every single call is the constitution + PROCESS §0 — the boot protocol (router, load manifest, precedence, DoD summary). Everything that grows with your project — stages, gates, spec shards, the project details — loads only when a stage asks for it.

≈1.6k always
stages · gates · spec shards · project details · changelog — demand-loaded
constitution + PROCESS §0standing cost ≈ constant, whatever the project size

one PO box, many worker boxes

Box roles & the surface-back protocol

A box (a machine / session) has a standing role, separate from the per-feature personas. Run a PO box that files tickets; let worker boxes pick up ready work and run it to done.

PO box full authority
  • triage, design, recon, spec authoring
  • files & shapes tickets; decides forks
  • patches the canonical spec; owns the merge
  • a solo dev is a PO box
worker box execution only
  • picks up a Ready (DoR-met) item
  • runs the implementation stages to Done
  • never authors the spec or decides forks
  • never edits scope or ACs
Hit an ambiguity? A worker never guesses and never patches the spec. It writes [NEEDS-PO] / [BLOCKED] back to the ticket, flips it to the PO-attention state, and stops. The fix lands in the artifact, before code — every time. The ticket is the async channel between boxes.

Across machines the item is the only channel: a worker claims it (claimed-by:<box-id>), runs it to gates-green, flags Ready-for-review — never merges; the PO box reviews + owns the serialized merge. Ready → Claimed → In-Progress → Ready-for-review → Done · polled every 15–30 min

≈20 minutes to adopt

Get started

Drop the spine into a repo, wire one stub, answer three questions, smoke-test the gates. That's it.

  1. Install the spine (installer, the plugin's /sdd-init, or copy) into your repo (sdd/) — never edited per project.
  2. Wire the agent carrierAGENTS.md holds the ~9-line stub (constitution + boot protocol + this box's role); CLAUDE.md routes to it, Copilot via .github/copilot-instructions.md. Cross-agent by design.
  3. Choose a changelog mode — external tracker (Jira / Linear) or a lighter on-disk backlog. The fold-on-ship invariant is identical either way.
  4. Greenfield or brownfield? New code → author the spec fresh. Existing code with no spec → reconstruct the slice you touch, or run discover-spec.md to characterize a whole area.
  5. Choose a spec format — Markdown→HTML (default) or raw HTML. Either way each subsection is a content-only shard.
  6. Instantiate the project details & register your architecture seams.
  7. Fill gates.config.json & add your inline gate rules.
  8. Smoke-test the gates — green means adopted.
## GUIDE SDD (spec-driven development)
This project uses GUIDE SDD — a defined spec-first process. On your first action, say so, then:
1. Obey @sdd/constitution.md (always in effect).
2. Read @sdd/PROCESS.md §0 (the boot protocol / router) and load ONLY your current stage.
3. Project specifics live in sdd/project-config/project-details.md — load on demand.
This box's SDD role: $SDD_BOX_ROLE (default po). Workers surface concerns
to the changelog item; they never author specs or decide forks — see sdd/box-roles.md.
Do not continue ad-hoc work. If unsure of your stage, you are in Stage 0.

how it compares

SDD vs. the field

All of these reject vibe-coding for structure; SDD, BMAD, and Spec Kit each center a spec and a constitution. Where SDD differs: it mechanically enforces the discipline with gates and an unbroken trace, and is built to stay token-lean — at the cost of being the newest (a GitHub repo with CI, an installer pair, a Claude Code plugin and a release zip — not yet a community).

SDD (this)BMAD-METHODGitHub Spec KitSuperpowers
Core ideaSpec is canon; gated, persona-split, token-leanMulti-agent agile team (12+ roles)Slash-command spec→plan→tasks→codeComposable agent skills, TDD-centric
Source of truthEARS shards + traceability, folded from the changelogPRD + architecture → story filesspec/plan/tasks.mdPlan + TDD tests; skills, no canonical spec
RolesPM + Orchestrator + QA⊥Engineer + fresh ValidationAnalyst / PM / Architect / SM / Dev / QAYou + your agent hostSubagents + a code-review subagent
EnforcementScriptable gates (coverage, link, test-edit-ban, seam, fold)Convention + prompt structureConvention + a constitutionTDD red/green; no spec gates
ContextStaged loading, ~1.6k always-loadedRich, front-loaded story filesPer-feature spec dirsSkills on demand + subagent isolation
Testing4 layers, spec-derived oracle, mutation in Discover SpecQA agent reviews (not gated)Tests as tasks (not enforced)TDD-first is the core
BrownfieldDiscover Spec (reconstruct + coverage/mutation)Analyst flowsGreenfield-leaningTDD on existing code
PlatformCross-agent via AGENTS.md (Claude / Codex / Cursor / Gemini / Copilot); PowerShell + Bash gates; Claude Code pluginAny IDE/model, domain-agnosticCLI + many agent hostsClaude Code + harnesses (plugin)
Install / adoptInstaller pair (install.ps1 / install.sh: install · update · doctor, manifest-tracked), Claude Code plugin (/plugin install guide-sdd@guide-sdd), or unzip + runbook → INIT (3 questions) → gate smoke test. No toolchain.npx bmad-method installuvx … specify init/plugin install superpowers
Maturityv1.13.0 · GitHub repo, CI on Windows + Ubuntu with negative controls, release-on-tag, dogfooded on 3 projects52.6k★, v6.11 skills-based, large communityOfficial GitHub, growingDominant skills framework

Pick SDD for enforced traceability + a token-lean, multi-box, cross-agent process. Pick the others for a packaged product (Spec Kit), cross-domain multi-agent planning with no lock-in (BMAD), or a TDD-first skills library (Superpowers). They also compose — e.g. SDD's gates over Superpowers-style TDD.

the package

Read on