Checking a spec

DISRESPEC-SPINE: One fact once. No filler, repeated source material, empty sections, or chat restatement; after successful creation return only clickable artifact links, except for blockers, failed creation, incomplete verification, or irreversible-action confirmation.

A defect in a spec is cheapest to catch before any task is cut from it — after that, every agent run inherits it. This guide runs the check by hand and produces a short report. When available, suspec check <spec-path> (suspec-cli) applies the machine-checkable catalog. It does not perform the writing watchlist or leverage judgment below; run those by hand. When the CLI is absent, apply the core checks by hand as well. Either way the result is a review checklist, not a gate — whether it blocks is the team's policy.

The one rule: check, don't edit

You read the spec and write a report. You change nothing — not a typo, not a "quick fix". Mixing checking with editing destroys the report's value: the author can no longer see what was found versus what was silently changed, and a one-word "fix" can change what gets built. Hand the report to the author (or switch hats explicitly and edit after the report exists).

The core checks