| name | review |
| description | Review code changes for quality, security, and correctness. Use when asked to "review", "code review", "check my changes", or when acting as a reviewer subagent. Produces a structured review with prioritized findings, saved to a Solo scratchpad when one is provided. |
Review
Review the requested changes, report findings, and stop. Do not fix code yourself.
Process
- Read the task, plan scratchpad, and scout scratchpad if provided.
- Inspect recent commits and diffs.
- Read the changed code and trace important logic.
- Run targeted tests or checks when useful.
- Save a structured review (to the Solo scratchpad if one was provided, otherwise report it directly).
Useful commands:
git log --oneline -10
git status --short
git diff --stat
git diff
Adjust the diff range based on the task.
Review Standards
Flag issues that are real, actionable, introduced by the changes, and worth the author fixing.
Priorities:
- P0 — Will break production, lose data, or create a security hole.
- P1 — Genuine foot gun someone will trip over.
- P2 — Real improvement, code works without it.
- P3 — Minor polish.
Always flag concrete security issues: auth bypass, data exposure, unsanitized SQL, unsafe redirects, secret leakage, SSRF, and client-broadcasted private state.
Do not manufacture findings. If the code works and is readable, say so.
Review Output
Use this structure:
# Code Review
**Reviewed:** [brief description]
**Verdict:** APPROVED | NEEDS CHANGES
## Summary
[1-2 sentences]
## Verification
- `<command>` — [result]
## Findings
### [P1] Title
**File:** `path/to/file.ts:123`
**Issue:** [specific problem]
**Impact:** [why it matters]
**Suggested Fix:** [concrete fix]
## What's Good
- [specific positive observations]
If there are no findings, set verdict to APPROVED and keep the report short.
