Verification Before Completion

Verification Before Completion

Discipline for proving work is done rather than asserting it. Every completion claim must be backed by captured output from verification commands executed in the current session. This skill exists because the most expensive bugs are not the ones that fail loudly — they are the ones that ship behind a confident "it works."

Iron Law

No "done" without evidence. Assertions are not evidence.

If you have not run a verification command and read its output in this session, you cannot claim the work passes. "Should work" is not a status. "I believe it's correct" is not a test result. The only acceptable proof is captured output from an executed command.

Why This Matters

False completion is more costly than incomplete work. Incomplete work is visible — someone will finish it. False completion is invisible — it passes review, merges, deploys, and fails in production. Every minute spent on proper verification saves hours of debugging, rollback, incident response, and trust repair. The cost of catching a defect multiplies by orders of magnitude at each stage: local development, code review, staging, production. Verify early, verify often, verify with evidence.

Core Principles

Tiered Definition of Done

Work passes through multiple tiers before it is truly done. Each tier has its own evidence requirements. See done-definitions for the full breakdown.

The Verification Cycle

Run this cycle before every completion claim.

Phase 1: Identify Verification Surface

Determine what needs to be verified based on what changed.

• List every file modified, added, or deleted
• Map each change to its verification category (code, config, schema, docs, infra)
• Identify the minimum set of commands that covers all changed surfaces
• If unsure what to verify, verify everything — over-verification costs minutes, under-verification costs hours

Phase 2: Run Verification Commands

Execute every required command. Do not skip any.

• Run commands in the project root unless they require a specific directory
• Use the project's own scripts and configuration — do not invent custom verification
• Run the full suite, not a subset, unless the full suite takes more than 5 minutes (then run targeted + note that full suite is deferred)
• Capture both stdout and stderr

Phase 3: Capture Output

Record the raw output from every command.

• Include the exact command that was run
• Include the full output (or the summary section for large outputs)
• Include the exit code
• Timestamp is implicit in the current session — do not fabricate timestamps

Phase 4: Compare to Expected

Verify that the output matches success criteria.

• All tests pass (zero failures, zero errors, zero skipped unless pre-existing)
• Zero lint errors (zero warnings for strict projects)
• Type checker reports zero errors
• Build exits with code 0 and produces expected artifacts
• If any check fails, the work is NOT done — fix the issue and restart from Phase 2

Phase 5: Cite Evidence in Claim

Reference the captured output when claiming completion.

• State which commands were run
• State the result of each (pass count, exit code, key output lines)
• If any caveats exist (pre-existing failures, skipped checks, known issues), state them explicitly
• Never use language that hides uncertainty — see Language to Avoid

What Counts as Evidence

See evidence-patterns for the complete reference.

Verification by Task Type

Different changes require different verification. See verification-checklist for complete checklists per task type.

Common Fake-Completion Patterns

See failure-modes for the full catalog.

Language to Avoid

Quality Checklist

Before claiming any work is complete:

• All modified files are identified
• Verification commands are identified for each change type
• Every verification command has been run (not recalled from memory — run fresh)
• Output from every command is captured and visible
• All tests pass with zero failures
• Linter reports zero errors
• Type checker reports zero errors (if applicable)
• Build succeeds with exit code 0 (if applicable)
• No untracked or uncommitted files that should be included
• No language from the "Language to Avoid" table appears in the completion claim
• Any caveats, known issues, or deferred checks are explicitly stated
• Evidence is cited, not asserted

Critical Rules

1. Run before you claim. Every verification command must be executed in the current session. Output from a previous session, a previous branch, or a previous version of the code is not evidence.

2. Capture everything. Paste output, do not paraphrase it. "Tests pass" is a claim. "Ran cargo test, 89 passed, 0 failed" is evidence.

3. Check exit codes. A command that prints friendly output but exits non-zero has failed. Always verify the exit code, not just the log output.

4. Full suite, not cherry-picked. Run the complete test suite, not just the tests for the file you changed. Your change may break something elsewhere.

5. No self-certification. "I verified it" without captured output is worth zero. The evidence must be visible to anyone reading the completion claim.

6. Caveats are mandatory. If any check was skipped, any test was ignored, or any known issue remains, state it explicitly. Hidden caveats are lies by omission.

7. Failures mean not done. If any verification command fails, the work is not complete. Fix the failure and re-run. There is no "done except for that one failing test."

8. Fresh over stale. If you made any change after the last verification run — even a one-character fix — re-run all verification. The last change is the one that breaks things.

9. Verification is not optional overhead. It is the work. Code without verification is a draft, not a delivery.

10. When in doubt, verify more. Over-verification wastes minutes. Under-verification wastes days.

Reference Files

Integration with Other Skills