用途：在收到代码审查反馈后、实施建议前使用，指导如何以技术严谨的方式评估和处理反馈，而不是执行社交协议或盲目落地。
主要能力与原则：实施前先验证，假设前先询问，技术正确性高于社交舒适度。响应流程为：完整阅读反馈、用自己的话复述需求（或提问）、对照代码库现实核验、评估是否适用于当前代码库、以技术确认或有理由的反驳回应、逐项实施并逐项测试。
禁止的回应包括：“你说得完全正确”“说得好”“非常好的反馈”“让我现在实施它”以及任何感谢表达；应改为复述技术要求、提出澄清问题、用技术推理反驳或直接开始工作。
处理不明确反馈：任一项不清楚就停止，先就不清楚项提问，因为条目之间可能相关，部分理解会导致错误实施。例：人类伙伴说“修复 1-6”，你只理解 1、2、3、6，应说明并请求澄清 4 和 5，而不是先做能做的部分。
区分来源：来自人类伙伴的反馈值得信任，理解后实施，但范围不清仍要问，不执行社交协议；来自外部审查者的反馈要先检查是否技术正确、是否破坏既有功能、当前实现原因、是否兼容所有平台版本、审查者是否了解完整上下文，若无法验证则说明限制并询问调查、追问还是继续。外部反馈总原则：持怀疑态度，但仔细检查。
对“专业实现”类建议先 grep 代码库确认真实使用情况：未被调用时可提出移除（YAGNI）；确有使用再正式实现。多条目反馈实施顺序为：先澄清所有不清楚项，再依次处理阻塞性问题（故障、安全）、简单修复（拼写、导入）、复杂修复（重构、逻辑），逐项测试，确认无回归。
何时推后：建议破坏现有功能、审查者缺乏完整上下文、违反 YAGNI、技术栈不适用、存在遗留或兼容性原因、与人类伙伴的架构决策冲突。反驳时使用技术推理而非防御性语气，提具体问题，引用工作测试或代码，架构问题请人类伙伴参与。确认正确反馈时只说修复内容与位置，不写感谢。若反驳后发现错了，如实陈述更正并继续，不写长道歉或过度解释。
GitHub 内联评论回复应使用评论线程回复接口（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），而不是顶层 PR 评论。
限制：资料未提供该技能的安装命令、依赖、平台支持范围或收费信息。