用途：规范代码评审流程，减少表演式回应，强调技术正确性与证据验证。核心原则为遵循 YAGNI、KISS、DRY，直接、简洁、诚实，先验证再实现，先提问再假设，先取证再断言。
主要能力分三类。其一，接收反馈：收到任何来源的评审意见、反馈不清或技术存疑、多条意见需排优先级时触发；流程为 READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT，禁止先说“你说得对”等客套话，禁止未验证就实现，不清楚时先停下澄清全部疑点；人类伙伴的意见理解后实现，外部评审者意见先做技术核实与破坏性检查，不合理可反驳，建议新增“正规”功能前先用 grep 确认是否真的被使用。其二，请求评审：在子智能体驱动的开发中每完成一个任务、完成重大功能或重构、合并主分支前、卡住需新视角、修复复杂缺陷后触发；步骤为用 git rev-parse 取得 BASE_SHA 与 HEAD_SHA，通过 Task 工具派发 code-reviewer 子智能体，并提供实现内容、计划或需求、两个 SHA 与描述，随后按严重度处理反馈。其三，验证门：宣布测试通过、构建成功或工作完成前必须先执行验证命令并读取输出，确认后再声明；包括测试零失败、构建退出码为 0、原症状用例通过、需求逐条核对。出现“应该”“大概”“似乎”、验证前表达满意、未验证即提交、轻信智能体报告等均为危险信号，须停下。
限制：资料未提供安装命令、依赖、平台支持与收费信息，暂未提供；具体细节见 references 下三个参考文件。