用途：当 PR/MR 存在人工或自动评审意见需要查看、处理或答复时使用。先基于真实评论和当前代码工作，改动或回复前先核实结论。
范围：若用户只要求检查或汇总评论，则收集评估后报告，不改代码、不发回复；若要求处理或答复，则应用已验证的修复、运行相关检查并按授权回复。通过链接、编号、当前分支或仓库上下文确定目标 PR/MR，仅在存在多个可能目标时询问。使用团队已有的认证工具；若缺少 GitHub CLI 且确有帮助，可阅读可选的一次性安装指南并向用户提议，而非默认安装。
工作流：每次使用都必须先识别评审平台并阅读对应流程（GitHub、GitLab 或 Bitbucket），即使以前用过也要重读该平台参考，其中含收集、回复与解决步骤；跳过其他平台参考。收集全部反馈，包括评审摘要、行内评论与回复、未解决线程和 CI 状态，并检查最后一次推送后的新评论；不要假设配置了某个机器人评审。逐条核实：检查相关代码、尽量复现行为或运行针对性检查，涉及库或 API 时查阅最新文档，标记为有效、已处理、不明确或无法支持，未改动项需说明证据。按需做聚焦修复，遵循仓库的分支、提交与测试规则，保持独立修复可评审，不为满足评论改动无关行为，检查通过前不声称已修复。回复时默认发一条汇总回复覆盖所有发现，含修复、证据和未改动原因；仅当用户要求或平台/仓库要求时才逐线程回复，避免重复。检查就绪状态，仅在用户授权（含对话中已授权）时合并，处理评论本身不构成合并授权。若结论仍不明确、评审者互相矛盾或需用户决策，说明冲突并请求决定，绝不只为关闭线程而应用未经验证的建议。
等待评审：只等待已请求或仓库已知配置预期的评审者；出现反应、评论或评审请求状态变化视为有活动，可再等并复查；明确拒绝则结束等待。无活动时约每 3–4 分钟检查一次，最多三次，然后报告尚无评审并停止轮询；可用定时器或后台监控避免阻塞。不得仅因没有评论就声称机器人评审通过。
回复格式：每条发现给出位置或评审者引用，并标注：已修复（改动、测试或检查证据、可用时附提交）、已处理（现有代码或早前提交的处理位置）、未改动（具体原因及代码或文档支持）、需决策（未决问题及其对 PR/MR 的影响）。回复应简短易扫读，仅在发现已处理且团队流程允许时解决线程。