القائمة
收到代码审查反馈后、实施建议之前使用，尤其当反馈不明确或技术上有疑问时——需要技术严谨性和验证，而非敷衍附和或盲目执行
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
在开始任何对话时使用——确立如何查找和使用技能，要求在任何响应（包括澄清性问题）之前调用 Skill 工具
在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能或修改行为。在实现之前先探索用户意图、需求和设计。
中文 review 沟通参考——话术模板、分级标注（必须修复/建议修改/仅供参考）、国内团队常见反模式应对。
中文 commit 与 changelog 配置参考——Conventional Commits 中文适配、commitlint/husky/commitizen 中文模板、conventional-changelog 中文配置。仅在用户显式 /chinese-commit-conventions 时调用，不要根据上下文自动触发。
中文文档排版参考——中英文空格、全半角标点、术语保留、链接格式、中文文案排版指北约定。仅在用户显式 /chinese-documentation 时调用，不要根据上下文自动触发。
国内 Git 平台配置参考——Gitee、Coding.net、极狐 GitLab、CNB 的 SSH/HTTPS/凭据/CI 接入差异与镜像同步配置。仅在用户显式 /chinese-git-workflow 时调用，不要根据上下文自动触发。
| name | receiving-code-review |
| description | 收到代码审查反馈后、实施建议之前使用，尤其当反馈不明确或技术上有疑问时——需要技术严谨性和验证，而非敷衍附和或盲目执行 |
代码审查需要的是技术评估，不是情绪表演。
核心原则： 先验证再实施。先提问再假设。技术正确性优先于社交舒适度。
收到代码审查反馈时：
1. 阅读：完整阅读反馈，不急于反应
2. 理解：用自己的话复述需求（或提问）
3. 验证：使用 read_file(path="...") 和 search_content(pattern="...") 对照代码库的实际情况检查
4. 评估：对这个代码库来说技术上合理吗？
5. 回应：技术性确认或有理有据的反驳
6. 实施：使用 edit_file(path="...", old="...", new="...") 一次一项修改，用 run_command(command="...") 逐个测试
绝不要说：
应该这样做：
如果有任何一项不明确：
停下来——先不要实施任何内容
就不明确的项目提出澄清
为什么：各项之间可能有关联。部分理解 = 错误实施。
示例： 搭档要求修复 1-6 项，你理解 1、2、3、6，对 4、5 不确定。 ❌ 错误：先实施 1、2、3、6，稍后再问 4、5 ✅ 正确："第 1、2、3、6 项我理解了。第 4 和第 5 项需要澄清后再动手。"
实施之前检查：
如果建议似乎有误：用技术理由反驳。 如果无法轻易验证：说明限制，请求指导。 如果与搭档之前的决策冲突：先停下来和搭档讨论。
如果审查者建议"正规地实现"：使用 search_content(pattern="接口名或函数名") 在代码库中搜索实际使用情况。
如何反驳： 用技术理由，不要带防御情绪。提出具体问题。引用可正常工作的测试/代码。如果涉及架构问题，让搭档参与。
当反馈确实正确时： ✅ "已修复。[简要说明改了什么]" ✅ "发现得好——[具体问题]。已在 [位置] 修复。" ✅ [直接修复并在代码中体现]
❌ "你说得太对了！" / "好观点！" / "感谢你发现了这个！" / 任何感谢的表达
为什么不用感谢： 行动说明一切。直接修复。代码本身就能表明你收到了反馈。
如果你反驳了但事后发现自己错了： ✅ "你是对的——我检查了 [X]，确实 [Y]。正在实施。" ✅ "验证后确认你是对的。我最初的理解有误，因为 [原因]。正在修复。"
❌ 长篇道歉 / 为自己的反驳辩护 / 过度解释
| 错误 | 修正 |
|---|---|
| 敷衍附和 | 复述需求或直接行动 |
| 盲目实施 | 先用 read_file(path="...") 和 search_content(pattern="...") 对照代码库验证 |
| 批量实施不测试 | 一次一项，用 edit_file 修改后用 run_command 逐个测试 |
| 假设审查者一定对 | 检查是否会破坏现有功能 |
| 回避反驳 | 技术正确性 > 社交舒适度 |
| 部分理解就开始实施 | 先澄清所有项 |
| 无法验证却继续推进 | 说明限制，请求指导 |
外部反馈 = 待评估的建议，不是必须执行的命令。
验证。质疑。然后实施。
不要敷衍附和。始终保持技术严谨。