Verify Code Before Claiming Completion

This skill enforces a strict rule against claiming work is complete without fresh verification evidence, framing unverified completion claims as dishonesty rather than efficiency. Its "Iron Law" is no completion claims without fresh verification evidence in the same message - if the verification command wasn't run in this response, the claim cannot be made. It defines a five-step gate function before any status claim or expression of satisfaction: identify what command actually proves the claim, run that full command fresh, read the complete output including exit code and failure count, verify the output actually confirms the claim, and only then state it, with the evidence attached.

It maps common claim types to what evidence is actually required versus what looks sufficient but isn't: "tests pass" requires fresh test output showing zero failures, not a previous run or assumption; "linter clean" requires linter output, not partial checks; "build succeeds" requires an exit-0 build run, not a passing linter (which doesn't check compilation); "bug fixed" requires re-testing the original symptom, not just changed code; a regression test requires a full red-green cycle (write it, confirm it passes, revert the fix, confirm it now fails, restore the fix); "agent completed" requires checking the actual VCS diff, not trusting the agent's self-report; and "requirements met" requires a line-by-line checklist, not just passing tests. It lists explicit red flags (hedging language like "should"/"probably"/"seems to," expressing satisfaction before verification, being about to commit/push without checking, trusting agent success reports, feeling tired and wanting to be done) and directly rebuts common rationalizations - "I'm confident" is not evidence, "linter passed" is not the same as compiling, "different words so the rule doesn't apply" is rejected because the spirit of the rule beats the letter.

Use this skill always before any variation of a success or completion claim, any expression of satisfaction, any positive statement about work state, committing or creating a PR, moving to the next task, or delegating to and then trusting another agent. The rule explicitly applies not just to exact phrasing but to paraphrases, synonyms, and any implication of success or correctness.

There is no stated exception - it treats "just this once" itself as one of the rationalizations to catch and reject, grounded in real failure cases (a human partner losing trust after being told something worked when it hadn't, undefined functions shipping and crashing, missing requirements shipping as if complete).

Input is a claim about to be made - that tests pass, a build succeeds, a bug is fixed, requirements are met, or an agent completed its task. Output is either verified evidence-backed language stating the actual result, or an honest statement of the actual, possibly failing or incomplete, status - never a claim made without having just run the proof.

# Pattern: run, read, then claim
[Run test command] [See: 34/34 pass] "All tests pass"

Framework-agnostic - applies to test runners, linters, build tools, VCS diffs, and agent-delegation workflows equally, wherever a completion or success claim is about to be made.

Developers and AI agents who need a hard discipline against overclaiming completion or correctness, especially under time pressure or when delegating work to sub-agents whose self-reports shouldn't be trusted without independent verification.