verification-before-completion

name	verification-before-completion
description	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.

Verification Before Completion

Core Principle: No completion claims without fresh verification evidence.

The Verification Gate

BEFORE any claim of success, completion, or satisfaction:

Copy this checklist and track your progress:

Verification Checklist:
- [ ] IDENTIFY: What command proves this claim?
- [ ] RUN: Execute the verification command (fresh, complete)
- [ ] READ: Check full output, exit code, failure counts
- [ ] VERIFY: Does output confirm the claim?
  - If NO → State actual status with evidence
  - If YES → State claim WITH evidence

1. IDENTIFY - What command proves this claim?
2. RUN - Execute the full verification command (fresh, complete)
3. READ - Check full output, exit code, failure counts
4. VERIFY - Does output confirm the claim?
   • NO → State actual status with evidence
   • YES → State claim WITH evidence from step 2-3

Skip any step = invalid claim.

When This Applies

ALWAYS 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
• Moving to next task or delegating work
• ANY statement implying success or completion

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"

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
• Think "just this once" or "I'm confident it works"

Key Examples

Regression test (TDD Red-Green):

✅ Write test → Run (fail) → Fix code → Run (pass) → Revert fix → Run (MUST fail) → Restore → Run (pass)
❌ "I've written a regression test" (without verifying red-green cycle)

Build vs Linter:

✅ Run `npm run build` → See "exit 0" → Claim "build passes"
❌ Run linter → Claim "build will pass" (linter ≠ compiler)

Agent delegation:

✅ Agent reports success → Check `git diff` → Verify changes → Report actual state
❌ Trust agent's success message without verification

Why It Matters

Unverified claims break trust and ship broken code:

• Undefined functions that crash production
• Incomplete features missing requirements
• Lost time on rework after false completion
• Partner distrust: "I don't believe you"

Violating this skill violates core honesty requirements.

No Exceptions

Run the command. Read the output. THEN claim the result.

Evidence before assertions, always.