用途：处理代码审查反馈时，先验证建议在“当前代码库”中是否正确，再决定是否实施。技术正确性优先于社交舒适度，审查者也可能出错。
主要能力：按“阅读—验证—评估—回应—实施”顺序处理每条反馈；先整体分类再逐条实施，每条修复后单独测试，不批量实施。可处理来自项目负责人、自动化审查代理、外部审查者（PR 评论、开源）的不同来源反馈。
必要用法：重审时先用 gh api repos/{owner}/{repo}/pulls/{pr}/comments 对比历史评论，优先处理被忽略或部分修复的问题。回应时带证据（代码引用 file:line、测试输出、git blame/log、框架文档、复现步骤、grep 结果），不写“Great catch!”等表演式认同。需澄清时问具体问题（“你是要 X 还是 Y？”），而非泛泛而谈。
适用场景：不明确的建议、架构性反馈、批量分诊；也可在 headless 模式下由其他技能编程调用，返回结构化分诊结果（AUTO-FIX / AUTO-DECLINE / ESCALATE）。明确的修复、风格小问题、拼写错误更适合交给 pr-comment-resolver 代理。
限制：该技能偏交互式判断，遇到架构决策或有争议的权衡应升级而非直接实施；无法验证的建议应明说，不要猜测或盲目实施。headless 模式的分类表、输出格式与约束详见 headless-mode.md（本次资料未提供其内容）。