Verify

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.

Flow

Step 1: Gather Context

Before launching the agent, collect from the current conversation:

• The approved plan (and Design Doc if any)
• The list of changed files
• The project-level CLAUDE.md path (if known)

Step 2: Launch Agent

Use the Agent tool to launch the implementation-verifier agent with the gathered context. Include in the prompt:

• The plan or Design Doc content (or note that none exists)
• The scope of changes (changed files, relevant modules)
• The project root path

Step 3: Present Results

When the agent completes, present its verification report to the engineer.

Apply the Iron Law to the agent's report: if the agent claims success, do not propagate the claim — verify by checking the actual evidence (test output, build exit code, diff). Trust the evidence, not the report.

If deviations from the plan or readability suggestions are found, ask the engineer how to proceed.

Step 4: Transition

After verification passes and the engineer reviews the report:

→ Transition to /review for comprehensive code review.

If verification fails:

→ Return to /execute-plan (or restart agent-teams for the failing task) to fix issues, then re-run /verify.

Common Failures

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, requirements met"

Agent delegation:

✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
❌ Trust agent report

Red Flags - STOP

• Using "should", "probably", "seems to" about verification results
• Expressing satisfaction before verification ("Great!", "Perfect!", "Done!")
• About to report completion without fresh verification
• Trusting a previous run's results
• Trusting the implementation-verifier agent's success report without checking evidence
• Relying on partial verification
• Thinking "just this once"
• Tired and wanting work over
• ANY wording implying success without having run verification

Rationalization Prevention

When To Apply

The Iron Law applies broadly — not just within /verify, but 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

The /verify skill is the formal application of this principle for post-implementation verification.

Important Rules

• Always gather context before launching the agent — the agent runs in isolation and cannot access the current conversation history.
• If no plan or Design Doc exists in the current conversation, tell the agent to skip the diff review and readability check steps.
• Do not re-run the agent unless the engineer requests it after making fixes.
• The engineer's review is a mandatory gate. Verification passing does not mean the work is done — the engineer must review.

The Bottom Line

No shortcuts for verification.

Run the command. Read the output. THEN claim the result.

This is non-negotiable.