verification-before-completion
obra/superpowers
Run verification commands and confirm output before claiming work is complete—evidence before assertions always.
What is verification-before-completion?
This skill enforces a discipline of running actual verification commands and reading their output before making any claims about work being complete, fixed, or passing. Use it whenever you're about to commit, create a PR, or declare a task done to prevent false completion claims and maintain honest communication.
- Requires executing full verification commands fresh before any success claims
- Enforces reading complete output and exit codes rather than relying on assumptions
- Prevents common failures like trusting partial checks, agent reports, or "should work" reasoning
- Provides a gate function: identify verification command → run it → read output → verify claim matches evidence
- Catches red flags like expressing satisfaction before verification or committing without fresh evidence
How to install verification-before-completion
npx skills add https://github.com/obra/superpowers --skill verification-before-completionHow to use verification-before-completion
- 1.Before claiming any status or expressing satisfaction, identify what command proves your claim
- 2.Execute the full verification command fresh (not from memory or previous runs)
- 3.Read the complete output, check the exit code, and count any failures or errors
- 4.Verify that the output actually confirms your claim—if not, state the actual status with evidence instead
- 5.Only after confirmation, make your claim and include the evidence in your communication
Use cases
- Before committing code changes, run the full test suite and confirm zero failures in output
- Before creating a PR, execute the build command and verify exit code 0 rather than assuming linter passing means build succeeds
- Before claiming a bug is fixed, run the original failing test to confirm it now passes
- Before delegating work to an agent, verify the agent's reported success by checking the actual VCS diff and running verification independently
- Before moving to the next task, re-read requirements and verify each one against actual test output or checklist
- Developers committing code or creating pull requests
- Anyone delegating work to AI agents and needing to verify results
- Teams that value honest communication and preventing false completion claims
- Engineers working in safety-critical or high-stakes codebases where unverified claims cause real damage
verification-before-completion FAQ
Confidence is not evidence. You must run the verification command and read its output. No exceptions, even if you're tired or in a hurry.
No. Linter passing and build success are different verification steps. You must run the actual build command and confirm exit code 0.
No. Verify independently by checking the VCS diff and running verification commands yourself. Agent reports are not evidence.
A command that directly tests your claim: test suite for "tests pass", build command for "build succeeds", running the original failing test for "bug fixed". Partial checks do not count.
Partial verification proves nothing. You must run the complete verification command and confirm the full output before making any claim.
Full instructions (SKILL.md)
Source of truth, from obra/superpowers.
name: verification-before-completion description: 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
Verification Before Completion
Overview
Claiming work is complete without verification is dishonesty, not efficiency.
Core principle: Evidence before claims, always.
Violating the letter of this rule is violating the spirit of this rule.
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.
The Gate Function
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
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 original symptom: passes | Code changed, assumed fixed |
| Regression test works | Red-green cycle verified | Test passes once |
| Agent completed | VCS diff shows changes | Agent reports "success" |
| Requirements met | Line-by-line checklist | Tests passing |
Red Flags - STOP
- Using "should", "probably", "seems to"
- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
- About to commit/push/PR without verification
- Trusting agent success reports
- Relying on partial verification
- Thinking "just this once"
- Tired and wanting work over
- ANY wording implying success without having run verification
Rationalization Prevention
| Excuse | Reality |
|---|---|
| "Should work now" | RUN the verification |
| "I'm confident" | Confidence ≠ evidence |
| "Just this once" | No exceptions |
| "Linter passed" | Linter ≠ compiler |
| "Agent said success" | Verify independently |
| "I'm tired" | Exhaustion ≠ excuse |
| "Partial check is enough" | Partial proves nothing |
| "Different words so rule doesn't apply" | Spirit over letter |
Key Patterns
Tests:
✅ [Run test command] [See: 34/34 pass] "All tests pass"
❌ "Should pass now" / "Looks correct"
Regression tests (TDD Red-Green):
✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
❌ "I've written a regression test" (without red-green verification)
Build:
✅ [Run build] [See: exit 0] "Build passes"
❌ "Linter passed" (linter doesn't check compilation)
Requirements:
✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
❌ "Tests pass, phase complete"
Agent delegation:
✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
❌ Trust agent report
Why This Matters
From 24 failure memories:
- your human partner said "I don't believe you" - trust broken
- Undefined functions shipped - would crash
- Missing requirements shipped - incomplete features
- Time wasted on false completion → redirect → rework
- Violates: "Honesty is a core value. If you lie, you'll be replaced."
When To Apply
ALWAYS before:
- ANY variation of success/completion claims
- ANY expression of satisfaction
- ANY positive statement about work state
- Committing, PR creation, task completion
- Moving to next task
- Delegating to agents
Rule applies to:
- Exact phrases
- Paraphrases and synonyms
- Implications of success
- ANY communication suggesting completion/correctness
The Bottom Line
No shortcuts for verification.
Run the command. Read the output. THEN claim the result.
This is non-negotiable.
Related skills
More from obra/superpowers and the wider catalog.
brainstorming
Explore user intent and design before implementation—mandatory first step for any creative work.
systematic-debugging
Find root cause before fixing—systematic debugging prevents wasted effort and masked problems.
writing-plans
Create detailed implementation plans for multi-step tasks before writing code.
using-superpowers
Establish skill-first workflow—invoke relevant skills before any response, even with 1% applicability.
requesting-code-review
Dispatch a code reviewer subagent to catch issues before they cascade.
test-driven-development
Write tests first, watch them fail, then implement—the disciplined way to build reliable code.