// Use when completing tasks, implementing major features, or before merging to verify work meets requirements
| name | requesting-code-review |
| description | Use when completing tasks, implementing major features, or before merging to verify work meets requirements |
Dispatch code reviewer subagent to catch issues before they cascade.
Core principle: Review early, review often.
Mandatory:
Optional but valuable:
1. Get git SHAs:
git rev-parse HEAD~1 # BASE_SHA
git rev-parse HEAD # HEAD_SHA
2. Dispatch code-reviewer subagent:
Using runSubagent tool:
runSubagent(
prompt: "Review the code changes between commits.
**What was implemented:** [description]
**Requirements/Plan:** [link or summary]
**Base SHA:** [base]
**Head SHA:** [head]
Review for:
- Does implementation match requirements?
- Any bugs or issues?
- Code quality concerns?
- Test coverage adequate?
Return:
- Strengths: What's done well
- Issues: Categorized by severity (Critical/Important/Minor)
- Assessment: Ready to proceed or needs fixes",
description: "Code review [feature]"
)
3. Act on feedback:
[Just completed Task 2: Add verification function]
You: Let me request code review before proceeding.
git rev-parse HEAD~1 # a7981ec
git rev-parse HEAD # 3df7661
runSubagent(
prompt: "Review code changes.
What was implemented: Verification and repair functions for conversation index
Requirements: Task 2 from docs/plans/deployment-plan.md
Base SHA: a7981ec
Head SHA: 3df7661
Review for requirements match, bugs, quality, tests.",
description: "Code review Task 2"
)
[Subagent returns]:
Strengths: Clean architecture, real tests
Issues:
Important: Missing progress indicators
Minor: Magic number (100) for reporting interval
Assessment: Ready to proceed after fixing Important issues
You: [Fix progress indicators]
[Continue to Task 3]
Subagent-Driven Development:
Executing Plans:
Ad-Hoc Development:
Never:
If reviewer wrong:
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Use when you have a written implementation plan to execute with review checkpoints
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when executing implementation plans with independent tasks in the current session