Review

Find defects that can change the result or make the change unsafe. Do not turn personal taste into a finding.

Use a fresh subagent that did not implement the change. Stay read-only. Do not edit files or post comments.

Scope

Review the implementation target named by the user. It may be a file, diff, branch, commit, pull request, or other code change on GitHub. Use /architecture-review for a technical proposal that has not been implemented.

If the user does not name a target, review the repository's complete local change set. Include commits on the current branch relative to the default branch, staged changes, unstaged changes, and untracked files.

Use the repository and the immediate surrounding code as context. If there are no local changes, say so. Do not substitute a whole-repository audit.

Standard

Approve only when:

• The change matches its source and behaves as required.
• No known defect or unhandled risk could break the source or repository rules for security, data loss, compatibility, or operations.

Do not demand perfection or block on personal taste. Cite technical evidence or repository conventions.

The verdict is independent agent evidence. It is not GitHub approval or a replacement for human review.

Review order

1. Set the frame. Give the reviewer the task, acceptance criteria and invariant IDs from its task or design, repository rules, complete diff or pull request, and test evidence. Name the user or developer affected by the change.
2. Take the broad view. Read the change summary and the relevant design or ticket. Confirm that the change belongs in the system, matches the intended behavior, and delivers one reviewable outcome. Report a mismatch before reviewing details.
3. Review the main behavior. Start with the files and flows that deliver the outcome. Check behavior, failures, security boundaries, interfaces, compatibility, migrations, concurrency, and operations.
4. Review every human-written changed line in context. Read enough surrounding code to judge correctness, regressions, complexity, names, comments, style, and docs. For generated files or large data, inspect the source and spot-check the output. Keep findings within the change's scope.
5. Review the proof. Check that tests:
   • Cover the changed behavior and affected failure paths.
   • Prove every cited AC-n, INV-n, or task criterion.
   • Assert behavior a user or caller can observe, or a documented internal contract.
   • Would fail under a broken implementation.
   • Do not copy implementation logic or hide the scenario in setup.
6. Run focused checks that can confirm or disprove a claim that could change a finding or verdict.
7. Check specialist coverage. Identify security, privacy, concurrency, accessibility, internationalization, or domain-specific work. Mark a risk unverified when the reviewer lacks the evidence or skill to judge it. Use Blocked when that gap could hide a problem that breaks a rule and no qualified reviewer covers it.
8. Report findings. Return actionable findings in priority order using the format below.

Code review findings

Report only real bugs, customer-impacting problems, and proven simplifications introduced or exposed by the change. Check security, logic, behavior, reliability, compatibility, regressions, and affected failure paths.

Inspect enough surrounding code to prove each finding. A simplification must deliver the same result and proof with less state, indirection, duplication, or operational work. Report it only as Could fix.

Use this format for every finding:

Priority: Must fix / Should fix / Could fix
Confidence: 0 to 5
What I found: Describe the technical problem.
Why it matters: Explain the impact on customers, callers, or the service.
Trigger and effect: State the exact condition and what the customer or service experiences.
Where: File and line.
Suggested fix: Give a short, practical direction.

Priority means:

• Must fix: Unsafe to merge. The change can cause a security failure, data loss, broken required behavior, or a serious service regression.
• Should fix: A real defect or reliability risk that should be corrected before merge.
• Could fix: A proven, limited problem or simplification that does not need to block merge. Do not use this for style preferences.

Confidence means:

• 5: Confirmed by reproduction, test, or direct code evidence.
• 4: Strong evidence with no credible alternative explanation.
• 3: Probable, but some runtime evidence is unavailable.
• 0 to 2: Do not report. Investigate further or mark the area unverified.

Use plain words. State what breaks, when it breaks, and who it affects. Omit style preferences, theoretical concerns, and problems outside the change.

Verdict

If fresh subagents are unavailable, stop and report that independent review is blocked unless the user explicitly accepts a documented self-review.

If there are no findings, say so. End with Approve, Request changes, or Blocked, then state what remains unverified. A Must fix or Should fix finding requires Request changes. Could fix findings do not prevent Approve.

Boundaries

• Keep findings within the change, but inspect enough surrounding code to judge each changed line and its system effect.
• Do not turn preferences into findings. Use technical evidence and repository conventions.
• Do not approve solely because checks pass.