---
name: verify-before-claim
description: Iron rule — no completion claims without fresh verification evidence. Use whenever about to claim work is done, fixed, working, or passing. Run verification commands and show output before making any success statement.
version: "1.2"
updated: "2026-05-23"
assumes: "A verifiable artifact, command, inspection, or evidence source exists for the claim."
conflicts_with: "Do not bypass because another skill produced a score, plan, or confidence statement."
---
# Verify Before Claim
**NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.**
## Usage Template
**Prompt**
```text
Use verify-before-claim. Before saying this is done, identify the proof command, run it fresh, read the output, and state the actual status with evidence.
```
**Use Case**
- Preventing unsupported claims that code, docs, tests, or workflows are fixed, passing, complete, or working.
**Expected Result**
- The agent reports command output, exit code, pass/fail count, and any remaining unverified risk.
**Output Example**
- `Command: npm test`, `Exit code: 0`, `Result: 42 passed, 0 failed`, plus residual risks.
**Verification Case**
- No completion language appears unless fresh evidence is shown in the same response.
**Verified Effect**
- The agent shifts from confidence-based status claims to evidence-based status reports.
## Success Metrics
- A fresh verification command or inspection is run in the current session.
- Output includes command, exit code or observable evidence, result, and residual risk.
- No completion claim is made when evidence is missing, stale, or failing.
## When to Use
- Before saying "done", "fixed", "complete", "passing", "working"
- Before committing or creating a PR
- Before expressing satisfaction with results
- When the user asks "is it working?"
- Any time the agent feels the urge to say "it should work"
## The Gate Function
```
BEFORE claiming any status:
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 output: 0 failures | Previous run, "should pass" |
| Linter clean | Linter output: 0 errors | Partial check |
| Build succeeds | Build exit code 0 | "Looks good" |
| Bug fixed | Reproduce original symptom: passes | "I changed the code" |
| Tests added | New tests exist + old tests still pass | "Tests should work" |
| Vendor/product claim | Official docs, changelog, or independent source; otherwise mark single-source | Keynote/demo statement alone |
| Agent can act for user | Mandate, tool log, preview/confirmation, receipt, rollback path | "User asked generally" |
| Generated media is safe/provenanced | Source/prompt/edit record and disclosure or watermark path | "Looks AI-generated" |
## Red Flags — STOP
- Using "should", "probably", "seems to" about completion
- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!")
- About to commit/push/PR without verification
- Trusting agent success reports without independent check
- Relying on partial verification
## Expected Value Thinking (From Poker Psychology)
> "The biggest bluff is convincing yourself you have control when you don't." — Maria Konnikova
**Apply to verification:**
| Poker Concept | Verification Application |
|---------------|-------------------------|
| **Expected Value (EV)** | Don't just check if it works now; check if it will work reliably |
| **Controllable vs Uncontrollable** | Focus on what you can verify; acknowledge what you can't |
| **Tilt Control** | Don't let excitement about "it works!" skip verification |
| **Process over Results** | Good verification process > lucky outcome |
**The verification mindset:**
```
1. Separate what you CAN verify from what you CAN'T
- CAN: Code compiles, tests pass, output matches expected
- CAN'T: Edge cases, production behavior, user experience
2. Focus on EXPECTED VALUE, not single results
- "Tests pass once" ≠ "Tests will pass reliably"
- "Works in my environment" ≠ "Works in all environments"
3. Be skeptical of success
- Good decisions can have bad outcomes
- Bad decisions can have good outcomes
- KEY: Evaluate the PROCESS, not just the result
```
## Single-Source Product Claims
Keynotes, launch posts, demos, and roadmap statements can be useful evidence, but they are not enough for operational guidance. When the only source is a vendor statement:
```text
Status: single-source
Source type: keynote / launch post / docs / independent test
Operational risk:
What must be verified next:
```
Do not turn a demo into a guarantee. Treat availability, scale numbers, benchmark claims, payment protocols, security properties, and adoption figures as unverified until checked.
**The Biggest Lesson from Poker:**
> "Knowing when to fold is more important than knowing when to play."
In verification: Knowing when to say "I'm not sure" is better than claiming "it works" without evidence.
- **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 |
| "Different context so rule doesn't apply" | Spirit over letter |
## SOP TDD Context
This skill is the verification component of the TDD-for-SOPs approach. Before writing a new SOP:
1. **Define failure**: What will the agent do wrong without the SOP?
2. **Watch it fail**: Verify the baseline error exists (RED)
3. **Write the SOP**: Address those specific failure modes
4. **Watch it pass**: Verify the agent now complies (GREEN)
5. **Refactor**: Close loopholes while maintaining compliance
## Quality Gates
- [ ] Verification command identified and run
- [ ] Full output shown (exit code, failure count)
- [ ] Claim only made WITH evidence
- [ ] No "should", "probably", "I think" on completion status
- [ ] Vendor/demo/product claims are marked single-source unless independently verified
- [ ] Delegated user actions have mandate, receipt, and rollback evidence