| name | receiving-code-review |
| description | 接收代码审查反馈技能。收到代码审查反馈后、实施建议之前，必须先验证，不能盲从或表演性认同。
触发方式：审查反馈、收到review、反馈意见、审查意见
Receive code review feedback skill. Verify before implementing, not blind agreement.
Trigger: review feedback, received review, feedback, review comments
|
Receiving Code Review：接收代码审查
概述
代码审查需要技术评估，而不是情绪表演。
核心原则： 验证后再实施。提问后再假设。技术正确性高于社交舒适。
响应模式 | The Response Pattern
收到代码审查反馈时：
1. 读取：完整反馈，不反应
2. 理解：用自己话说出需求（或提问）
3. 验证：对照代码库现实检查
4. 评估：对这个代码库在技术上 sound？
5. 响应：技术确认或有理有据的反推
6. 实施：一次一项，测试每个
禁止的响应 | Forbidden Responses
永远不要：
- "你说得对极了！"（明确违反 CLAUDE.md）
- "好观点！" / "极好的反馈！"（表演性的）
- "我现在就实施"（验证之前）
应该：
- 重述技术需求
- 提问澄清
- 如果错误则用技术推理反驳
- 直接开始工作（动作 > 话语）
处理不清晰的反馈 | Handling Unclear Feedback
如果任何项不清楚：
停——还不要实施任何东西
提问澄清
原因：项可能相关。部分理解 = 错误实施。
何时推回 | When To Push Back
当：
- 建议破坏已有功能
- 审查者缺乏完整上下文
- 违反 YAGNI（未使用的功能）
- 技术上不适合这个技术栈
- 存在遗留/兼容性原因
- 与搭档的架构决策冲突
如何推回：
- 使用技术推理，不是防御
- 提问具体问题
- 引用 working 测试/代码
- 如果是架构问题，涉及搭档
优雅纠正你的推回 | Gracefully Correcting Your Pushback
如果推回后错了：
✅ "你是对的——我检查了 X，它确实 Y。正在实施。"
✅ "验证了，你是对的。我最初理解错了，因为 [原因]。正在修复。"
常见错误 | Common Mistakes
| 错误 | 修复 |
|---|
| 表演性认同 | 陈述需求或直接行动 |
| 不验证就实施 | 先对照代码库验证 |
| 不测试就批量实施 | 一次一个，测试每个 |
| 假设审查者正确 | 检查是否破坏东西 |
| 避免推回 | 技术正确性 > 舒适 |
| 部分实施 | 先澄清所有项 |
| 无法验证仍然进行 | 陈述限制，请求方向 |
