用途：在收到代码评审反馈后、动手修改前，对反馈进行技术评估与处理。适用于来自人类搭档、外部贡献者或自动化工具的反馈，尤其是建议含糊、技术上可疑、涉及多项且可能相互影响，或与既有架构决策冲突的情况。
主要能力与原则：核心是“先验证再行动，先澄清再假设，技术准确性高于礼貌”。每条反馈都要做技术评估，无例外。处理流程为：吸收（不回应地读完所有评论）、复述（用自己的话说明每条要求）、交叉核对（对照实际代码库）、评估（对本项目是否技术成立）、回复（技术性确认或有理由的反对）、行动（逐项处理并独立验证）。
使用方式：收到反馈后先确认已完整阅读、能复述每条、已对照代码库、已标记含糊项（不要部分实现）、已发现与既有架构或搭档先前决策的冲突、已确定分诊顺序。若有任何含糊，先暂停并请求澄清，不要先做清楚的部分。分诊顺序为：先解决所有歧义，再依次处理阻塞项（崩溃、安全漏洞）、快速修复（拼写、缺失导入）、结构性改动（重构、逻辑重写），每项独立验证，全部完成后确认无回归。
限制与注意：禁止表演式回应，如“你说得完全对”“好观点”“感谢指出”等，改为复述技术诉求、提出澄清问题、以技术证据反对，或直接静默修复。对外部贡献者的建议先验证其技术合理性、是否破坏现有行为、当前实现为何如此选择、是否跨平台版本成立、贡献者是否掌握完整上下文；无法验证时说明限制并询问方向，不要猜测。对“最佳实践”类建议用 YAGNI 过滤：先搜索代码库实际使用情况，未被调用则询问是否移除。反对时以技术证据为先，架构争议交由人类搭档。在 GitHub 内联评论中回复应使用评论线程回复接口，而非顶层 PR 评论。资料未提供具体安装命令、收费或平台信息。