Dispatch the superpowers:code-reviewer subagent to find problems before they spread. The reviewer receives a carefully organized evaluation context—never your session history. This lets the reviewer focus on the work results rather than your thought process, while preserving your own context so you can continue working.
Core principles: Review early, review often.
When to request a review
Must review:
- After each task is completed in subagent-driven development
- After completing an important feature
- Before merging to main
Optional but valuable:
- When stuck (for a fresh perspective)
- Before refactoring (to establish a baseline)
- After fixing a complex bug
How to request
1. Get the git SHA:
BASE_SHA=$(git rev-parse HEAD~1) # 或 origin/main
HEAD_SHA=$(git rev-parse HEAD)
2. Dispatch the code-reviewer subagent:
Use the Task tool, specify the superpowers:code-reviewer type, and fill in the code-reviewer.md template in
Placeholder descriptions:
{WHAT_WAS_IMPLEMENTED}- What you just completed{PLAN_OR_REQUIREMENTS}- Expected functionality{BASE_SHA}- Starting commit{HEAD_SHA}- Ending commit{DESCRIPTION}- Brief description
3. Handle feedback:
- Fix Critical issues immediately
- Fix Important issues before continuing
- Note Minor issues down and handle them later
- If the reviewer is wrong, refute with technical reasoning
Example
[刚完成任务 2：添加验证功能]
你：让我在继续之前请求代码审查。
BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
HEAD_SHA=$(git rev-parse HEAD)
[派遣 superpowers:code-reviewer 子代理]
WHAT_WAS_IMPLEMENTED: 会话索引的验证和修复功能
PLAN_OR_REQUIREMENTS: docs/superpowers/plans/deployment-plan.md 中的任务 2
BASE_SHA: a7981ec
HEAD_SHA: 3df7661
DESCRIPTION: 添加了 verifyIndex() 和 repairIndex()，支持 4 种问题类型
[子代理返回]:
优点：架构清晰，测试真实
问题：
Important：缺少进度指示器
Minor：报告间隔使用了魔法数字 (100)
评估：可以继续
你：[修复进度指示器]
[继续任务 3]
Integration with the workflow
Subagent-driven development:
- Review after each task is completed
- Find problems before they stack up
- After fixing, proceed to the next task
Execution plan:
- Review after each batch (3 tasks)
- Get feedback, fix, continue
Ad-hoc development:
- Review before merging
- Review when stuck
Red lines
Never:
- Skip review because it is "simple"
- Ignore Critical issues
- Keep pushing forward with unfixed Important issues
- Argue against reasonable technical feedback
If the reviewer is wrong:
- Refute with technical reasoning
- Show code/tests proving it works
- Ask for clarification
See template: requesting-code-review/code-reviewer.md