Code Review
Request or perform code review before issues compound.
Operating Mode
Act as a pragmatic review coordinator first, and a reviewer second.
Prioritize:
- clear review scope before opinions
- requirement alignment before style nits
- bugs and regressions before polish
- explicit evidence before confidence
Review early and review often.
Workflow
Follow this sequence unless the user asks for only one part of the review flow.
1. Define the review scope
Choose the smallest meaningful diff to review.
Prefer:
- branch review:
git merge-base origin/main HEADtoHEAD - task review: previous task commit to
HEAD - single-commit review:
HEAD~1toHEAD
Use commands such as:
git merge-base origin/main HEAD
git rev-parse HEAD
git log --oneline --decorate -n 10If the change set is too large or mixes unrelated work, call that out and split the review scope before continuing.
2. Gather review context
Capture the minimum context a reviewer needs:
- what was implemented
- plan, requirements, or acceptance criteria
- known risks or edge cases
- tests added, updated, or still missing
- exact
BASE_SHAandHEAD_SHA
Do not rely on session history. Summarize the relevant context explicitly.
3. Choose the review path
If a dedicated review subagent or local review skill is available, dispatch it with the prepared scope and context.
If no dedicated reviewer is available, perform the review directly in the current session using the same scope and context.
When delegating, pass only the material needed for review:
- implementation summary
- requirements or plan reference
BASE_SHAHEAD_SHA- brief description of the change
4. Review the change set
Inspect the diff against the stated requirements.
Focus on:
- correctness bugs
- missing requirements
- behavioral regressions
- unsafe migrations or rollout risks
- missing or weak tests
- security, reliability, and performance issues when relevant
Prefer review commands such as:
git diff <base>..<head>
git log <base>..<head> --statFor the detailed reviewer checklist and findings template, read references/reviewer-guide.md.
5. Return findings in severity order
Report findings first.
Use this structure:
# Review Findings
## Critical
- <issue with file/line and impact>
## Important
- <issue with file/line and impact>
## Minor
- <issue with file/line and impact>
## Open Questions
- <missing context or assumption>
## Assessment
- Ready to proceed / Fix important issues first / BlockedKeep findings concrete. Include file and line references when available. If there are no findings, state that explicitly and note any residual risk or test gap.
6. Act on the review
- Fix Critical issues immediately.
- Fix Important issues before proceeding or merging.
- Track Minor issues deliberately instead of losing them.
- Push back on incorrect review comments with technical reasoning and evidence.
Do not wave through known Important issues just because the change is small.
Review Brief Template
Use this when preparing a review request:
# Review Request
## What Was Implemented
<what changed>
## Requirements
<plan, ticket, acceptance criteria, or intended behavior>
## Scope
- BASE_SHA: <sha>
- HEAD_SHA: <sha>
## Notes for Reviewer
- risks, edge cases, or areas needing extra scrutinyDecision Rules
- Prefer reviewing a precise diff over reviewing an entire branch by default.
- Prefer merge-base for branch reviews and
HEAD~1only for truly single-commit reviews. - Escalate when scope is ambiguous, requirements are missing, or the diff contains unrelated changes.
- Treat missing tests as a real finding when behavior changed.
- Keep reviewer context concise and independent from hidden chain-of-thought or session history.
Red Flags
Stop and reassess if:
- the review scope is unclear
- the diff includes unrelated changes
- the requirements are too vague to judge correctness
- the review request lacks
BASE_SHAorHEAD_SHA - critical feedback is being ignored without evidence