用途
本技能用于指导规范的代码评审实践，核心是强调技术严谨性、基于证据的主张，以及验证优先于表演式回应。它把代码评审拆分为三种相互独立的实践，每种都有明确的触发条件和协议。
主要能力
一、接收反馈
触发条件包括：收到来自任何来源的代码评审意见；反馈不清晰或在技术上存疑；多个评审项需要排定优先级；外部评审者缺乏完整上下文；建议与既有决策冲突。
响应模式为：READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT。
关键规则：
- 禁止表演式认同，例如“你完全正确！”“好观点！”“感谢……”等。
- 禁止在验证之前就动手实现。
- 应当复述需求、提出问题、以技术理由反驳，或直接开始工作。
- 若不清楚，先停下，就所有不清楚的项请求澄清。
- YAGNI 检查：在实现建议的“正规”功能前，先用 grep 检查其使用情况。
来源处理：来自人类伙伴的反馈视为可信，理解后实现，不做表演式认同；来自外部评审者的反馈需先验证技术正确性、检查是否造成破坏，若错误则反驳。
二、请求评审
触发条件包括：在子代理驱动开发中完成每个任务后；完成重大功能或重构后；合并到主分支前；遇到困难需要新视角时；修复复杂缺陷后。
流程：
- 获取 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 记录待后续处理。
三、验证门
触发条件包括：即将声称测试通过、构建成功或工作完成时；提交、推送或创建 PR 前；进入下一任务时；任何暗示成功或完成的表述；对工作表示满意时。
铁律：没有新鲜的验证证据，不得声称完成。
门函数：IDENTIFY 命令 → RUN 完整命令 → READ 输出 → VERIFY 确认主张 → 然后才声称。跳过任何一步都等于撒谎，而非验证。
要求：测试通过需测试输出显示 0 失败；构建成功需构建命令退出码为 0；缺陷修复需原始症状的测试通过；需求满足需逐行核对清单。
危险信号（应停止）：使用“应该”“大概”“似乎”；在验证前表达满意；未验证就提交；轻信代理报告；任何未运行验证就暗示成功的措辞。
使用方式
技能提供快速决策树：
- 收到反馈：不清楚则先停下请求澄清；来自人类伙伴则理解后实现；来自外部评审者则先技术验证再实现。
- 完成工作：重大功能或任务则请求 code-reviewer 子代理评审；合并前则请求 code-reviewer 子代理评审。
- 即将声称状态：有新鲜验证则带证据陈述；无新鲜验证则先运行验证命令。
各实践的完整协议见对应参考文件：references/code-review-reception.md、references/requesting-code-review.md、references/verification-before-completion.md。
适用场景
- 子代理驱动开发：每个任务后评审，进入下一任务前验证。
- 拉取请求：验证测试通过，合并前请求 code-reviewer 评审。
- 通用：在任何状态声明前应用验证门，对无效反馈进行反驳。
限制
资料未提供该技能的具体安装方式、依赖环境、支持的平台或工具版本等信息，暂未提供。