Verification before completion

Claiming work is complete without verification is dishonesty, not efficiency. The verification-before-completion skill enforces a single rule: run the command, read the output, then claim the result.

When this skill fires

The skill description reads: “Use when about to claim work is complete, fixed, or passing, before committing or creating PRs — requires running verification commands and confirming output before making any success claims; evidence before assertions always.” It fires before:

Any variation of success or completion claims
Any expression of satisfaction (“Done!”, “Perfect!”, “Great!”)
Committing, creating PRs, or marking tasks complete
Moving to the next task
Delegating to agents

What it does

The skill enforces a gate function that must be completed before any claim:

BEFORE claiming any status or expressing satisfaction:

1. IDENTIFY: What command proves this claim?
2. RUN: Execute the FULL command (fresh, complete)
3. READ: Full output, check exit code, count failures
4. VERIFY: Does output confirm the claim?
   - If NO: State actual status with evidence
   - If YES: State claim WITH evidence
5. ONLY THEN: Make the claim

Skip any step = lying, not verifying

The iron law

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

If you haven’t run the verification command in this message, you cannot claim it passes.

Common failures

Claim	Requires	Not sufficient
Tests pass	Test command output: 0 failures	Previous run, “should pass”
Linter clean	Linter output: 0 errors	Partial check, extrapolation
Build succeeds	Build command: exit 0	Linter passing, logs look good
Bug fixed	Test for original symptom: passes	Code changed, assumed fixed
Requirements met	Line-by-line checklist against plan	Tests passing
Agent completed	VCS diff shows changes	Agent reports “success”

Key patterns

Tests
Regression tests
Build
Requirements
Agent delegation

✅ [Run test command] → [See: 34/34 pass] → "All tests pass"
❌ "Should pass now" / "Looks correct"

For TDD red-green verification:

✅ Write test → Run (pass) → Revert fix → Run (MUST FAIL) → Restore fix → Run (pass)
❌ "I've written a regression test" (without red-green verification)

✅ [Run build] → [See: exit 0] → "Build passes"
❌ "Linter passed" (linter does not check compilation)

✅ Re-read plan → Create checklist → Verify each item → Report gaps or completion
❌ "Tests pass, phase complete"

✅ Agent reports success → Check VCS diff → Verify changes exist → Report actual state
❌ Trust the agent's report at face value

Red flags — stop

Stop before making any claim if you notice:

Using “should”, “probably”, or “seems to”
Expressing satisfaction before verification
About to commit or create a PR without running verification
Trusting an agent’s success report without checking the diff
Relying on a partial verification
Thinking “just this once”

Rationalization prevention

Excuse	Reality
”Should work now”	Run the verification
”I’m confident”	Confidence is not evidence
”Just this once”	No exceptions
”Linter passed”	Linter is not a compiler
”Agent said success”	Verify independently
”I’m tired”	Exhaustion is not an excuse
”Partial check is enough”	Partial proves nothing

Example scenario

You’ve just fixed a bug in the authentication service. Before saying “fixed”, the verification-before-completion skill requires you to:

Identify the verification command: npm test src/auth/
Run it: npm test src/auth/
Read the output: 18/18 tests passed, 0 failures
Verify: yes, the output confirms the claim
Make the claim: “Bug fixed. npm test src/auth/ shows 18/18 tests passing including the new regression test for empty email validation.”

Not: “Should be fixed now” or “I think that covers it.”

Test-driven development

Provides the tests that verification-before-completion runs to confirm work is done.

Systematic debugging

After a fix, verification-before-completion confirms the fix actually resolved the issue.

Get Started

The Workflow

Skills

Commands

Agents

Configuration

Verification before completion

When this skill fires

What it does

The iron law

Common failures

Key patterns

Red flags — stop

Rationalization prevention

Example scenario

Test-driven development

Systematic debugging

​When this skill fires

​What it does

​The iron law

​Common failures

​Key patterns

​Red flags — stop

​Rationalization prevention

​Example scenario

​Related skills

Test-driven development

Systematic debugging

When this skill fires

What it does

The iron law

Common failures

Key patterns

Red flags — stop

Rationalization prevention

Example scenario

Related skills