Verification Before Completion
Core Principle: No completion claims without fresh verification evidence.
Unverified claims break trust and ship broken code: undefined functions that crash production, incomplete features missing requirements, lost time on rework after false completion. The cost of running one command is trivial compared to the cost of a wrong claim.
The Verification Gate
Before any claim of success, completion, or satisfaction:
- IDENTIFY - What command proves this claim?
- RUN - Execute the full verification command (fresh, complete)
- READ - Check full output, exit code, failure counts
- VERIFY - Does output confirm the claim?
- NO - State actual status with evidence
- YES - State claim WITH evidence from step 2-3
When This Applies
Before:
- Claiming "tests pass", "build succeeds", "linter clean", "bug fixed"
- Expressing satisfaction ("Great!", "Done!", "Perfect!")
- Using qualifiers ("should work", "probably fixed", "seems to")
- Committing, creating PRs, marking tasks complete
- Marking a multi-file implementation as complete (dispatch
ce:code-reviewer agent)
- Moving to next task or delegating work
Common Verification Requirements
| Claim |
Required Evidence |
Not Sufficient |
| Tests pass |
yarn test output: 0 failures |
Previous run, "looks correct" |
| Build succeeds |
Build command: exit 0 |
Linter clean, "should work" |
| Bug fixed |
Test reproducing bug: now passes |
Code changed, assumed fix |
| Linter clean |
Linter output: 0 errors |
Partial check, spot test |
| Regression test works |
Red→Green cycle verified |
Test passes once |
| Agent task complete |
VCS diff shows expected changes |
Agent reports "success" |
| Work is complete |
Code review via ce:code-reviewer with no unresolved Critical issues |
Self-review, "looks good to me" |
Red Flags
Stop and verify if you're about to:
- Use hedging language ("should", "probably", "seems to")
- Express satisfaction before running verification
- Trust agent/tool success reports without independent verification
- Rely on partial checks or previous runs
Key Examples
Regression test (TDD Red-Green):
Write test → Run (fail) → Fix code → Run (pass) → Revert fix → Run (fail) → Restore → Run (pass)
vs. "I've written a regression test" (without verifying red-green cycle)
Build vs Linter:
Run `npm run build` → See "exit 0" → Claim "build passes"
vs. Run linter → Claim "build will pass" (linter ≠ compiler)
Agent delegation:
Agent reports success → Check `git diff` → Verify changes → Report actual state
vs. Trust agent's success message without verification
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: verification-before-completion-253description: Run verification commands before claiming work is complete or fixed. Use before asserting any task is done, bug is fixed, tests pass, or feature works. Use when this capability is needed.4---56# Verification Before Completion78**Core Principle:** No completion claims without fresh verification evidence.910Unverified claims break trust and ship broken code: undefined functions that crash production, incomplete features missing requirements, lost time on rework after false completion. The cost of running one command is trivial compared to the cost of a wrong claim.1112## The Verification Gate1314Before any claim of success, completion, or satisfaction:15161. **IDENTIFY** - What command proves this claim?172. **RUN** - Execute the full verification command (fresh, complete)183. **READ** - Check full output, exit code, failure counts194. **VERIFY** - Does output confirm the claim?20 - NO - State actual status with evidence21 - YES - State claim WITH evidence from step 2-32223## When This Applies2425Before:2627- Claiming "tests pass", "build succeeds", "linter clean", "bug fixed"28- Expressing satisfaction ("Great!", "Done!", "Perfect!")29- Using qualifiers ("should work", "probably fixed", "seems to")30- Committing, creating PRs, marking tasks complete31- Marking a multi-file implementation as complete (dispatch `ce:code-reviewer` agent)32- Moving to next task or delegating work3334## Common Verification Requirements3536| Claim | Required Evidence | Not Sufficient |37| --------------------- | -------------------------------- | ----------------------------- |38| Tests pass | `yarn test` output: 0 failures | Previous run, "looks correct" |39| Build succeeds | Build command: exit 0 | Linter clean, "should work" |40| Bug fixed | Test reproducing bug: now passes | Code changed, assumed fix |41| Linter clean | Linter output: 0 errors | Partial check, spot test |42| Regression test works | Red→Green cycle verified | Test passes once |43| Agent task complete | VCS diff shows expected changes | Agent reports "success" |44| Work is complete | Code review via `ce:code-reviewer` with no unresolved Critical issues | Self-review, "looks good to me" |4546## Red Flags4748Stop and verify if you're about to:4950- Use hedging language ("should", "probably", "seems to")51- Express satisfaction before running verification52- Trust agent/tool success reports without independent verification53- Rely on partial checks or previous runs5455## Key Examples5657**Regression test (TDD Red-Green):**5859```60Write test → Run (fail) → Fix code → Run (pass) → Revert fix → Run (fail) → Restore → Run (pass)61vs. "I've written a regression test" (without verifying red-green cycle)62```6364**Build vs Linter:**6566```67Run `npm run build` → See "exit 0" → Claim "build passes"68vs. Run linter → Claim "build will pass" (linter ≠ compiler)69```7071**Agent delegation:**7273```74Agent reports success → Check `git diff` → Verify changes → Report actual state75vs. Trust agent's success message without verification76```7778---79> Converted and distributed by [TomeVault](https://tomevault.io/claim/rileyhilliard) — claim your Tome and manage your conversions.80<!-- tomevault:4.0:skill_md:2026-04-11 -->
tomevault-io