用途：在收到代码审查反馈后、真正动手实施建议之前使用，帮助判断反馈是否技术合理，避免情绪化回应或未经核实的批量修改。
主要能力：给出响应流程（阅读、理解、验证、评估、回应、实施）；列举禁止的回应方式（如空泛附和的“你说得太对了”“好观点”等）与推荐做法（复述技术需求、提出澄清问题、用技术理由反驳）；区分搭档反馈与外部审查者反馈的处理差异；针对“专业化”功能建议进行 YAGNI 检查，先在代码库中确认是否有实际调用；给出实施顺序：先澄清全部不明确项，再依次处理阻塞性问题、简单修复、复杂修复，逐项测试并验证无回归。
使用方式：收到反馈后完整阅读并用自己的话复述需求；对不明确项先停下来提问，不要部分理解就开工；外部审查建议需检查是否技术正确、是否破坏现有功能、当前实现是否有既定原因、是否跨平台版本适用、审查者是否了解完整上下文；若建议有误会以技术理由反驳，无法验证则说明限制并请求指导；与搭档既有架构决策冲突时先讨论。GitHub 行内评论回复应在线程中回复：gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies，而非发顶层 PR 评论。
适用场景：代码审查反馈处理、PR 评审沟通、多人协作中的修改决策。
限制：资料为协作流程规范，不涉及具体语言或工具链；正式规则中提到的 CLAUDE.md 等约束以所在项目为准；价格、平台支持等未提供。