用途：该技能用于规范代码审查实践，核心是技术正确性优先于社交性回应，强调先验证再实现、先提问再假设、先有证据再下结论，并遵循 YAGNI、KISS、DRY 原则。
主要能力：分为三类实践。接收反馈时按 READ→UNDERSTAND→VERIFY→EVALUATE→RESPOND→IMPLEMENT 流程处理，禁止表演式认同（如“你说得完全对”），不清楚时先停下澄清，外部审查者意见需先技术验证再实现，建议实现“更完善”功能前先用 grep 检查使用情况。请求审查时，在子代理驱动开发的每个任务后、重大功能或重构完成、合并主分支前、修复复杂缺陷后，通过 Task 工具派发 code-reviewer 子代理，需提供 WHAT_WAS_IMPLEMENTED、PLAN_OR_REQUIREMENTS、BASE_SHA、HEAD_SHA、DESCRIPTION，其中 SHA 可用 BASE_SHA=$(git rev-parse HEAD~1) 与 HEAD_SHA=$(git rev-parse HEAD) 获取；反馈按 Critical 立即修复、Important 继续前修复、Minor 记录后处理。验证门要求在声称测试通过、构建成功或工作完成前，先识别命令、运行完整命令、读取输出、确认结论，再作声明；测试通过需输出显示 0 失败，构建成功需退出码 0，缺陷修复需原症状测试通过，需求满足需逐条核对。
适用场景：子代理驱动开发、功能完成、重构、合并前、复杂缺陷修复后，以及任何准备提交、推送、创建 PR 或声明完成时。
限制：资料未提供具体安装命令、平台支持、收费方式或效果数据；使用需依赖相应子代理与 git 环境。