requesting-code-review 的核心用途是：在开发过程中的关键节点发起代码审查，借助 superpowers:code-reviewer 子代理在问题扩散前发现问题。该技能主张“尽早审查、频繁审查”。
适用时机分为两类。强制场景包括：在子代理驱动开发中每个任务完成后、完成重要功能后、合并到主分支前。可选但有价值的场景包括：遇到困难需要新视角时、重构前做基线检查时、修复复杂缺陷后。
使用方式分三步。第一步获取 git SHA：以 BASE_SHA=$(git rev-parse HEAD~1) 或 origin/main 作为起始提交，以 HEAD_SHA=$(git rev-parse HEAD) 作为结束提交。第二步调度 code-reviewer 子代理：使用 Task 工具并指定 superpowers:code-reviewer 类型，按 code-reviewer.md 模板填写占位符，包括 {WHAT_WAS_IMPLEMENTED}（刚构建的内容）、{PLAN_OR_REQUIREMENTS}（应实现的功能）、{BASE_SHA}（起始提交）、{HEAD_SHA}（结束提交）、{DESCRIPTION}（简要总结）。第三步处理反馈：立即修复 Critical 问题，继续推进前修复 Important 问题，记录 Minor 问题留待后续；若审查者判断有误，可附技术理由反驳。
资料给出了一个示例流程：完成任务 2（添加验证函数）后，先通过 git log 定位任务 1 的提交作为 BASE_SHA，当前 HEAD 作为 HEAD_SHA，调度子代理并填写实现内容、需求来源、提交区间与描述；子代理返回优点（清晰架构、真实测试）与问题（Important：缺少进度指示；Minor：上报间隔使用魔法数字 100），评估为可继续推进；开发者修复进度指示后进入任务 3。
与工作流的集成方式：子代理驱动开发中每个任务后审查，防止问题累积，修复后再进入下一任务；执行计划时每批（3 个任务）后审查，获取反馈、应用后继续；临时开发则在合并前或受阻时审查。
限制与红线：不得因“很简单”跳过审查，不得忽略 Critical 问题，不得在 Important 问题未修复时继续推进，也不得与有效的技术反馈争辩；若认为审查者有误，应以技术理由反驳、展示证明其可工作的代码或测试，或请求澄清。模板位于 requesting-code-review/code-reviewer.md。