何时使用
- 每个子代理任务完成后
- 重大功能完成后
- 合并到 main 前
- 卡住时
- 重构前
请求代码审查 (requesting-code-review)
请求代码审查（requesting-code-review）
Section titled “请求代码审查（requesting-code-review）”requesting-code-review 是 Superpowers 里”质量保障”的关键 Skill。
它的核心理念是：
早审查，常审查。
很多开发者的习惯是：
- 代码写完了 → 直接提交
- 功能做完了 → 直接合并
- “反正后面还有测试”
这种模式的问题在于：
- 问题发现得越晚，修复成本越高
- 错误的架构决策一旦固化，重构代价巨大
- 缺少审查的代码容易变成”技术债务”
而 requesting-code-review 要求你在关键节点主动邀请审查：
- 每次子代理任务完成后
- 重大功能完成后
- 合并到主分支前
这样可以把问题在”还可以轻易修改”的阶段就抓住。
何时请求审查
Section titled “何时请求审查”- 子代理驱动开发中的每个任务完成后
- 重大功能完成后
- 合并到 main 分支前
可选但有价值
Section titled “可选但有价值”- 卡住时（ fresh perspective）
- 重构前（ baseline check）
- 复杂 Bug 修复后
如何请求审查
Section titled “如何请求审查”1. 获取 git SHA
Section titled “1. 获取 git SHA”BASE_SHA=$(git rev-parse HEAD~1) # 或 origin/mainHEAD_SHA=$(git rev-parse HEAD)2. 调度 code-reviewer 子代理
Section titled “2. 调度 code-reviewer 子代理”使用 Task 工具，类型为 superpowers:code-reviewer，填充 code-reviewer.md 中的模板。
占位符：
{WHAT_WAS_IMPLEMENTED}- 你刚构建的{PLAN_OR_REQUIREMENTS}- 应该做什么{BASE_SHA}- 起始提交{HEAD_SHA}- 结束提交{DESCRIPTION}- 简要总结
3. 处理反馈
Section titled “3. 处理反馈”- 立即修复 Critical 问题
- 重要问题修复后再继续
- 记录 Minor 问题留后处理
- 如果审查者错了，提出反驳（带技术理由）
与工作流集成
Section titled “与工作流集成”子代理驱动开发
Section titled “子代理驱动开发”- 每个任务后都审查
- 在问题累积前抓住
- 修复后再进入下一任务
- 每批任务（3 个）后审查
- 获取反馈、应用、继续
- 合并前审查
- 卡住时审查
常见错误与红旗
Section titled “常见错误与红旗”| 错误行为 | 为什么是错的 |
|---|---|
| 跳过审查因为”很简单” | 简单代码也会有问题 |
| 忽略 Critical 问题 | 这些是必须修复的 |
| 带着未修复的 Important 问题继续 | 问题会累积 |
| 与有效的技术反馈争辩 | 审查是为了质量 |
如果审查者错了：
- 用技术理由反驳
- 展示证明它工作的代码/测试
- 请求澄清
关键要点
- 早审查，常审查
- 用 code-reviewer 子代理
- 提供精确的上下文
- 按严重程度分类问题
处理反馈
- Critical：立即修复
- Important：修复后再继续
- Minor：记录后处理
流程
- 获取 BASE_SHA 和 HEAD_SHA
- 调度 code-reviewer 子代理
- 填入占位符
- 处理反馈
- 修复后继续
关联 Skill
Section titled “关联 Skill”- 后续：
receiving-code-review（如何处理收到的审查反馈）。 - 互补：
subagent-driven-development（子代理任务后的审查）、verification-before-completion（审查前的验证）。
查看源文件: GitHub原始文件