The verification-before-completion Skill — Evidence Before Claims
How the verification-before-completion skill enforces a single rule: no completion claim without fresh verification output. The gate function, common failure modes, and why partial checks prove nothing.
Claiming work is complete without running verification is not efficiency — it is a false statement. The verification-before-completion skill encodes one rule: no claim of success, no expression of satisfaction, no commit, no PR, and no move to the next task without running the relevant command and reading its output in the same message.
The skill is loaded before any completion action. Its core instrument is the gate function: a five-step sequence that must execute in order before any positive claim is made.
The gate function
The five steps are: identify what command proves the claim; run the full command fresh and complete; read the full output and check the exit code; confirm that the output actually supports the claim; and only then state the claim with the evidence attached. Skipping any step produces a lie, not a verification.
The rule applies to exact phrases and to paraphrases. "Should pass now," "looks correct," and "probably fine" are all completion claims without evidence, even though none of them say the word "done." The spirit of the rule covers any wording that implies success without having run the check.
Common failure modes
A table in the skill maps claim types to what actually constitutes verification. Claiming tests pass requires test command output showing zero failures — a previous run or a "should pass" does not qualify. Claiming a build succeeds requires a build command that exits with code zero — linter output alone does not qualify, because a linter does not check compilation. Claiming a bug is fixed requires reproducing the original symptom and seeing it pass — changing the code and assuming it is fixed does not qualify. Claiming an agent completed a task requires checking the VCS diff for actual changes — the agent's own success report does not qualify.
Each of these failure modes has appeared in practice. Undefined functions reached production. Features shipped incomplete. Hours were spent on false completion before the work was redirected.
Regression tests and TDD
For regression tests specifically, "written a regression test" is not enough. The red-green cycle must be completed: write the test, run it and confirm it passes, revert the fix, run it again and confirm it fails, restore the fix, and run it a third time to confirm it passes again. A test that was never seen to fail has not demonstrated that it catches the bug it was written for.
Why this is non-negotiable
The skill cites 24 recorded failure cases that shaped the rule. Trust breaks when a human partner sees a completion claim that does not hold up. Rework is more expensive than the time saved by skipping verification. The rule admits no exceptions: not fatigue, not confidence, not a partial check that "covers the important cases."
Read what Datarim is for broader context, or see the related post on the v-ac-axis-split skill that governs evidence requirements at the specification level.