用途：处理代码审查反馈，在动手修改前先核实建议是否技术正确，而非为社交舒适盲目照做。适用于收到 PR 评论、自动代理建议或外部评审意见时。
主要能力：对每条反馈按读、验证、评估、回应、实现五步处理；先对待办分类再逐条实现，每条修改后单独测试。可处理模糊反馈，先澄清全部不明项再实现任何一项；关键路径上的歧义（如鉴权、支付、数据迁移、权限校验）在可用 AskUserQuestion 时最多批量 4 条提问，否则以编号散文列出，选项为 Valid / False positive / Defer。
来源区分：来自项目所有者视为可信上下文，理解后仍要验证；来自自动审查代理默认存疑，逐条对照代码库，检查 YAGNI，丢弃与项目约定冲突的建议；来自外部评审则核对是否适用于当前技术栈与版本。
反驳与 dismissing：当建议破坏现有功能、违反项目约定、技术错误、增加不必要复杂度、未使用或与架构决策冲突时，凭证据反驳。证据可为代码引用、测试输出、git blame/log、框架文档、复现步骤、grep 结果等。拒绝建议时用标签：FP-ASSUMPTION、FP-CONVENTION、FP-ALREADY-HANDLED、FP-OUT-OF-SCOPE，并附所需证据。
用法与限制：回复模板强调“已验证—具体问题—实施具体修复”，禁止“谢谢”“说得对”等表演式用语。GitHub PR 用 gh api 的 in_reply_to 在内联线程回复，验证通过后再标记解决。无头模式下跳过交互提示，返回结构化分类结果。与 ia-code-review、ia-pr-comment-resolver、ia-verification-before-completion 配合使用。资料未提供具体安装命令、收费、平台与效果信息。