用途：该技能用于规范代码审查全流程，把“技术正确性”置于“社交舒适”之上，减少表演式附和与未经验证的完成声明。核心原则：遵循 YAGNI、KISS、DRY，直截了当、简洁、以证据说话；先验证再实现，先询问再假设。
主要能力分三类实践：接收反馈、发起审查、验证门禁，各自有明确触发条件与参考文件。
接收反馈：当收到来自任何来源的审查意见、反馈不清晰或技术上可疑、需要给多条意见排优先级、外部审查者缺乏完整上下文、建议与既有决策冲突时触发。响应模式为 READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT。禁止表演式认同（如“你完全正确”“好点子”“谢谢”），禁止未经验证就实现；要求复述需求、提问、以技术理由反驳，或直接开始工作。不清晰时先停下，就不清晰项全部澄清。对建议的“完整”功能先 grep 检查是否被使用（YAGNI）。来源处理：人类伙伴可信任，理解后实现；外部审查者需先验证技术正确性并检查是否引入破坏，若错误则反驳。
发起审查：在每个子代理驱动开发任务完成后、重大功能完成、合并到主分支前、卡住需要新视角、修复复杂缺陷后触发。流程为取 git SHA：BASE_SHA=$(git rev-parse HEAD~1) 与 HEAD_SHA=$(git rev-parse HEAD)，再通过 Task 工具派发 code-reviewer 子代理，提供 WHAT_WAS_IMPLEMENTED、PLAN_OR_REQUIREMENTS、BASE_SHA、HEAD_SHA、DESCRIPTION；反馈按严重度处理：Critical 立即修复，Important 在继续前修复，Minor 记录待后续。
验证门禁：铁律是“没有最新验证证据就不得声称完成”。门禁函数为 IDENTIFY 命令 → RUN 完整命令 → READ 输出 → VERIFY 确认声明 → 再声明；跳过任一步即为说谎。要求：测试通过需输出显示 0 失败；构建成功需退出码 0；缺陷修复需原症状测试通过；需求满足需逐行清单核对。红旗信号包括使用“应该／可能／似乎”、验证前表达满意、未验证就提交、轻信代理报告，以及任何暗示成功却未运行验证的措辞。
适用场景：子代理驱动开发、拉取请求、一般开发流程中的状态声明与反馈处理。限制：资料未提供安装方式、平台支持、价格或具体集成命令，实际使用需自行获取参考文件。