verification-before-completion

# Verification Before Completion Claiming work done without fresh verification is dishonesty, not efficiency. `adversarial-verify` is the *what*; this skill is the *when* — the gate you pass through right before any completion claim. ## The Iron Law ``` NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE ``` If you have not run the verification command in this message, you cannot claim it passes. Not "should", not "probably", not "based on the diff". ## The gate function Before writing "done" / "fixed" / "green" / "ready to merge" — even in your own head: 1. **Identify** — what exact command proves this claim? 2. **Run** — execute it fresh, complete, in this turn. 3. **Read** — full output, check exit code, count failures. 4. **Verify** — does the output actually confirm the claim? 5. **Only then** — make the claim, with the evidence attached. Skip any step = you are lying to the user, not verifying. ## Common false claims → what they actually need | Claim | Requires | Not sufficient | |---|---|---| | Tests pass | Fresh test run, exit 0, 0 failures | "should pass", previous run, "logic looks right" | | Linter clean | Linter output, 0 errors | Partial check, extrapolating from unrelated files | | Build succeeds | Build command, exit 0 | Linter passing, editor squiggles gone | | Bug fixed | Reproduce original symptom, watch it not happen | Code changed, "assumed" fixed | | Regression test works | Red → green cycle verified (revert fix, watch test fail, restore, watch pass) | Test passes once | | Agent/subagent completed | Read the VCS diff, verify claimed changes exist | Agent's own "success" report | | Spec satisfied | Line-by-line checklist against the plan | "Tests pass, phase complete" | ## Red flags — you are about to claim without verifying - Words like "should", "probably", "seems to", "looks good" - Satisfaction language ("Great!", "Perfect!", "Done!") before running the command - About to commit / push / open PR without a verification block in this turn - Trusting a subagent's own success report - "Just this once" thinking, or "I'm tired, close enough" - Partial verification (linter passed, so build must) ## Rationalization prevention | Excuse | Reality | |---|---| | "Should work now" | RUN it. | | "I'm confident" | Confidence ≠ evidence. | | "Linter passed" | Linter ≠ compiler ≠ tests. | | "The agent said success" | Read the diff yourself. | | "Partial check is enough" | Partial proves nothing about the whole. | | "Different words, so rule doesn't apply" | Spirit over letter. | ## Patterns **Tests** - Run the test command. See `34/34 pass`. Then say "all tests pass". - Never: "should pass now". **Regression tests (real red-green)** - Write test → run (pass) → revert fix → run (MUST FAIL) → restore fix → run (pass). - Never: "I've added a regression test" without the red-green cycle. **Build** - Run the build. See exit 0. Then say "build passes". - Never: "linter passed, build should too". **Agent delegation** - Subagent reports success → check the VCS diff → verify the claimed change is actually there → report actual state. - Never: paste the agent's report and treat it as truth. ## When this fires Always, before: - Any variation of success / completion / fixed / passing / green - Committing, opening a PR, marking a task done, handing off - Moving to the next task - Any positive statement about the work's state ## Pair with - `adversarial-verify` — the 11 shortcuts agents take to fake "done"; run through the list, then run through this gate. - `clean-commits` — clean commits require verified content. - The `verifier` subagent — dispatch it; then verify its report against the diff (per the "Agent delegation" pattern above). ## The bottom line Run the command. Read the output. THEN claim the result. Non-negotiable.