该技能用于接收代码审查反馈之后、动手实现建议之前的处理流程，核心原则是：先验证再实现，先询问再假设，技术正确性高于社交舒适度。
响应步骤：完整读完反馈不急于反应；用自己的话复述需求或提问；对照代码库实际情况核查；评估建议是否真正适用于当前代码库；给出技术性确认或有理有据的反驳；逐条实现并逐条测试。
禁止的回应方式包括："你说得完全对"、"好观点"、"很棒的反馈"等表演式附和，以及在验证之前就说"我现在就实现"。替代做法是复述技术要求、提出澄清问题、用技术理由反驳，或直接开始动手。
遇到不清楚的反馈时应停止实现，先就不明确项请求澄清，因为条目之间可能相关联，部分理解会导致错误实现。来自人类协作者的意见被视为可信，理解后即可实现，但范围不清仍要询问；来自外部审查者的意见需先核查：是否对该代码库技术正确、是否破坏现有功能、当前实现的原因、是否兼容所有平台版本、审查者是否了解完整上下文，无法轻易验证时直接说明并询问方向。
对于"正规实现"类建议，先用 grep 检查代码库实际使用情况，未被调用的功能可按 YAGNI 原则建议移除以示谨慎。多条目反馈的实现顺序为：先澄清不确定项，再依次处理阻塞性问题（破坏、安全）、简单修复（拼写、导入）、复杂修复（重构、逻辑），每条单独测试并确认无回归。
需要反驳的情形包括：建议破坏现有功能、审查者缺乏完整上下文、违反 YAGNI、对该技术栈不正确、存在兼容性原因、与人类协作者的架构决策冲突。反驳应使用技术理由而非防御性态度，必要时请人类协作者介入。
反馈正确时只需简洁说明修复内容与位置，不使用任何感谢类表达。若先前反驳有误，应事实性承认并继续推进，不做冗长道歉。在 GitHub 行内评论中回复时，应使用评论线程回复接口（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），而非顶层 PR 评论。
整体立场是：外部反馈是待评估的建议而非必须服从的命令，验证、质疑，然后再实现。