Back to Workflow & Productivity
verification-before-completion
verificationtestingcode qualityworkflowquality assurancedeveloper disciplineci/cdevidence-based development
Install this skill
npx skills add obra/superpowersWorks across Claude Code, Cursor, Codex, Copilot & Antigravity
Verification Before Completion functions as an evidentiary gatekeeper for development workflows. It mandates that no claim of success, task completion, or operational stability be made without an immediate, fresh execution of a verifiable command. Instead of relying on assumptions, memory, or previous test states, users must identify the specific test or build command that validates their current claim, execute it, and inspect the raw output. This approach prioritizes factual evidence over confidence, preventing the common failure of shipping incomplete or broken code. By forcing a strict feedback loop between execution and reporting, this methodology eliminates misleading progress updates and ensures that all status declarations are backed by verifiable data. It demands intellectual honesty in every communication, treating unverified claims as non-existent until the terminal output proves otherwise.
When to Use This Skill
- β’Confirming a bug fix before submitting a pull request
- β’Validating build integrity after dependency updates
- β’Checking requirement coverage through a manual checklist against terminal output
- β’Auditing agent-generated code changes prior to final approval
How to Invoke This Skill
Example prompts that trigger this skill in Claude Code, Cursor, or Antigravity:
- βVerify the current build status before we proceed
- βDid the test suite pass correctly?
- βRun the validation command to confirm the bug is fixed
- βProvide evidence that the new requirements are met
- βConfirm completion of this task with output evidence
Pro Tips
- π‘Integrate specific verification commands into your project's pre-commit hooks to catch issues before they even reach version control.
- π‘Standardize verification commands in your project's `package.json` scripts or `Makefile` for easy, consistent execution across team members and agents.
- π‘Encourage your AI agent to not just run, but also interpret and summarize the output of verification commands, specifically highlighting failures or warnings rather than just stating pass/fail.
What this skill does
- β’Forces direct terminal execution before validating task completion
- β’Establishes a mandatory link between evidence and status reporting
- β’Eliminates reliance on outdated or stale build outputs
- β’Validates regressions through the mandatory red-green-red testing cycle
- β’Filters out subjective performance indicators in favor of objective exit codes
When not to use it
- βWhen initial setup or environment configuration is still in progress
- βDuring early-stage exploration where no objective pass/fail criteria are established yet
Example workflow
- Identify the specific command required to validate the feature
- Execute the command fresh within the current environment
- Inspect the raw output for successful exit codes or zero errors
- Compare the actual output against the expected success criteria
- Draft the status update citing the specific output data
- Submit the final confirmation of completion
Prerequisites
- βIdentifiable test or build commands
- βDefined criteria for what constitutes a passing state
Pitfalls & limitations
- !Mistaking passing tests for complete requirement satisfaction
- !Attempting to verify partial logic instead of the full application state
- !Falling back on 'should work' sentiments when tests yield unexpected results
FAQ
Does this mean I need to run tests every single time I check a box?
Yes. Any claim that a task is complete requires fresh evidence to prevent false positives.
Is my confidence enough if I am sure the code is perfect?
Confidence is not evidence. The protocol requires objective, terminal-based proof to validate any claim of correctness.
What happens if the tests pass but the feature is still broken?
This indicates your test coverage is insufficient, not that the verification protocol failed. You must then investigate why the current evidence fails to capture the issue.
Can I trust an agent's report that a build succeeded?
No. You must independently verify agent reports by executing the command yourself and inspecting the output logs.
How it compares
Unlike manual workflows that rely on developer intuition, this process creates an automated, immutable barrier that forces proof before communication, eliminating the bias of premature confidence.
π Full skill instructions β original source: obra/superpowers
# 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
If you haven't run the verification command in this message, you cannot claim it passes.
## The Gate Function
## 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:**
**Regression tests (TDD Red-Green):**
**Build:**
**Requirements:**
**Agent delegation:**
## 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.
## 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 EVIDENCEIf 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.
How to Use This Skill Unit
Option A: Project-Specific (Recommended)
- Click "Download" above
- In your project, create the directory:
.agent/skills/verification-before-completion/ - Save the file as
SKILL.md - The agent will automatically discover the skill based on its description.
Option B: Global Installation (All Agents)
Save the file to these locations to make it available across all projects:
- Claude Code:
~/.claude/skills/obra/superpowers/verification-before-completion/SKILL.md - Cursor:
~/.cursor/skills/obra/superpowers/verification-before-completion/SKILL.md - Antigravity:
~/.gemini/antigravity/skills/obra/superpowers/verification-before-completion/SKILL.md
π Install with CLI:npx skills add obra/superpowers
Recommended Rules
View more rules βPython Testing Best Practices
PythonTestingQuality Assurance
You are an expert in Python testing with pytest and testing best practices. Key Principles: - Write tests before or alongside code (TDD/BDD) - Aim fo...
Next.js Testing Strategies Expert
Next.jsTestingJest
You are an expert in Next.js testing strategies and best practices. Key Principles: - Test Server and Client Components differently - Use Jest for un...
TypeScript Testing with Vitest/Jest Expert
TypeScriptTestingVitest
You are an expert in TypeScript testing with Vitest and Jest. Key Principles: - Write type-safe tests - Use proper test typing - Mock with TypeScript...
Recommended Workflows
View more workflows βPre-Flight Check
CI/CDTestingBuild
--- description: Run type checking, linting, and build verification before pushing --- 1. **Type Check**: - Ensure there are no TypeScript errors....
E2E Testing Setup (Playwright)
TestingE2EPlaywright
--- description: Boilerplate setup for end-to-end testing --- 1. **Initialize Playwright**: - Run the init command. // turbo - Run `npm init...
Setup Prettier & ESLint from Scratch
ESLintPrettierCode Quality
--- description: Configure linting and formatting (ESLint 9 Flat Config) --- 1. **Install Dependencies**: - Install ESLint, Prettier, and configs....
