القائمة
收到代码审查反馈后、实施建议之前使用，尤其当反馈不明确或技术上有疑问时——需要技术严谨性和验证，而非敷衍附和或盲目执行
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
当你有一份书面实现计划需要在单独的会话中执行，并设有审查检查点时使用
在开始任何对话时使用——确立如何查找和使用技能，要求在任何响应（包括澄清性问题）之前调用 Skill 工具
在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能或修改行为。在实现之前先探索用户意图、需求和设计。
当实现完成、所有测试通过、需要决定如何集成工作时使用——通过提供合并、PR 或清理等结构化选项来引导开发工作的收尾
当需要开始与当前工作区隔离的功能开发，或在执行实现计划之前使用——通过原生工具或 git worktree 回退机制确保隔离工作区存在
中文 review 沟通参考——话术模板、分级标注（必须修复/建议修改/仅供参考）、国内团队常见反模式应对。仅在用户显式 /chinese-code-review 时调用，不要根据上下文自动触发。
| name | receiving-code-review |
| description | 收到代码审查反馈后、实施建议之前使用，尤其当反馈不明确或技术上有疑问时——需要技术严谨性和验证，而非敷衍附和或盲目执行 |
| version | 1.0.0 |
| license | MIT |
| metadata | {"hermes":{"tags":["code-review"]}} |
代码审查需要的是技术评估，不是情绪表演。
核心原则： 先验证再实施。先提问再假设。技术正确性优先于社交舒适度。
收到代码审查反馈时：
1. 阅读：完整阅读反馈，不急于反应
2. 理解：用自己的话复述需求（或提问）
3. 验证：对照代码库的实际情况检查
4. 评估：对这个代码库来说技术上合理吗？
5. 回应：技术性确认或有理有据的反驳
6. 实施：一次一项，逐个测试
绝不要说：
应该这样做：
如果有任何一项不明确：
停下来——先不要实施任何内容
就不明确的项目提出澄清
为什么：各项之间可能有关联。部分理解 = 错误实施。
示例：
搭档："修复第 1-6 项"
你理解 1、2、3、6。对 4、5 不确定。
❌ 错误做法：先实施 1、2、3、6，稍后再问 4、5
✅ 正确做法："第 1、2、3、6 项我理解了。第 4 和第 5 项需要澄清后再动手。"
实施之前：
1. 检查：对这个代码库来说技术上正确吗？
2. 检查：是否会破坏现有功能？
3. 检查：当前实现这样写是否有原因？
4. 检查：在所有平台/版本上都适用吗？
5. 检查：审查者了解完整上下文吗？
如果建议似乎有误：
用技术理由反驳
如果无法轻易验证：
说明情况："没有 [X] 我无法验证这一点。我应该 [调查/提问/先做]？"
如果与搭档之前的决策冲突：
先停下来和搭档讨论
搭档的原则： "对外部反馈要持怀疑态度，但要仔细核实"
如果审查者建议"正规地实现"：
在代码库中 grep 实际使用情况
如果没人用："这个接口没有被调用。删掉它（YAGNI）？"
如果有人用：那就正规实现
搭档的原则： "你和审查者都对我负责。如果我们不需要这个功能，就不要加。"
对于包含多项的反馈：
1. 先澄清所有不明确的项
2. 然后按以下顺序实施：
- 阻塞性问题（崩溃、安全）
- 简单修复（拼写、导入）
- 复杂修复（重构、逻辑）
3. 逐个测试每项修复
4. 验证没有回归
在以下情况反驳：
如何反驳：
如果觉得不方便当众反驳，暗号是： "Strange things are afoot at the Circle K"
当反馈确实正确时：
✅ "已修复。[简要说明改了什么]"
✅ "发现得好——[具体问题]。已在 [位置] 修复。"
✅ [直接修复并在代码中体现]
❌ "你说得太对了！"
❌ "好观点！"
❌ "感谢你发现了这个！"
❌ "感谢你 [任何内容]"
❌ 任何感谢的表达
为什么不用感谢： 行动说明一切。直接修复。代码本身就能表明你收到了反馈。
如果你发现自己要写"感谢"： 删掉它。直接说明修复内容。
如果你反驳了但事后发现自己错了：
✅ "你是对的——我检查了 [X]，确实 [Y]。正在实施。"
✅ "验证后确认你是对的。我最初的理解有误，因为 [原因]。正在修复。"
❌ 长篇道歉
❌ 为自己的反驳辩护
❌ 过度解释
如实陈述纠正，然后继续。
| 错误 | 修正 |
|---|---|
| 敷衍附和 | 复述需求或直接行动 |
| 盲目实施 | 先对照代码库验证 |
| 批量实施不测试 | 一次一项，逐个测试 |
| 假设审查者一定对 | 检查是否会破坏现有功能 |
| 回避反驳 | 技术正确性 > 社交舒适度 |
| 部分理解就开始实施 | 先澄清所有项 |
| 无法验证却继续推进 | 说明限制，请求指导 |
敷衍附和（反面例子）：
审查者："删除遗留代码"
❌ "你说得太对了！让我删掉它……"
技术验证（正面例子）：
审查者："删除遗留代码"
✅ "查了一下……构建目标是 10.15+，这个 API 需要 13+。向后兼容需要保留遗留代码。当前实现有错误的 bundle ID——修复它还是放弃 pre-13 支持？"
YAGNI（正面例子）：
审查者："实现完善的指标追踪，包括数据库、日期过滤、CSV 导出"
✅ "在代码库中 grep 了一下——没有任何地方调用这个接口。删掉它（YAGNI）？还是有我遗漏的调用？"
不明确的项（正面例子）：
搭档："修复第 1-6 项"
你理解 1、2、3、6。对 4、5 不确定。
✅ "第 1、2、3、6 项我理解了。第 4 和第 5 项需要澄清后再动手。"
在 GitHub 上回复行内审查评论时，在评论线程中回复（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），不要发顶层 PR 评论。
外部反馈 = 待评估的建议，不是必须执行的命令。
验证。质疑。然后实施。
不要敷衍附和。始终保持技术严谨。