done

done — the evidence gate

/done [what was being built, or a path to its spec/plan]

Answer one question: is there evidence this change works and does what was asked — or does it merely look finished? "The work looks done" is the weakest signal in agentic coding; this gate replaces it with quoted output and an independent review. It never makes the change better — it decides whether the change is ready.

Step 0 — Establish the yardstick

Identify the diff (uncommitted changes, or the branch vs its merge base) and the intent: the change folder's spec.md/plan.md if this came from the feature skill, the bug repro if from bugfix, otherwise ask the user for one sentence of "what was this supposed to do". No yardstick → the review below can only check correctness, not compliance; say so.

Step 1 — Evidence checklist

Copy this checklist into the response and fill it in as you go — every line gets quoted command output or an explicit ✗ with the reason. An unticked line with a reason is honest; a ticked line without evidence is the exact failure this skill exists to prevent.

- [ ] Full test suite: <command> → <pass/fail counts, verbatim tail>
- [ ] Lint / typecheck: <command> → <result>          (✗ if repo has none)
- [ ] Build: <command> → <result>                     (✗ if n/a)
- [ ] Ran the actual change: <command / flow> → <observed behavior>
- [ ] Diff hygiene: no debug prints (grep the diff for [DEBUG- — the tag
      bugfix leaves), no commented-out code, no stray files
- [ ] Tripwires (fake-green + source-security, below): clean

Every line is quoted redacted: secrets replaced with <REDACTED>, long output cut to its signal-carrying lines. A live secret in pasted evidence is itself a finding — treat it like a tripwire hit (→ FIX FIRST) until it's out of the evidence; whether it's also in the code is the source-security scan's job below.

"Ran the actual change" is the line agents skip and humans value most: a green suite proves the tests pass, not that the feature works. Execute the spec's end-to-end check — start the app, curl the endpoint, run the CLI on real input — and report what actually happened. On auth, payment, or data-migration surfaces, "ran the change" means the failure path too, not just the happy one — an expired or tampered token is rejected, a declined card and a replayed webhook are handled, a migration's rollback is actually run — because that's where these surfaces break. Happy-path evidence alone on one of those surfaces can't reach SHIP: it's incomplete evidence (→ FIX FIRST, or NEEDS HUMAN when the missing check is a judgment call).