用途：在收到代码评审反馈、准备实施建议之前使用，尤其适用于反馈不清楚、有风险、有争议或技术上存疑的情况。核心原则是先验证再实施、先提问再假设，技术正确性优先于社交舒适。
主要能力：给出接收反馈的响应流程——完整读完反馈、用自己的话复述需求、对照代码库实际情况验证、评估是否适合当前代码库、给出技术性确认或有理有据的反驳、逐条实施并逐条测试。明确禁止表演式回应，如“你说得完全对”“好观点”“感谢指出”等，改为复述技术要求、提出澄清问题、用技术理由反驳，或直接动手修改。
使用方式：对不清楚的条目先停下，不要实施任何内容，先请求澄清，因为条目之间可能相关，部分理解会导致错误实现。区分反馈来源：来自人类搭档的反馈可信，理解后实施，但范围不清仍要提问；来自外部评审者的反馈要先检查是否技术正确、是否破坏现有功能、当前实现的原因、是否兼容所有平台版本、评审者是否了解完整上下文，无法验证时说明限制并询问方向，与人类搭档既有决策冲突时先停下讨论。对“正确实现”类建议先 grep 代码库确认实际使用情况，未被调用则按 YAGNI 建议移除。多条反馈按阻塞问题、简单修复、复杂修复的顺序实施，逐条测试并确认无回归。
适用场景：处理代码评审意见、GitHub 行内评论回复（应在评论线程内回复，而非顶层 PR 评论）、判断是否采纳外部建议、纠正自己错误的反驳。
限制：资料未提供安装命令、平台支持、收费或价格信息。