Review
Use this workflow when reviewing a diff, pull request, branch, or local change set.
Workflow
- Identify the review scope: diff, files, commit range, pull request, or task goal.
- Inspect changed behavior before style or cleanup concerns.
- Prioritize bugs, regressions, security risks, data-loss risks, and missing verification.
- Check whether tests, docs, migrations, and release notes match the behavioral impact.
- Look for edge cases around empty input, permissions, concurrency, rollback, and failure paths.
- Keep findings specific, reproducible, and tied to exact files or lines when possible.
- Avoid broad refactor suggestions unless they block correctness, safety, or maintainability.
- If no issues are found, say so clearly and note remaining test gaps or residual risk.
When the review covers a large diff, consider delegating per-area passes to parallel subagents (for example a code-reviewer subagent per concern: correctness, security, performance, tests). Combine findings, deduplicate, and rank by severity.
Final Report
Lead with findings, ordered by severity.
For each finding, include:
- severity or priority
- file and line when available
- what can fail
- why it matters
- a concrete fix direction
Then include:
- open questions or assumptions
- verification reviewed or still missing
- brief summary of the reviewed change
1---2name: review3description: Review code changes with a bug-first, risk-focused workflow before merge or release.4---56# Review78Use this workflow when reviewing a diff, pull request, branch, or local change set.910## Workflow11121. Identify the review scope: diff, files, commit range, pull request, or task goal.132. Inspect changed behavior before style or cleanup concerns.143. Prioritize bugs, regressions, security risks, data-loss risks, and missing verification.154. Check whether tests, docs, migrations, and release notes match the behavioral impact.165. Look for edge cases around empty input, permissions, concurrency, rollback, and failure paths.176. Keep findings specific, reproducible, and tied to exact files or lines when possible.187. Avoid broad refactor suggestions unless they block correctness, safety, or maintainability.198. If no issues are found, say so clearly and note remaining test gaps or residual risk.2021When the review covers a large diff, consider delegating per-area passes to parallel subagents (for example a `code-reviewer` subagent per concern: correctness, security, performance, tests). Combine findings, deduplicate, and rank by severity.2223## Final Report2425Lead with findings, ordered by severity.2627For each finding, include:2829- severity or priority30- file and line when available31- what can fail32- why it matters33- a concrete fix direction3435Then include:3637- open questions or assumptions38- verification reviewed or still missing39- brief summary of the reviewed change
s-hiraoku