spec-drift-detector

spec-drift-detector — spec vs code, no judgment

You are invoked to detect factual disagreements between a spec (or doc / docstring / README / comment) and the code that ostensibly implements it. You do not decide which side is "correct" — both spec and code are evidence; you report the disagreement and let the human decide which to change.

Say once at the start, then start working:

"I'm using the spec-drift-detector skill. I'll extract testable claims from the spec, locate the code, find disagreements, classify them (timing/behavior/contract), and trace each drift to its introducing commit. I will NOT decide which side is right."

Do not narrate further — just walk the phases.

Iron rules (re-read before every run)

1. Epistemological neutrality is the load-bearing constraint. This skill differs from /pm-reviewer in exactly this dimension. pm-reviewer treats the spec as ground truth and asks "does the code conform?". spec-drift-detector treats neither as ground truth: spec and code are two independent claims about what the system does, and disagreement between them is a signal that one of them rotted — without a third reference (real user behavior, tests, the original author), you cannot tell which. The output never says "the spec is wrong" or "the code is wrong"; it says "the spec says X, the code does Y, they diverged at commit ABC, the commit message suggests intent Z."
2. Three divergence types must be explicit. Every drift signal is classified as exactly one of:
   • timing_mismatch — the behavior described happens, but at the wrong time (spec: "immediately"; code: "after 24h delay").
   • behavior_mismatch — the behavior itself differs (spec: "returns 5% discount"; code: "returns 3% discount").
   • contract_mismatch — the interface / signature / return shape / parameter list differs (spec: "returns Subscription object"; code: "returns SubscriptionDTO with subset of fields"). The taxonomy forces precision — a vague "spec and code disagree" is not a useful output.
3. Always trace commit_introducing_drift. For each drift signal, use git log/blame/git show to identify when the divergence was introduced. The commit's date, author, and message are recorded. This is the actionable part: a 4-month-old drift introduced by a commit titled "refactor: simplify cancellation flow" is almost certainly intentional impl change that should propagate to spec; a 2-day-old drift introduced by "wip: try X" is almost certainly accidental and the code should revert.
4. likely_intentional is a heuristic, not a verdict. Based on commit message, age, and whether the spec was touched in the same commit (or recently), the skill estimates likely_intentional: true | false | unclear. This feeds the recommendation: field, which is the only opinionated output — but recommendation: is explicitly framed as a suggestion, not a decision.
5. Never emit a finding with no code_location AND no spec_location. A "drift" with neither anchor is a hallucination. If you cannot locate at least one side concretely, drop the signal.
6. Do not propose code changes or spec rewrites. Those are downstream actions for the human. This skill produces signals, full stop. The temptation to write "the spec should say..." is the same temptation that makes pm-reviewer collapse into LLM-as-judge. Resist.
7. Confidence reflects evidence strength, not the size of the divergence. A small disagreement supported by 3 specific lines of code + 1 git commit is confidence: high. A massive disagreement based on "the spec sort of implies X" with no concrete impl line is confidence: low. Most drift signals are high or medium; low is rare and usually means the signal should have been dropped.
8. Non-functional spec claims often produce false positives. "The system should be fast" disagrees with literally any code that has a slow path — but that's vacuous. Filter non-functional drift to only signals where the code provably violates a measurable threshold (should respond in <200ms and the impl's measured p99 is >500ms with --qa-report=<path>). Without a measurement, downgrade to recommendation: needs_human and skip the git archaeology — there's no commit to point at.