| name | requesting-code-review |
| description | Use when completing tasks, implementing major features, or before merging to verify work meets requirements |
Requesting Code Review
Run a structured in-session review to catch issues before they cascade.
Core principle: Review early, review often.
When to Request Review
Mandatory:
- After each major task in executing-plans
- After completing major feature
- Before commit on main/master
Optional but valuable:
- When stuck (fresh perspective)
- Before refactoring (baseline check)
- After fixing complex bug
How to Request
1. Gather review scope:
git status
git diff
2. Review against requirements:
Check:
- Spec/plan compliance
- Test coverage for changed behavior
- Regressions and edge cases
- Security and data-safety concerns
- Simplicity and maintainability
3. Act on findings:
- Fix Critical issues immediately
- Fix Important issues before proceeding
- Note Minor issues for later
- Document tradeoffs when intentionally deferring issues
Example
Review checklist:
- Requirement met: Yes
- Tests updated: Yes
- Regression risk: medium (error path changed)
- Issues:
- Important: Missing progress indicators
- Minor: Magic number (100) for reporting interval
Action:
- Fix progress indicators now
- Extract constant before final commit
Integration with Workflows
Subagent-Driven Development:
- Deprecated in this repository
Executing Plans:
- Review after each major task or batch
- Get feedback, apply, continue
Ad-Hoc Development:
- Review before merge
- Review when stuck
Red Flags
Never:
- Skip review because "it's simple"
- Ignore Critical issues
- Proceed with unfixed Important issues
- Skip review before committing on main/master
If reviewer wrong:
- Push back with technical reasoning
- Show code/tests that prove it works
- Request clarification
Use the checklist above for every review pass.
