---

name: verification-patterns description: Evidence-based verification of completed work. Use when verifying task completion, confirming work is done, validating changes, or checking if a task is finished.

Verification Patterns

"The most impactful tip is: always ask Claude Code to verify it has completed the task." — Boris

Core Principle

Never trust "I've completed X" without evidence.

Verification means proving work is done, not just saying it is.

The Verification Protocol

Step 1: Identify Claims

What work was supposedly completed?

• Code changes made
• Bugs fixed
• Features added
• Tests written

Step 2: Define Evidence

For each claim, what would prove it?

Step 3: Gather Evidence

Copy# Check code changes
git diff --stat

# Run tests
npm test

# Verify build
npm run build

# Check behavior
curl http://localhost:3000/api/endpoint

Step 4: Report Results

For each claim:

• ✅ Verified with evidence
• ⚠️ Partially verified
• ❌ Not verified

Evidence Types

Code Evidence

• File diffs showing changes
• New files created
• Tests added

Runtime Evidence

• Tests passing
• Build succeeding
• Application running

Behavioral Evidence

• Feature works as expected
• Bug no longer reproducible

Verification Checklist

Copy### Code Changes
- [ ] Files modified as intended
- [ ] No unintended changes

### Tests
- [ ] All existing tests pass
- [ ] New tests added (if applicable)

### Build
- [ ] Build completes without errors

### Behavior
- [ ] Primary functionality works
- [ ] No regressions introduced

Anti-Patterns

"I've done it"

Bad: "I've added the login feature." Good: "Login feature added. Tests pass: 12/12. Login flow verified working."

"Should work"

Bad: "This should fix the bug." Good: "Bug fixed. Reproduced issue, applied fix, confirmed issue no longer occurs."

Remember

"Show me, don't tell me."