verify-before-claim

# Verify Before Claim Never say a code change is "done", "ready", or "should work" without running a verification command in the same turn and quoting the pass output in the reply. Reading the diff is not verification. Compiling in your head is not verification. The verifier is. ## When this applies Use this skill any time all of these are true: - You edited code, config, or tests. - The edit is meant to leave the project in a working state. - A verification command exists for the change: test suite, linter, type-checker, smoke invocation, `--help`, `--dry-run`, or a short script that exercises the new behavior. Skip it when: - The user explicitly asked for a draft, sketch, or commentary - not a finished change. - The change has no executable surface (pure documentation, a README edit, a comment-only diff). - A separate iteration loop (e.g. a declared `check` task) already owns the verification - the loop's pass verdict is sufficient. ## How to pick the verification command Pick the narrowest command that can reject the change. | Change shape | Verification command | | --------------------------------------- | ------------------------------------------------------------------ | | New or edited function with a unit test | Run the single test (e.g. `npm test -- <file>`, `bats <file>`). | | Edit to a shell script | `shellcheck <path>` + a smoke invocation with representative args. | | Config / JSON / YAML edit | The tool's validator: `jq -e .`, `yamllint`, `tsc --noEmit`. | | Refactor touching multiple files | The full project test/lint command. | | New CLI flag | Run the CLI with the flag and paste the output. | | Bug fix with a reproducer | Run the reproducer before (optional) and after; both pastes help. | If no verifier exists yet, either (a) write one as part of the change, or (b) downgrade the claim: say "written but unverified - please run X to confirm" instead of "done". ## The contract 1. Make the edit. 2. Run the verification command in the same turn as the claim. 3. Quote the relevant pass output (exit 0, "OK", "42 passed", etc.) in the reply - not as a screenshot of your plan, but as the literal tail of the command output. 4. Only then say "done" / "ready" / equivalent. ## Claim phrases that trigger this skill If you find yourself about to write any of these, you owe the reader a verifier run first: - "should work now" - "this is done" - "ready to commit" - "all tests should pass" - "the fix is in place" - "you can merge this" Without a fresh pass output, rewrite as: "edit is written; run `<command>` to confirm before merging." ## Anti-patterns - **Claiming on "the diff looks right".** The diff looking right is a necessary precondition, not the check itself. - **Running the verifier and forgetting to quote it.** If the user can't see the pass output, they'll rerun it anyway - paste the last few lines. - **Running a broader verifier when a narrow one exists.** A single-file test run that passes is a stronger signal than a big suite whose tail got truncated. - **Running the verifier in a separate background job and claiming done before it finishes.** If you used a background runner, wait for exit and quote the result before the claim. - **Claiming a negative result ("the test now fails correctly") without showing the failure text.** Same rule - reproduce it in-turn.