| name | requesting-code-review |
| description | 完成任务、实现重要功能或合并前使用,用于验证工作成果是否符合要求 |
请求代码审查
派遣 code-reviewer 子代理来在问题扩散之前发现它们。审查者获得的是精心组织的评估上下文——绝不是你的会话历史。这样可以让审查者专注于工作成果而非你的思考过程,同时保留你自己的上下文以便继续工作。
核心原则: 早审查,勤审查。
何时请求审查
必须审查:
- 子代理驱动开发中每个任务完成后
- 完成重要功能后
- 合并到 main 之前
可选但有价值:
- 卡住时(换个视角)
- 重构之前(建立基线)
- 修复复杂 bug 之后
如何请求
1. 获取 git SHA:
BASE_SHA: run_command(command="git rev-parse HEAD~1") # 或 origin/main
HEAD_SHA: run_command(command="git rev-parse HEAD")
2. 派遣 code-reviewer 子代理:
run_skill(
name="flow-review",
arguments="审查当前分支变更。实现内容:{WHAT_WAS_IMPLEMENTED}。参考计划:{PLAN_OR_REQUIREMENTS}。范围:{BASE_SHA}..{HEAD_SHA}。"
)
占位符说明:
{WHAT_WAS_IMPLEMENTED} - 你刚完成的内容
{PLAN_OR_REQUIREMENTS} - 预期功能
{BASE_SHA} - 起始提交
{HEAD_SHA} - 结束提交
{DESCRIPTION} - 简要说明
3. 处理反馈:
- Critical 问题立即修复
- Important 问题在继续之前修复
- Minor 问题记录下来稍后处理
- 如果审查者有误,用技术理由反驳
示例
[刚完成任务 2:添加验证功能]
你:让我在继续之前请求代码审查。
run_command(command="git log --oneline | grep 'Task 1' | head -1 | awk '{print $1}'") # 获取 BASE_SHA
run_command(command="git rev-parse HEAD") # 获取 HEAD_SHA
run_skill(
name="flow-review",
arguments="审查当前分支从 a7981ec 到 3df7661 的变更。实现了 verifyIndex() 和 repairIndex(),支持 4 种问题类型。参考计划:docs/superpowers/plans/deployment-plan.md 任务 2。"
)
[子代理返回]:
优点:架构清晰,测试真实
问题:
Important:缺少进度指示器
Minor:报告间隔使用了魔法数字 (100)
评估:可以继续
你:[修复进度指示器]
[继续任务 3]
与工作流的集成
子代理驱动开发:
- 每个任务完成后审查
- 在问题叠加之前发现它们
- 修复后再进入下一个任务
执行计划:
临时开发:
红线
绝不要:
- 因为"很简单"就跳过审查
- 忽略 Critical 问题
- 带着未修复的 Important 问题继续推进
- 对合理的技术反馈进行争辩
如果审查者有误:
- 用技术理由反驳
- 展示证明其可行的代码/测试
- 要求澄清
参见模板:requesting-code-review/code-reviewer.md