sdd — the rsc Spec-Driven Development dispatcher

The front door for building software the rsc way: intent in, shipped-and-verified software out, with the spec, plan and decisions recorded into the project's living knowledge model as you go.

sdd is the engineering counterpart of the harness. The harness runs the chaos → knowledge loop (inbox → 02-DOCS wiki). sdd runs the intent → shipped software loop, and it writes the artifacts of that loop — constitution, specs, plans, decisions — into the same 02-DOCS/wiki/sdd/ so the project's knowledge grows with every feature instead of leaking into chat history.

This skill does not do a phase itself. It is the dispatcher: it names the method, reads how much accompaniment you want, tells you which phase you are in, and hands off to the phase skill that owns the work. Each phase skill, when it finishes, points you at the next one — so once you enter the chain you rarely come back here.

The method in one breath

Spec-Driven Development (SDD, GitHub Spec Kit lineage) says: decide what and why before how, write it down, and let each written artifact gate the next step. You do not jump from a sentence in chat to a pull request. You move through ordered phases, each producing a durable artifact that the next phase reads. The payoff is that the intent is reviewable before any code exists, drift is caught at a gate instead of in production, and the whole thing is legible to the next person (or the next session) because it lives in 02-DOCS, not in a scrollback.

If you only remember one rule: the artifact is the contract. Code is checked against the plan, the plan against the spec, the spec against the constitution. When they disagree, you fix the disagreement before writing more code — you do not let the code silently win.

Step zero: calibrate the SDD runtime

Before the first non-trivial feature in a repo, run ../sdd-init/SKILL.md. It detects the stack, package manager, test runners, scripts, monorepo signals and review budget, refreshes .rsc/skill-registry.json, and writes: