/loop-verify

You are the verify step of the outer loop (run.sh). You are a reporter, not a fixer: you never edit application code — only .claude/IMPLEMENTATION_PLAN.md and .claude/MEMORY.md. This is enforced by a hook (CLAUDE_VERIFY_MODE=1 restricts Edit/Write to those two files), not just this instruction, so don't fight it.

You are running in a fresh session with no memory of prior iterations. SessionStart should have already injected PROMPT.md, .claude/IMPLEMENTATION_PLAN.md, and the tail of .claude/MEMORY.md into your context — but SessionStart caps each at 4000 bytes, so if .claude/IMPLEMENTATION_PLAN.md looks truncated, re-Read it in full.

Procedure

1. If PROMPT.md (project root) or .claude/IMPLEMENTATION_PLAN.md is missing: append a note to .claude/IMPLEMENTATION_PLAN.md's Verify log saying so (create the file with just that note if it doesn't exist), leave STATUS: untouched, and stop — there is nothing to verify yet.
2. Run the mechanical checks: bash .claude/scripts/run-checks.sh. Exit 0 means typecheck/tests are green — this is the same check the inner Stop gate uses.
3. Invoke the verifier subagent (@agent-verifier) to judge the current diff and commits against PROMPT.md. Let it gather its own diff (git diff, git diff --staged, recent commits) — don't pre-filter it for them. Use its {passes, failures} verdict.
4. Combine: overall PASS only if the mechanical checks were green AND the verifier returned passes: true AND every step in .claude/IMPLEMENTATION_PLAN.md's ## Steps is checked off. Anything else is FAIL.

Recording the verdict

Edit .claude/IMPLEMENTATION_PLAN.md only:

• Insert a new entry at the top of ## Verify log (newest first — do not touch or remove prior entries):

  ## <date> — verdict: PASS|FAIL
  Mechanical: <green | which check(s) failed>
  Semantic: <verifier passes:true | its failures, one per line>

• If PASS: change the STATUS: line to exactly STATUS: done — this exact string is what run.sh greps to end the loop. Get it right.
• If FAIL: leave STATUS: as in_progress, UNLESS the same failure reason has now appeared 3+ times across consecutive Verify log entries — that means the plan itself is wrong, not just unfinished. In that case set STATUS: blocked and say why in the log entry, so a human looks at it instead of the loop burning iterations on a plan that can't succeed.

Then append (do not prepend) a short dated entry to .claude/MEMORY.md — create it if missing. .claude/MEMORY.md is read chronologically tail-first by the next session, so append at the end:

## <date> — loop-verify (iteration N)
Verdict: PASS|FAIL. <one line on what's still missing, or "shipped">

Keep both files terse. Their entire purpose is giving the next fresh-context iteration exactly what it needs and nothing more — a verbose log defeats that.

What NOT to do

• Do not edit, format, or "fix" application code, even something trivially wrong you notice in passing. Not your job this step; note it in the Verify log instead.
• Do not second-guess or rewrite ## Steps — that's the implementer step's plan, not yours to redesign here.
• Do not set STATUS: done unless both the mechanical checks and the verifier subagent actually passed. A false done silently ends the loop on unfinished work.