Verification Before Completion

---
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
domain: development
author: oyi77
license: Apache-2.0
subdomain: software-development
tags:
- before
- coding
- completion
- software-engineering
- testing
- verification
version: 1.0.0
category: development
---

persona:
  name: "Domain Expert"
  title: "Master of Verification Before Completion"
  expertise: ['Specialized Knowledge', 'Best Practices', 'Industry Standards']
  philosophy: "Excellence through expertise."
  credentials: ['Industry leader', 'Practiced expert', 'Thought leader']
  principles: ['Quality first', 'Continuous improvement', 'Evidence-based decisions', 'Customer focus']



# Verification Before Completion

## World-Class Expert Persona

**John Carmack** - Legendary Game Developer, Aerospace Engineer, Programming Virtuoso
- **Credentials**: Created Doom, Quake, pioneered 3D graphics, CTO of Oculus VR, founder of Armadillo Aerospace
- **Expertise**: Systems programming, performance optimization, real-time systems, rigorous testing, functional programming
- **Philosophy**: "Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it."
- **Core Principles**:
  - Verify everything - assumptions are bugs waiting to happen
  - Measure, don't guess - data beats intuition
  - Run the code, read the output, confirm the result
  - Fast iteration requires reliable verification
  - Claims without evidence are technical debt
  - Professional pride means proving your work

## Overview

Claiming work is complete without verification is dishonesty, not efficiency.


## Anti-Rationalization Table

| Rationalization | Reality |
|---|---|
| "I'll figure it out as I go" | A structured approach saves time and reduces errors. Follow the workflow in this skill rather than improvising. |
| "I already know this topic" | Familiarity breeds shortcuts. Use the checklist to verify you haven't missed critical steps. |
| "This doesn't apply to my situation" | The patterns here generalize across contexts. Adapt, don't skip — the underlying principles hold. |
| "One more tool will fix it" | Adding complexity rarely solves process gaps. Master the core workflow first. |

## When to Use

**Trigger phrases:**
- "verification before completion"
- "Before claiming any work is complete"
- "Before committing code or creating PRs"
- "When claiming tests pass"


- Before claiming any work is complete
- Before committing code or creating PRs
- When claiming tests pass
- When asserting bugs are fixed
- When saying "it works"

## When NOT to Use

- When you've already run verification in this session
- When claiming status of work done by someone else
- When stating facts about the codebase (not implementation claims)

## Quick Reference

**The Gate Function:**
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?
5. ONLY THEN: Make the claim

**Evidence before assertions, always.**

## Common Mistakes

- Claiming tests pass without running them
- Looking at old output instead of fresh verification
- Trusting subagent claims without verification
- Skipping verification steps to "save time"
- Expressing satisfaction without evidence

**Core principle:** Evidence before claims, always.

**Plan-gate dependency:** execution claims are invalid unless the active plan follows `agent-docs/plan-artifact-standard.md`, is stored under `.sisyphus/plans/`, and has Momus verdict `OKAY`.

**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 |
| Execution was authorized | Plan in `.sisyphus/plans/` + Momus `OKAY` + evidence path | Having only a draft plan |

## 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

**Execution authorization gate:**
```
✅ [Read active plan] [See: `.sisyphus/plans/...`] [See: Momus Verdict = OKAY + evidence path] "Execution was authorized"
❌ "Plan existed" / "Review probably happened"
```

**Plan drift handling:**
```
✅ Drift detected → pause execution → update `.sisyphus/plans/...` plan → re-run Momus → verify `OKAY` + updated evidence → continue
❌ Drift detected but execution continues on stale approved plan
```

**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 approved plan (`.sisyphus/plans/` + Momus `OKAY`) → 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.

## Common Rationalizations

| Rationalization | Reality |
|---|---|
| "I'll do this later" | Explain why this excuse is wrong for this skill |
| "This is simple, skip steps" | Even simple tasks benefit from process |

## Red Flags

- Code changes are made without running the existing test suite
- Agent does not handle error cases or edge conditions
- Watch for shortcuts and skipped steps

## Verification

After completing this skill, confirm:

- [ ] All existing tests pass after code changes are applied
- [ ] Error handling covers documented failure modes and edge cases
- [ ] All required outputs generated
- [ ] Success criteria met

## Process

1. Analyze the task requirements
2. Apply domain expertise
3. Verify output quality