/done

name: done
description: >-
  End-of-session shipping gate — "prove it works, then ship it." Runs an
  evidence checklist (full test suite, lint/typecheck, build, and actually
  running the change — output quoted, never asserted), then a fresh-context
  two-stage review by a sub-agent that sees only the diff and the spec:
  spec-compliance first, correctness second, style never — joined by a
  cross-model second opinion when a codex/gemini CLI is installed. Flags
  fake-green
  tripwires (edited or deleted tests, new TODOs or skips, hardcoded
  expectations) and ends with a verdict — SHIP, FIX FIRST, or NEEDS HUMAN —
  before drafting the commit/PR for the user's approval. Use at the end of
  any coding session or when the user asks "is this done", "ready to ship?",
  "/done", "wrap this up", "review and commit this". It is the closing step
  of both feature and bugfix, but works standalone on any uncommitted or
  branch diff.

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).

**Fake-green tripwires** — scan the diff itself; any hit is called out loudly and blocks a SHIP verdict until the user rules on it:

• an existing test **modified or deleted** in the same diff that makes it pass
• new `skip` / `xfail` / `.only` / commented-out assertions
• new TODOs or "temporary" workarounds standing in for the actual behavior
• assertions hardcoded to the current output rather than the intended behavior
• a test whose expected value is **recomputed the way the code computes it**

— expected values come from an independent source of truth

**Source-security tripwires** — the source-side twin of the block above: scan the diff for a catastrophe pattern *shipped into the code*, not a faked test. Same rule — any hit is called out loudly with the **file:line** and blocks a SHIP verdict until the user rules on it. This is a scan of the diff, not an audit of the repo: a pattern the change doesn't introduce isn't a finding. Some clauses below are *missing-safeguard* ones — no tested rollback, no signature check — where the safeguard may live in an unchanged file; there the tripwire fires on the dangerous operation the diff *does* introduce, and the user's ruling is where a safeguard already present elsewhere gets confirmed.

• **Secrets in source** — an API key, token, password, or private key in a

committed file (not `.env`, not a placeholder); an OAuth or signing secret anywhere but a secret manager.

• **Injection** — a SQL query built by string-concatenation with

user-controlled input (no parameterization / ORM escaping); a shell command assembled from user input via `exec`/`spawn`/`eval`; a template rendered with unescaped user input where XSS is reachable.

• **Auth bypass** — a middleware check with a path that skips it (early

return, swallowed exception, condition that always resolves to "authenticated"); a role or permission check forgeable by a request parameter; a JWT accepted with `alg: none` or verified against a secret hardcoded in source.

• **Payment / webhook** — a handler that swallows errors silently (empty

catch, unhandled rejection); a webhook with no signature verification; an amount or recipient derived from untrusted input without server-side validation.

• **Destructive data** — a migration with a `DROP` or destructive `ALTER` and

no tested rollback; a bulk delete or update with no `WHERE