用途：这是一个处理代码评审反馈的技能，用于在实施评审建议之前进行技术评估，而非情绪化附和。核心原则是先验证再实施、先询问再假设，技术正确性优先于社交舒适度。
主要流程：收到反馈后先完整阅读、用自己的话复述需求或追问，再对照代码库现实核验，评估该建议是否适用于当前代码库，然后给出技术性确认或有理由的反驳，最后逐项实施并逐项测试。
处理不清晰反馈：若有条目不清楚应停止实施并先请求澄清，因为条目之间可能相关，部分理解会导致实现错误。例如被要求修复 1-6 项但只理解 1、2、3、6 时，应先说明并请求解释 4、5，而不是先做已理解的部分。
反馈来源区分：来自人类搭档的反馈可信，理解后实施；来自外部评审者的反馈需先检查是否技术正确、是否破坏现有功能、原实现原因、是否兼容所有平台与版本、评审者是否了解完整上下文；无法轻易验证时应说明限制并询问。若与人类搭档此前的架构决策冲突，应先与人类搭档讨论。
YAGNI 检查：当评审者建议“正确实现”某功能时，可先在代码库中搜索实际调用；若未被使用，可提出移除（YAGNI）。实施顺序为先阻塞性问题（破坏、安全），再简单修复（拼写、导入），再复杂修复（重构、逻辑），每项单独测试并确认无回归。
禁止的回应：避免“你完全正确！”“好观点！”“谢谢指出”等表演式或感谢性表述；应直接陈述技术需求、提问、以技术理由反驳，或直接开始修改并用代码体现。若反驳后发现自己有误，应事实性说明更正并继续，不作冗长道歉或辩解。
GitHub 场景：回复 PR 内联评审评论时，应回复在对应评论线程（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），而非顶层 PR 评论。
适用与限制：适合接收代码评审反馈的开发者与 AI 编程代理。资料未提供具体安装命令、平台依赖、收费或效果数据，这些暂未提供。