请求代码审查

要解决什么问题

在子代理驱动的开发里，任务一个接一个落地，缺陷往往在合并或进入下一批任务之后才暴露，修复成本会随提交链变长而放大。本技能针对的是：你已经有明确实现区间（BASE_SHA → HEAD_SHA），却缺少一套固定节奏去请人（或子代理）做审查，以及收到反馈后该先动哪类问题。

技能如何工作

核心原则是及早审查、经常审查。技能把「何时审」和「怎么审」写成可执行清单：

• 必须审查：子代理驱动开发中每个任务之后、主要功能完成后、合并主分支之前
• 可选但有价值：卡壳时换视角、重构前做基线、复杂 bug 修完后复核

请求审查的三步与 code-reviewer.md 模板对齐：

1. 获取 git SHAs：确定审查 diff 的起止提交（BASE_SHA、HEAD_SHA）。
2. 派遣 superpowers:code-reviewer 子代理：通过 Task 工具，类型为 superpowers:code-reviewer，填写模板占位符——{WHAT_WAS_IMPLEMENTED}（刚做了什么）、{PLAN_OR_REQUIREMENTS}（应满足的需求）、{DESCRIPTION}（简要总结）等。
3. 对反馈采取行动：严重问题立即修；重要问题在进入下一步前修；次要问题记录延后；若审查结论有误，用技术理由反驳并附代码或测试依据。

与工作流的衔接也写得很具体：子代理开发是「每任务后审」；执行计划可按批（例如每 3 个任务）审一轮；临时开发则强调合并前与遇阻时再审。

适用边界与注意点

技能不是替代你自己的设计决策，而是把审查插进流水线，在问题级联前拦住它们。红旗行为包括：因「很简单」跳过审查、无视严重项、带着未修的重要问题继续、与有效技术反馈空辩。审查者错了时，应展示能证明有效的实现或测试，必要时请求澄清，而不是情绪化争论。