Skip to content
Templates/Code Review
Code ReviewLow risk

Code Review Loop

Review a code change for correctness, safety, maintainability, and test coverage.

What this Loop Engineering template does

Produce a severity-ranked review of a code change with file and line references, changing no code unless asked.

Read the diff and its description. Stay read-only by default and rank issues by severity.

When to use it

Pre-merge review
Security and maintainability checks
Test-coverage review

When not to use it

Implementing the change
Approving your own work
Product sign-off

Validation checks

validation
Review report includes severity levels
Every blocking issue has file and line references
No code is changed unless explicitly requested

Boundaries & stop rule

!Read-only by default
!Do not auto-apply fixes
!Do not approve your own changes
Stop rule — Stop when the review covers correctness, safety, maintainability, and tests. If the change is too large to review safely, ask for it to be split and review the highest-risk part first.

Copy the loop prompt

claude-goal.txt
/goal Produce a severity-ranked review of a code change with file and line references, changing no code unless asked.
 
Work toward this goal until all validation checks pass or the stop rule is reached.
 
Loop cycle:
1. Discovery — Read the latest signal for this template before acting: CI output, issue detail, review comment, dataset report, or content brief.
2. Handoff — Hand the work to one agent in an isolated branch, worktree, or clearly scoped session. Keep final approval with a human.
3. Verification — Use an independent review pass to confirm the result, inspect the diff or artifact, and reject shortcut work.
4. Persistence — Save a short run note with the signal reviewed, actions taken, validation result, and next recommended step.
5. Scheduling — Run manually until the loop is reliable; only then consider a scheduled or event-triggered run.
 
Context:
Read the diff and its description. Stay read-only by default and rank issues by severity.
 
Validation:
Review report includes severity levels
Every blocking issue has file and line references
No code is changed unless explicitly requested
 
Independent checker:
Use an independent review pass to confirm the result, inspect the diff or artifact, and reject shortcut work.
 
Boundaries:
Read-only by default
Do not auto-apply fixes
Do not approve your own changes
 
Stop rule:
Stop when the review covers correctness, safety, maintainability, and tests.
Maximum iterations: 3
 
Budget:
Stop before exceeding the agreed per-run token budget.
 
Human approval:
Required before merge, deploy, delete, purchase, or external communication.
 
Fallback:
If the change is too large to review safely, ask for it to be split and review the highest-risk part first.
 
Do not delete tests, bypass checks, or modify unrelated files just to satisfy the validation condition. If blocked, stop and summarize the blocker, attempted fixes, and recommended next action.

Failure modes to watch

Reviewer rubber-stamps without reading
Reviewer edits the code it should review
Vague feedback with no file references
Self-approval

Loop Engineering FAQ

No, not by default. It is read-only and reports issues. Apply fixes in a separate maker loop so review and implementation stay independent.