该技能用于指导开发者如何接收代码审查反馈，核心目标是把反馈当作需要评估的技术建议，而不是必须服从的指令。
用途 技能适用于收到代码审查反馈之后、开始实现建议之前，尤其适合反馈含义不清或从技术角度看存在疑问的情况。
主要能力与处理流程 技能给出的响应模式为：READ（完整阅读反馈且不立即反应）、UNDERSTAND（用自己的话复述需求或提问）、VERIFY（对照代码库实际情况检查）、EVALUATE（判断对该代码库是否技术上成立）、RESPOND（给出技术性确认或有理有据的反驳）、IMPLEMENT（一次只做一项并逐项测试）。
禁止的回应 技能明确禁止：绝对化赞同、表演式称赞、在验证前就表示立刻实现。替代做法是复述技术需求、提出澄清问题、用技术理由反驳错误建议，或者直接开始处理。
处理不清晰反馈 只要有任何一项不清晰，就应停下，不要先实现已理解的部分，因为条目之间可能相关，理解不完整会导致错误实现。示例中，若“修复 1-6”而只理解 1、2、3、6，正确做法是先说明理解范围，并要求澄清 4 和 5。
来源区分 来自人类搭档的反馈被认为是可信的，理解后实现，但范围不清仍需提问，不做表演式赞同。来自外部审查者的反馈则需先检查：对该代码库是否技术正确、是否会破坏现有功能、当前实现的原因、是否兼容所有平台与版本、审查者是否了解完整上下文。若建议看似错误，应带技术理由反驳；若无法轻易验证，应说明限制并询问应调查、提问还是继续；若与人类搭档此前决定冲突，应先与人类搭档讨论。
YAGNI 检查 当审查者建议“按规范正确实现”时，技能要求先在代码库中检索实际使用情况。若无人使用，可提出删除该端点（YAGNI）；若确有使用，再正确实现。
实现顺序 对于多条目反馈，先澄清所有不清楚之处，然后按阻塞性问题（破坏、安全）、简单修复（拼写、导入）、复杂修复（重构、逻辑）的顺序实现，并逐项测试、确认没有回归。
何时反驳 当建议破坏现有功能、审查者缺乏完整上下文、违反 YAGNI、对该技术栈技术不正确、存在遗留或兼容性原因、或与人类搭档的架构决定冲突时，应当反驳。反驳要使用技术推理而非防御姿态，提出具体问题，引用可运行的测试或代码，架构层面则引入人类搭档。
确认正确反馈 反馈正确时，应简短说明已修复内容或直接展示代码改动，不表达感谢或其他感激用语。
纠正自己的错误反驳 如果反驳后发现自己是错的，应事实性地说明对方正确、自己初始理解错误的原因，然后继续修复，不做冗长道歉或过度解释。
常见错误 技能列出常见错误及修正，包括表演式赞同、盲目实现、未测试就批量处理、默认审查者正确、回避反驳、部分实现、无法验证却继续等。
GitHub 线程回复 在 GitHub 回复行内审查评论时，应回复在评论线程内，而不是作为 PR 顶层评论发布。
适用场景与限制 该技能是面向代码审查接收过程的行为准则，不涉及具体产品或收费信息；其效果取决于开发者是否按流程执行。资料未提供该技能的安装命令、平台支持范围或与其他工具的集成方式。