技能介绍

问题在哪

PR 一来就改、先表态再核对，是线上 bug 和无效 diff 的常见来源。评审人可能误判上下文，自动化 agent 更会堆「以防万一」的改动；作者若用社交礼貌代替技术判断，坏建议也会进主干。更麻烦的是多轮评审：上一轮指出的问题若没对齐，新评论会盖过旧债。

技能如何工作

核心原则是 Verify before implementing：技术正确性优先于「看起来配合」。对每条反馈按固定顺序处理：

再评审时（第 0 步）：用 PR 评论线程对照当前 diff，优先处理被忽略或只修了一半的旧问题。
Read → Verify → Evaluate → Respond → Implement：先理解建议，再判断对本仓库是否成立，区分真缺陷与风格偏好；不清楚就 Stop，一次性澄清，不盲改。
分来源对待：项目方意见信任业务上下文但仍要验技术；对 automated review agents 默认怀疑，对照 CLAUDE.md 与 grep 查 YAGNI；外部评审要核对框架版本与架构决策。
反驳要有证据：用 file:line、测试输出、文档版本说明；驳回时可标 FP-ASSUMPTION / FP-CONVENTION / FP-ALREADY-HANDLED / FP-OUT-OF-SCOPE，避免空口「不同意」。
实施顺序：先澄清 → 阻塞项 → 简单修复 → 复杂改动；每条改完单独测，不要批量改完再测。

GitHub 场景下建议在 inline 线程回复（in_reply_to），核实后再 resolve；与 ia-code-review（发起评审）、ia-pr-comment-resolver（已分拣的单条机械修复）、ia-verification-before-completion（完工前验证）分工配合。

边界与注意

交互模式适合需要判断的反馈；headless 只做结构化分拣（AUTO-FIX / AUTO-DECLINE / ESCALATE），见 headless-mode 说明。
已明确分类、无需争辩的 nit，应交给 ia-pr-comment-resolver，本技能不替代其「低怀疑、单条落地」角色。
关键路径上多条含糊意见且可用 AskUserQuestion 时，可批量最多 4 条做 Valid / False positive / Defer；非关键路径含糊项可自动分拣继续推进。