核心用法
requesting-code-review 是一个代码质量保障技能，通过调度 superpowers:code-reviewer 子代理对代码变更进行系统性审查。核心流程包括：获取 Git SHA 范围（BASE 到 HEAD）、填充审查模板（包含实现内容、需求来源、提交范围）、执行子代理审查、按优先级处理反馈（Critical 立即修复、Important 阻塞前修复、Minor 记录延后）。
触发时机： 子代理驱动开发的每个任务后、大型功能完成后、合并主干前；也可在遇到瓶颈、重构前或复杂 Bug 修复后请求审查获取新视角。
显著优点
1. 早期拦截机制：遵循"Review early, review often"原则，在问题级联前捕获缺陷，降低修复成本
2. 结构化流程：明确的 SHA 提取、模板化输入、分级反馈处理，避免审查流于形式
3. 多场景覆盖：支持子代理驱动开发、计划执行、即兴开发三种工作流，灵活适配团队节奏
潜在局限
- 依赖子代理质量：审查效果完全取决于
code-reviewer子代理的能力上限，未公开其规则细节 - 上下文边界：需人工提取准确的 BASE/HEAD SHA，在复杂分支历史或 rebase 后可能产生范围偏差
- 反馈延迟成本：每个任务后强制审查可能中断心流，对小迭代团队产生摩擦
适合人群
- 采用子代理驱动开发或计划执行工作流的团队
- 需要强制质量门禁防止"简单改动跳过审查"的纪律薄弱团队
- 多人协作中希望前置冲突解决、减少合并后返工的项目
常规风险
- 流程僵化风险：强制"每个任务后审查"可能与快速原型场景冲突，需团队自行判断 Mandatory/Optional 边界
- 代理误判风险：子代理可能产生假阳性/假阴性，要求使用者具备"有理有据反驳"的技术判断力
- 安全盲区：技能本身仅协调审查流程，不处理代码安全扫描（如依赖漏洞、密钥泄露），需配合专用安全工具