用途：该技能面向“收到代码审查反馈之后、开始实现建议之前”这一环节，要求对反馈做技术评估，而不是情绪化回应。核心原则是：先验证再实现，先询问再假设，技术正确性优先于社交舒适。
主要能力与流程：给出接收反馈的响应模式——完整读完反馈不急于反应；用自己的话复述需求或提问；对照代码库实际情况验证；评估该建议是否适合当前代码库；给出技术性确认或有理由的反驳；最后逐条实现并逐条测试。
禁止的回应：不得使用“你说得完全对！”“好观点！”“感谢指出！”等表演式认同或任何致谢表达，也不得在验证前就说“我马上实现”。替代做法是复述技术要求、提出澄清问题、用技术理由反驳，或直接动手。
处理不清晰的反馈：只要有任何一条不清楚就应停止，不要先实现清楚的部分，因为条目之间可能相关，部分理解会导致错误实现。例如对方说“修复 1-6”，你只理解 1、2、3、6，正确做法是先说明理解范围并请求澄清 4 和 5。
来源区分：来自人类搭档的反馈视为可信，理解后实现，但范围不清仍要问；来自外部评审者的反馈要先检查是否对当前代码库技术正确、是否破坏现有功能、当前实现的原因、是否兼容所有平台版本、评审者是否了解完整上下文。若建议有误，用技术理由反驳；若难以验证，说明缺少什么并询问是调查、询问还是继续；若与人类搭档此前的决定冲突，先停下与搭档讨论。
YAGNI 检查：当评审者建议“正规实现”某功能时，先在代码库中搜索实际调用；若无人使用，可提出按 YAGNI 移除；若确有使用，再正规实现。
实现顺序：先澄清所有不清楚项，再按阻塞问题（破坏、安全）、简单修复（拼写、导入）、复杂修复（重构、逻辑）的顺序处理，逐条测试并确认无回归。
何时反驳：建议破坏现有功能、评审者缺乏完整上下文、违反 YAGNI、对当前技术栈不正确、存在遗留或兼容原因、与搭档的架构决定冲突时。反驳应使用技术理由、提出具体问题、引用可运行的测试或代码，涉及架构时让搭档参与。
确认正确反馈：直接说明“已修复”及改动内容，或指出具体问题与修复位置，或直接改完在代码中体现，不要致谢。若自己反驳错了，应事实性地承认并继续，不做冗长道歉或辩解。
GitHub 线程回复：回复行内评审评论时，应回复在该评论线程内（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），而不是作为 PR 顶层评论。
限制：资料未提供该技能的安装方式、依赖、平台支持、收费或价格信息，暂未提供。