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