verification-before-completion

This skill is the gate between finished work and the sentence "it works". The check happens before the claim, not after someone challenges it.

Completion claims without applicable verification evidence do not get made. Applicable means the evidence covers this claim, this state and this scope — see OPS §3 for what keeps evidence valid.

The gate

1. Name the claim precisely. Which behavior, artifact or scope is claimed? "Tests pass" and "the suite passes on the merged tree" are different claims.
2. Name the evidence that can establish it. Use the table below; the claim and its evidence must be the same kind of thing.
3. Check whether valid evidence already exists for the current state. If it does, reuse it and cite its provenance rather than rerunning. If it does not, produce it.
4. Read the actual output or observation. Exit code, failure count, rendered result, probe response — not the command's success in general.
5. Claim only what the evidence shows. If it shows less than the claim, narrow the claim or report the gap. Both directions count: claiming a suite-wide green you did not run is dishonest, and rerunning an unchanged check with no new failure or concern is ceremony.

Evidence by claim type

Many checks do not end in an exit code.

Delete the claim's doubt by checking the smallest observation that can falsify it, not by adding unrelated checks.

When the evidence cannot be obtained

Unavailable is not passed, and it is not a failed check either. When the primary check cannot run — service down, environment missing, permission absent — report it as unavailable, name the prerequisite, and do not retry the same dead service in a loop.

A substitute check counts only if it proves the same contract. If it proves less, narrow the claim to what it does prove and report the required check as unavailable. A narrowed claim is honest; a promoted substitute is not.

Rationalizations

Red flags

Pause before the claim when you notice:

• "Should", "probably", "seems to" used as proof instead of a labeled uncertainty
• satisfaction language ("Done", "Perfect", "Great") before any check
• committing, pushing or opening a PR with no evidence for the final state
• trusting someone else's success report, including a subagent's
• extrapolating a partial result to the full claimed scope
• rationalizing that this case is special

Visible evidence patterns

Tests:      [run command] [0 failures] → "These tests pass on this revision"
Build:      [run build] [exit 0]      → "The build succeeds"
Bug fix:    [reproduce before] [recheck after] → "The reported symptom no longer reproduces"
Requirements: re-read request → checklist → verify each → report gaps or completion
Delegation: agent reports success → inspect artifacts → exercise behavior → report actual state

State provenance when reusing evidence (which state, which command, which result) so a later reader can tell what was and was not observed. Calibrated uncertainty is a valid report; it is not a substitute for the check.

Source: obra/superpowers (MIT). Adapted for coding-kit: cross-references made local.