用途：这是一个代码审查实践指南类技能，用于规范评审反馈的接收、审查的发起以及完成工作的验证，核心是以技术正确性而非社交舒适度为准，先验证再实现，先提问再假设，先有证据再下结论。
主要能力与用法：分三部分。一、接收反馈：触发条件包括收到任何来源的评审意见、反馈含糊或技术上可疑、多项意见需排优先级、外部评审者缺乏完整上下文、建议与既有决策冲突。流程为 READ→UNDERSTAND→VERIFY→EVALUATE→RESPOND→IMPLEMENT，禁止“你说得完全对”这类表演式认同，禁止未经验证就实现；不清楚时先停下询问全部不明项；对建议的“正规”功能先 grep 检查是否真被使用（YAGNI）。来自人类伙伴的反馈理解后实现，来自外部评审者的反馈需先技术验证、检查是否破坏现有功能，错误则回退。二、请求审查：在子代理驱动开发中每个任务完成后、完成重大功能或重构后、合并到 main 前、卡住或修复复杂 bug 后触发。流程是先取 BASE_SHA=$(git rev-parse HEAD~1) 与 HEAD_SHA=$(git rev-parse HEAD)，再通过 Task 工具派发 code-reviewer 子代理，提供已实现内容、计划或需求、两个 SHA 与描述，按反馈处理：Critical 立即修复，Important 在继续前修复，Minor 记录待办。三、验证闸门：铁律是“没有新的验证证据就不得宣称完成”。流程为确定命令→运行完整命令→读取输出→确认支持结论→再作宣称。要求测试输出 0 失败、构建退出码 0、原始症状对应的测试通过、需求逐条核对。
适用场景：子代理驱动开发、代码合并前的 PR 流程，以及任何准备提交、推送、创建 PR 或表示“完成”的时刻。
限制：资料未提供该技能的安装方式、依赖、平台支持、收费与价格信息；相关技能 golang-style、aip 仅在对应场景下按需调用。