用途
在完成任务、实现重大功能或合并到主分支之前，使用本技能请求代码审查，通过派发代码审查子代理来捕捉问题，防止问题层层累积。核心原则是：尽早审查，频繁审查。
何时请求审查
强制场景：
- 子代理驱动开发中每完成一个任务后
- 完成重大功能后
- 合并到主分支之前
可选但有价值的场景：
- 遇到困难时（获取新视角）
- 重构之前（基线检查）
- 修复复杂 bug 之后
如何请求
- 获取 git SHA：
BASE_SHA=$(git rev-parse HEAD~1) # 或: git merge-base origin/main HEAD
HEAD_SHA=$(git rev-parse HEAD)
- 派发代码审查子代理：
派发一个通用子代理，填写 code-reviewer.md 中的模板。
占位符：
- {DESCRIPTION} - 你所构建内容的简要概述
- {PLAN_OR_REQUIREMENTS} - 它应该做什么
- {BASE_SHA} - 起始提交
- {HEAD_SHA} - 结束提交
- 根据反馈行动：
- 立即修复 Critical 问题
- 在继续之前修复 Important 问题
- 记录 Minor 问题留待后续处理
- 如果审查者有误，带理由地反驳
示例
[刚完成 Task 2：添加验证函数]
你：让我在继续之前请求代码审查。
BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | cut -d' ' -f1)
HEAD_SHA=$(git rev-parse HEAD)
[派发代码审查子代理]
DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md
BASE_SHA: a7981ec
HEAD_SHA: 3df7661
[子代理返回]：
Strengths: Clean architecture, real tests
Issues:
Important: Missing progress indicators
Minor: Magic number (100) for reporting interval
Assessment: Ready to proceed
你：[修复进度指示器] [继续 Task 3]
常见合理化借口
| 借口 | 现实 |
|---|---|
| “我直接自己审查 diff 就行了，不用派发审查者” | 你是协调者——内联审查 diff 会消耗你维持工作推进所需的上下文窗口。派发一个审查子代理：diff 和评估都留在它的上下文中，只有发现的问题返回给你。 |
| “审查者需要我整个会话历史才能理解这个变更” | 给它精心构造的上下文，而绝不是你的会话历史。这样能让审查者专注于工作成果，而非你的思考过程。 |
危险信号
绝不：
- 因为“很简单”而跳过审查
- 忽略 Critical 问题
- 在 Important 问题未修复的情况下继续推进
- 与有效的技术反馈争辩
如果审查者有误：
- 用技术理由反驳
- 展示证明其可用的代码/测试
- 请求澄清
模板
参见模板：code-reviewer.md