用途
该技能用于处理代码评审反馈，适用于收到代码评审意见后、准备实施建议之前，特别是当反馈内容不清晰或技术上有疑问时。其核心原则是：先验证再实施，先询问再假设，技术正确性优先于社交舒适。
主要能力
- 响应模式：接收反馈时依次执行：完整阅读反馈不作反应；用自己的话复述需求（或提问）；对照代码库实际情况核实；评估对该代码库是否技术合理；给出技术确认或有理由的反驳；逐条实现并测试。
- 禁止的回应：不得使用“你完全正确！”“好观点！”“我马上实现”等表演式附和，应复述技术需求、提出澄清问题、用技术理由反驳或直接开始工作。
- 处理不清晰反馈：如果任何一项不清楚，就停止，先不要实现任何内容，先就不清楚的项请求澄清。因为各项可能相关，理解不完整会导致错误实现。例如伙伴说“修复 1-6”，你理解 1、2、3、6 但不清楚 4、5，正确做法是先说明自己理解的部分，并要求澄清 4 和 5 后再动手。
- 区分来源：来自人类伙伴的反馈可信，理解后实施，但范围不清时仍要询问，不做表演式同意；来自外部评审者的反馈，在实施前要检查：对本代码库是否技术正确、是否破坏现有功能、当前实现的原因、是否在所有平台/版本可用、评审者是否了解完整上下文。若建议有误，用技术理由反驳；若无法轻易验证，说明限制并询问方向；若与人类伙伴此前决策冲突，先停下来与伙伴讨论。
- YAGNI 检查：若评审者建议“正确实现”某功能，先在代码库中搜索实际使用情况。若未被使用，可提出按 YAGNI 移除；若确实被使用，再正确实现。
- 实现顺序：多项反馈先澄清不清楚的部分，然后按阻塞性问题（破坏、安全）、简单修复（拼写、导入）、复杂修复（重构、逻辑）的顺序实施，逐项测试并验证无回归。
- 何时反驳：当建议破坏现有功能、评审者缺少完整上下文、违反 YAGNI、对本技术栈技术不正确、存在遗留/兼容原因、或与人类伙伴的架构决策冲突时应反驳。反驳方式是用技术推理而非防御性态度，提出具体问题，引用可工作的测试或代码，架构问题则让人类伙伴参与。
- 确认正确反馈：反馈正确时，直接说明修复内容，如“已修复，改动如下”或“好发现，某问题已在某处修复”，或直接在代码中展示。不得表达感谢。
- 纠正自己的反驳：如果反驳后发现自己错了，应事实性地承认并继续，如“你是对的，我查了 X，它确实 Y，现在实施”，避免冗长道歉、为自己反驳辩护或过度解释。
使用方式
这是一个技能说明，提供响应代码评审的具体步骤、禁止项、处理流程和示例，供 AI 或开发者参照执行。
适用场景
- 收到人类伙伴或外部评审者的代码评审反馈。
- 反馈中存在不清晰或技术上有疑问的项。
- 需要判断建议是否符合当前代码库、是否破坏功能、是否违反 YAGNI。
- 在 GitHub 上回复行内评审评论时，应使用
gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies在评论线程中回复，而不是作为 PR 顶层评论。
限制
资料未提供该技能的具体平台依赖、安装命令、价格或收费信息。