该技能用于 AI 编程助手接收代码审查反馈、在实施建议之前的处理方式，尤其是反馈含义不清或技术上存疑时。核心原则是：先核验再实现，先提问再假设，技术正确性优先于社交舒适度。
主要能力与流程：收到反馈后依次执行 READ（完整阅读不急于反应）、UNDERSTAND（用自己的话复述需求或提问）、VERIFY（对照代码库实际情况核查）、EVALUATE（判断对该代码库是否技术合理）、RESPOND（技术性确认或有理由的反驳）、IMPLEMENT（逐项实施并逐项测试）。禁止表演式回应，如“你完全正确！”“好观点！”“感谢指出”等；应改为复述技术要求、提出澄清问题、用技术理由反驳，或直接动手。
处理不清楚的反馈时，若有任何条目不明，应停止实施，先就不明条目提问，因为条目之间可能相关，理解不完整会导致实现错误。
针对不同来源：来自人类搭档的反馈可信任，理解后实施，范围不清仍需提问；来自外部评审者的反馈，实施前需核查是否对该代码库技术正确、是否破坏现有功能、当前实现的原因、是否兼容所有平台与版本、评审者是否了解完整上下文。若建议看似错误，用技术理由反驳；若难以验证，说明“没有 X 我无法验证，是否应该调查/询问/继续”；若与人类搭档先前决定冲突，先与其讨论。
对“专业化实现”类建议做 YAGNI 检查：在代码库中 grep 实际调用，若未被使用可建议移除，若确有使用再正式实现。
多条目反馈的实施顺序：先澄清不明确项，再按阻塞问题（破坏、安全）、简单修复（拼写、导入）、复杂修复（重构、逻辑）处理，逐项测试，确认无回归。
需要反驳的情形包括：建议破坏现有功能、评审者缺乏完整上下文、违反 YAGNI、对该技术栈不正确、存在遗留或兼容性原因、与搭档的架构决策冲突。反驳时使用技术推理、具体提问、引用可工作的测试或代码，涉及架构时请搭档参与。
反馈正确时应简短确认，如“已修复：[简述改动]”或“好发现——[具体问题]，已在[位置]修复”，或直接改在代码中，不表达任何感谢。若反驳后发现错误，应事实性说明纠正并继续。
在 GitHub 上回复行内评审评论时，应在评论线程内回复（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），而不是作为 PR 顶层评论。
限制与边界：该资料仅描述此技能的反馈处理规范，未提供安装命令、收费、价格、平台兼容范围等信息，暂未提供。