Requesting Code Review
Dispatch superpowers:code-reviewer subagent to catch issues before they cascade.
Core principle: Review early, review often.
When to Request Review
Mandatory:
- - After each task in subagent-driven development
- After completing major feature
- Before merge to main
Optional but valuable:
- - When stuck (fresh perspective)
- Before refactoring (baseline check)
- After fixing complex bug
How to Request
1. Get git SHAs:
CODEBLOCK0
2. Dispatch code-reviewer subagent:
Use Task tool with superpowers:code-reviewer type, fill template at INLINECODE0
Placeholders:
- -
{WHAT_WAS_IMPLEMENTED} - What you just built - INLINECODE2 - What it should do
- INLINECODE3 - Starting commit
- INLINECODE4 - Ending commit
- INLINECODE5 - Brief summary
3. Act on feedback:
- - Fix Critical issues immediately
- Fix Important issues before proceeding
- Note Minor issues for later
- Push back if reviewer is wrong (with reasoning)
Example
CODEBLOCK1
Integration with Workflows
Subagent-Driven Development:
- - Review after EACH task
- Catch issues before they compound
- Fix before moving to next task
Executing Plans:
- - Review after each batch (3 tasks)
- 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
- Argue with valid technical feedback
If reviewer wrong:
- - Push back with technical reasoning
- Show code/tests that prove it works
- Request clarification
See template at: requesting-code-review/code-reviewer.md
请求代码审查
派遣超级能力：代码审查子代理，在问题级联之前捕获它们。
核心原则： 尽早审查，经常审查。
何时请求审查
强制要求：
- - 在子代理驱动的开发中每个任务之后
- 完成主要功能之后
- 合并到主分支之前
可选但有价值：
- - 遇到困难时（获得新视角）
- 重构之前（基线检查）
- 修复复杂错误之后
如何请求
1. 获取Git SHA值：
bash
BASE_SHA=$(git rev-parse HEAD~1) # 或 origin/main
HEAD_SHA=$(git rev-parse HEAD)
2. 派遣代码审查子代理：
使用Task工具，类型为superpowers:code-reviewer，填写code-reviewer.md模板
占位符：
- - {WHATWASIMPLEMENTED} - 你刚刚构建的内容
- {PLANORREQUIREMENTS} - 它应该做什么
- {BASESHA} - 起始提交
- {HEADSHA} - 结束提交
- {DESCRIPTION} - 简要总结
3. 根据反馈行动：
- - 立即修复严重问题
- 在继续之前修复重要问题
- 记录次要问题留待后续处理
- 如果审查者错误，进行反驳（附上理由）
示例
[刚刚完成任务2：添加验证功能]
你：在继续之前，让我请求代码审查。
BASE_SHA=$(git log --oneline | grep Task 1 | head -1 | awk {print $1})
HEAD_SHA=$(git rev-parse HEAD)
[派遣超级能力：代码审查子代理]
WHATWASIMPLEMENTED: 对话索引的验证和修复功能
PLANORREQUIREMENTS: docs/plans/deployment-plan.md中的任务2
BASE_SHA: a7981ec
HEAD_SHA: 3df7661
DESCRIPTION: 添加了verifyIndex()和repairIndex()，支持4种问题类型
[子代理返回]：
优点：架构清晰，有真实测试
问题：
重要：缺少进度指示器
次要：报告间隔使用魔法数字(100)
评估：可以继续
你：[修复进度指示器]
[继续执行任务3]
与工作流的集成
子代理驱动的开发：
- - 每个任务后审查
- 在问题累积前捕获
- 在进入下一个任务前修复
执行计划：
- - 每批任务后审查（3个任务）
- 获取反馈，应用，继续
临时开发：
警示标志
绝对不要：
- - 因为很简单而跳过审查
- 忽略严重问题
- 在未修复重要问题的情况下继续
- 与有效的技术反馈争论
如果审查者错误：
- - 用技术推理进行反驳
- 展示证明其有效的代码/测试
- 请求澄清
请参阅模板：requesting-code-review/code-reviewer.md
