Spec-Driven Workflow

Development where the specification is the source of truth and the code is its implementation, rather than a document that was true at kickoff and fiction by week three. The mechanism is unglamorous: every normative statement gets a stable ID, every ID appears in a test, and the merge gate fails when the two drift apart. Without that mechanical link a spec is a memo, and memos do not survive contact with a sprint.

When to use this skill

• Starting a greenfield feature where the interface is contested and the cost of building the wrong thing is high
• Reviving a stale spec that no longer matches shipped behaviour and needs reconciling before the next change
• Gating merges on coverage so a PR that implements two of five committed requirements cannot silently land
• Auditing what actually shipped ahead of a stakeholder review or a compliance obligation
• Handing a feature to another team who need the intent, not just the code
• Generating an implementation from a spec — which only works if the spec is precise enough that two engineers would build the same thing

Inputs the skill expects