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

# 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

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