verify-before-complete

<objective> Enforce the GSD "work is not done when code compiles; work is done when verification passes" contract. A completion claim without verification output generated in the current message is a broken claim. This skill is the gate. </objective> <context> GSD's system prompt sets the expectation; `complete-slice.md` and `auto-verification.ts` enforce it at the slice boundary. But between slice boundaries — mid-task, mid-debug, mid-review — an agent can drift into "I think it works" mode and ship broken work. This skill is the ritual to break that pattern at any completion point. Invocation points: - About to toggle a checkbox from `[ ]` to `[x]` via a `gsd_*` tool - About to commit, push, or open a PR - About to summarize a task or slice as complete - About to say "tests pass", "build works", "lint clean", "fixed", "done" - Replying to a user question with "yes it works" or similar </context> <core_principle> **EVIDENCE BEFORE CLAIMS, ALWAYS.** "I ran it earlier" is not evidence. A log from three tool calls ago is not evidence if code has changed since. The verification must have happened *after* the last code change, in this message, with fresh output. **VIOLATING THE LETTER IS VIOLATING THE SPIRIT.** If the principle feels inconvenient, that is the signal it is load-bearing. Find the verification command. Run it. Read the output. </core_principle> <process> ## Step 1: Identify the claim What are you about to claim? Name it precisely: - "Tests pass" → which tests? - "Build works" → for which target? - "Bug is fixed" → which reproduction? - "Task complete" → which acceptance criteria? ## Step 2: Identify the verification command Match claim → command: | Claim | Verification | |---|---| | Tests pass | The specific test command the project uses (`npm test`, `cargo test`, `pytest`, etc.) — scoped to changed code if large suite. | | Build works | The project's build command, for real — not `tsc --noEmit` if the project needs a bundle. | | Lint clean | `lsp diagnostics` on edited files, plus the project's linter if CI runs one. | | Bug fixed | The reproduction steps from the bug report or test, freshly run. | | UI works | Browser verification via `browser_snapshot_refs` + `browser_assert` in a running app — not "it looks right in the diff". | | Slice complete | Every acceptance criterion in `S##-PLAN.md`, re-checked against live behavior. | If no verification command exists, the task has not produced a falsifiable claim — it is not complete. Write the verification first (see the `tdd` or `test` skill). ## Step 3: Run it now Use `async_bash` for one-shot commands, `bg_shell` for long-running servers/watchers. Wait for it to exit. Read the output. Not skim — read. **If output indicates failure:** you do not have a completion claim. Loop back: inspect the error, fix, re-run until it passes or a real blocker requires user input. Do not partially claim ("tests mostly pass") — either pass or report failure honestly. **If output indicates success:** quote the relevant line in your reply. "42 tests passing" or "Exit code 0" or "LSP reports 0 errors on the 3 edited files." ## Step 4: Check for staleness If you ran the verification early in this message, then made further code changes, the output is stale. Re-run. Cancel in-flight `async_bash` jobs that predated the edit (see system prompt: "stale job hygiene"). ## Step 5: Now claim Only now, after fresh output, can you: - Mark a task/slice/milestone complete via `gsd_*` - Commit / push / open PR - State "done", "fixed", "passes", "works" Include the evidence in the claim: "Slice complete — `npm test` passed (84/84), `npm run build` exit 0, acceptance criterion 3 verified against live UI at /dashboard." </process> <anti_patterns> - **"It should work"** — not verification. Run the command. - **"Tests passed earlier"** — stale. Run them now. - **"The code looks right"** — code review is not verification. - **`tsc --noEmit` as the build check** when the project bundles — test what the user experiences. - **Silent failures** — "the test was killed by a timeout so I assume it's fine." No. - **Partial passes** — 80/84 is not "tests pass." Report the 4 failures. - **Skipping because "I know why this works"** — your mental model is not evidence. </anti_patterns> <success_criteria> - [ ] The claim is precise — not "it works" but "`npm test` passed with 84/84 tests." - [ ] The verification command ran *after* the last code change, in this message. - [ ] Output was read, not skimmed. - [ ] Failures would have been caught — the verification actually tests what the claim asserts. - [ ] Relevant evidence is quoted in the claim reply. </success_criteria>