用途：规范代码审查实践，核心原则是技术正确性优先于社交礼仪，先验证再实现，先提问再假设，先有证据再下结论。
主要能力分三类。接收反馈：适用于收到任何来源的审查意见、反馈含糊或技术存疑、多条意见需排序、外部审查者缺少上下文、建议与既有决策冲突时。流程为阅读、理解、验证、评估、回应、实现；禁止表演式附和，不得未经核实即实现，含糊时须先澄清全部不明项，实施前可用 grep 检查实际使用情况。来自人类伙伴的反馈在理解后实现；来自外部审查者的反馈须先验证技术正确性、检查是否引入破坏，有误则提出反对。
请求审查：适用于子智能体驱动开发中每项任务完成后、重大功能或重构完成、合并到主分支前、受阻需新视角、修复复杂缺陷后。流程为取基线提交，如 BASE_SHA=$(git rev-parse HEAD~1) 与 HEAD_SHA=$(git rev-parse HEAD)，再通过 Task 工具分派 code-reviewer 子智能体，并提供实现内容、计划或需求、BASE_SHA、HEAD_SHA、描述；按严重程度处理反馈，严重问题立即修复，重要问题在继续前修复，次要问题记录待办。
验证闸门：铁律是无新鲜验证证据不得声称完成。流程为确定命令、运行完整命令、读取输出、确认支持结论后再声明。要求包括测试通过需输出显示 0 失败、构建成功需退出码为 0、缺陷修复需原症状测试通过、需求满足需逐项核对。出现“应该”“可能”“看起来”等措辞、验证前表示满意、未验证即提交、轻信代理报告等属危险信号，应立即停止。
适用场景：分支合并与拉取请求、子智能体驱动开发、复杂缺陷修复后的复核，以及一切需要声明成功或完成之前。
限制与暂未提供：资料未说明安装命令、收费标准、支持平台或具体依赖，相关内容暂未提供；各参考文件的具体内容也未展开。