Spec Driven Workflow

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

• A specification document in markdown, with normative statements using must/shall/should/may
• Acceptance criteria per requirement, ideally in given/when/then form
• The source tree and test suite where implementations will be annotated
• The coverage bar the merge gate enforces (mandatory-requirement coverage, typically 1.0)
• The previous requirements snapshot, when checking for drift against a baseline
• Which requirements are explicitly out of scope for the current milestone

Clarify First

Before writing or auditing a spec, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• What must be true for this to be "done" — becomes the acceptance criteria; without it the spec is a wish list and nothing is verifiable
• Which constraints are hard vs preferences — decides must/shall versus should, which in turn decides what the merge gate blocks on
• Who consumes the spec — an implementing engineer, a generating model, and an auditor need different precision; the generating case needs the most
• Scope boundary for this milestone — requirements outside it must be marked, or coverage reports will show permanent false gaps

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

Workflows

Workflow 1 — Write the spec, then prove it is precise

1. Draft requirements one statement at a time, each with exactly one obligation and a modality keyword. Two obligations in one sentence become two requirements.
2. Attach given/when/then acceptance criteria directly beneath each requirement.
3. Run the ambiguity linter. Fix every error before circulating the draft; errors are statements no engineer could implement without guessing.
4. Re-run until the precision ratio clears 0.85. Below that, review meetings will be spent discovering ambiguity rather than discussing design.

python3 engineering/spec-driven-workflow/scripts/spec_lint.py \
  --spec engineering/spec-driven-workflow/assets/sample_spec.md \
  --max-findings 0 --min-precision 0.85 --format text

The shipped sample scores 0.46 on purpose — it contains the exact failures the linter is built to catch, so you can see each rule fire before pointing it at real work.

Workflow 2 — Extract requirement IDs and freeze the baseline

1. Parse the spec into requirements. IDs are derived from section and ordinal (REQ-ROTATION-02), so they are stable across unrelated edits elsewhere in the file.
2. Commit the emitted JSON alongside the spec. This is the baseline.
3. On every subsequent parse, diff against the baseline. A DRIFT line means a requirement's text changed while its ID stayed the same — its tests now verify something the spec no longer says, which is the most dangerous state in the workflow.

python3 engineering/spec-driven-workflow/scripts/spec_parse.py \
  --spec engineering/spec-driven-workflow/assets/sample_spec.md \
  --baseline engineering/spec-driven-workflow/assets/sample_requirements.json \
  --require-acceptance --format text

Exit code is 1 when a mandatory requirement lacks acceptance criteria or when any requirement has drifted, which makes this the first half of the CI gate.

Workflow 3 — Gate the merge on bidirectional coverage

1. Annotate implementations and tests with their requirement IDs in comments or test names (def test_rotation_marks_pending_revocation(): # REQ-ROTATION-01).
2. Run coverage against the source tree. Read both directions: requirements with no implementation, and annotations naming IDs the spec no longer contains.
3. Fail the build below the mandatory coverage floor, or on any orphan annotation.

python3 engineering/spec-driven-workflow/scripts/trace_coverage.py \
  --requirements engineering/spec-driven-workflow/assets/sample_requirements.json \
  --index engineering/spec-driven-workflow/assets/sample_trace_index.json \
  --min-coverage 1.0 --format text

Swap --index for --code <path> to scan a real tree. The index form exists so the gate can run against a trace index built by another tool, and so this workflow is runnable straight from a fresh clone.

Decision frameworks

How precise does the spec need to be? [PROVEN]

Precision is a cost, and the right amount depends entirely on who reads the spec next.

Writing at "very high" for an internal one-week feature is waste. Writing at "moderate" for a generated implementation produces confidently wrong code, because ambiguity gets resolved silently rather than escalated.

Requirement status ladder

Every requirement sits in one of four states. Only one is acceptable at merge.

Coverage floors by requirement modality [RECOMMENDED]

The floors matter less than their being non-negotiable once set. A coverage gate that gets waived twice stops being read.