receiving-code-review

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

错误	修复
表演性认同	陈述需求或直接行动
不验证就实施	先对照代码库验证
不测试就批量实施	一次一个，测试每个
假设审查者正确	检查是否破坏东西
避免推回	技术正确性 > 舒适
部分实施	先澄清所有项
无法验证仍然进行	陈述限制，请求方向