name: 代码审查 description: 在接收代码审查反馈时使用（特别是如果反馈不明确或技术上可疑），在完成任务或需要审查后才能继续的主要功能时，或在做出任何完成/成功声明之前使用。涵盖三种实践 - 以技术严谨性接收反馈而非表演性同意，通过代码审查子代理请求审查，以及在做出任何状态声明之前需要证据的验证门。对于子代理驱动开发、拉取请求和防止虚假完成声明至关重要。

代码审查

指导正确的代码审查实践，强调技术严谨性、基于证据的声明和验证而非表演性响应。

概述

代码审查需要三种不同的实践：

接收反馈 - 技术评估而非表演性同意
请求审查 - 通过代码审查子代理进行系统审查
验证门 - 在任何完成声明之前提供证据

每种实践都有详细的触发条件和协议，在参考文件中。

核心原则

始终遵循 YAGNI、KISS 和 DRY 原则。 诚实、直接、简洁。 技术正确性优先于社交舒适度。 在实施前验证。在假设前询问。在声明前提供证据。

何时使用此技能

接收反馈

触发时机：

从任何来源接收代码审查评论
反馈似乎不明确或技术上可疑
需要优先处理多个审查项目
外部审查员缺乏完整上下文
建议与现有决策冲突

参考: references/code-review-reception.md

请求审查

触发时机：

在子代理驱动开发中完成每个任务后
完成主要功能或重构后
在合并到主分支之前
卡住并需要新视角时
修复复杂错误后

参考: references/requesting-code-review.md

验证门

触发时机：

即将声称测试通过、构建成功或工作完成时
在提交、推送或创建PR之前
移动到下一个任务时
任何暗示成功/完成的声明
表达对工作的满意度时

参考: references/verification-before-completion.md

快速决策树

情况？
│
├─ 接收反馈
│  ├─ 不明确项目？ → 停止，首先请求澄清
│  ├─ 来自人类伙伴？ → 理解，然后实施
│  └─ 来自外部审查员？ → 在实施前技术验证
│
├─ 完成工作
│  ├─ 主要功能/任务？ → 请求代码审查子代理审查
│  └─ 合并前？ → 请求代码审查子代理审查
│
└─ 即将声称状态
   ├─ 有新鲜验证？ → 用证据声明
   └─ 没有新鲜验证？ → 首先运行验证命令

接收反馈协议

响应模式

阅读 → 理解 → 验证 → 评估 → 响应 → 实施

关键规则

❌ 无表演性同意：“你完全正确！”、“好观点！”、“感谢[任何内容]”
❌ 在验证前不实施
✅ 重述要求、提问、用技术推理推回，或直接开始工作
✅ 如果不明确：停止并首先请求所有不明确项目的澄清
✅ YAGNI检查：在实施建议的“正确”功能前，grep使用情况

来源处理

人类伙伴： 可信 - 理解后实施，无表演性同意
外部审查员： 验证技术正确性，检查是否破坏，如果错误则推回

完整协议: references/code-review-reception.md

请求审查协议

何时请求

在子代理驱动开发中每个任务后
主要功能完成后
合并到主分支前

过程

获取git SHAs：BASE_SHA=$(git rev-parse HEAD~1) 和 HEAD_SHA=$(git rev-parse HEAD)
通过Task工具派遣代码审查子代理，包含：WHAT_WAS_IMPLEMENTED, PLAN_OR_REQUIREMENTS, BASE_SHA, HEAD_SHA, DESCRIPTION
根据反馈行动：立即修复关键问题，在继续前修复重要问题，记录次要问题稍后处理

完整协议: references/requesting-code-review.md

验证门协议

铁律

没有新鲜验证证据，不做完成声明

门功能

识别命令 → 运行完整命令 → 读取输出 → 验证确认声明 → 然后声明跳过任何步骤 = 撒谎，未验证

要求

测试通过：测试输出显示0失败
构建成功：构建命令退出0
错误修复：原始症状测试通过
要求满足：逐行检查清单已验证

红旗 - 停止

使用“应该”/“可能”/“似乎”，在验证前表达满意度，未验证就提交，信任代理报告，任何暗示成功而未运行验证的措辞

完整协议: references/verification-before-completion.md

与工作流集成

子代理驱动： 每个任务后审查，在移动到下一个前验证
拉取请求： 验证测试通过，在合并前请求代码审查审查
一般： 在任何状态声明前应用验证门，对无效反馈推回

底线

技术严谨性优先于社交表现 - 无表演性同意
系统审查流程 - 使用代码审查子代理
证据先于声明 - 始终验证门

验证。提问。然后实施。证据。然后声明。