verification-before-completion

Verification before completion means identifying the specific command that proves your claim—like running tests or linting—executing it in full, reading the complete output and exit status, and confirming the results match your assertion before committing or reporting success. This prevents false completion claims and ensures evidence backs every status update.

Assuming relies on confidence or reasoning; verification runs fresh evidence. Before claiming a bug fix, run the exact test that reproduces the bug, confirm it passes with full output visible, and only then state the fix works. This discipline eliminates rework and builds trust in your reporting.

No. Verification is a gate function applied wherever success or completion is declared—code changes, tests, builds, lint checks, and deployment steps. The workflow identifies the verification command for each step, runs it completely, reads the full output, and confirms alignment before the claim stands.

This Skill explicitly counters rationalization. Phrases like "should," "probably," or "seems to" signal you haven't run verification yet. The gate function requires fresh command execution and output proof—not intuition—before any completion claim, eliminating excuses for skipping the verification step.

Partial verification doesn't count. You must run the full command, check all exit codes, and count total pass/fail results. Only after the complete command executes and output confirms your claim in full can you assert completion. Partial runs create false confidence and hidden bugs.

Report the actual state shown in the command output and exit code, not your original claim. If tests fail, lint errors surface, or builds break, state what the verification output reveals. This honest reporting prevents cascading rework and keeps the workflow accurate.