用途：当用户要求处理 GitHub PR 或 GitLab MR 上未解决或新增的评审反馈（含后续评论）时使用。该技能把评审反馈处理组织为端到端工作流。
主要能力：预检与触发器盘点；完整拉取评审上下文；建立条目级台账并分诊；实施修复；执行最多 3 轮评审-修复循环；提交并获取发布批准；同步回复与 PR/MR 上下文；推送并转换线程状态；最后验证自动化与完整性。条目台账区分稳定评论/note ID 与线程/讨论 ID，要求先穷尽分页、游标、续传令牌和嵌套评论连接后再过滤。
使用方式：预检时选择一个平台接口，优先使用能暴露分页、线程、评论、元数据和运行记录的 GitHub 或 GitLab 专用接口；否则用 gh/GitHub GraphQL 或 GitLab REST 访问确切的 PR/MR 主机。需对主机做精确凭据绑定。根据用户请求语义选择授权模式（自主或守卫），在自主模式下记录标准授权信封，任何超出信封的变更都需停止并报告。执行前需绑定权威源仓库、完整 head ref 与最终 SHA，并识别受信任/不受信任的 head 仓库。
适用场景：需要在单个 PR/MR 上闭环处理评审意见，且请求明确授权端到端评审处理、仓库与评审系统变更、并避免反复确认时。
限制：不执行不可信 head 代码于带凭据主机，除非在无凭据、网络默认关闭的隔离环境；缺少隔离时改为静态审查，守卫模式下询问受信任运行器或明确接受未验证范围，自主模式下停止并报告。提交与推送只有在可信基础仓库规则明确允许预先授权时才可纳入信封；仓库强制的提交后确认或单独推送确认在任何模式下都是强制检查点。推送须绑定权威源仓库、完整 head ref 和仅由可归属任务变更产生的最终 SHA。提交信息与 PR/MR 标题正文不得包含评审者姓名、评论 ID 或“address review”等表述。触发器排序规则要求最终触发写入基于最终 SHA 的权威远端 head 和冻结的发布上下文；延迟触发接受后的运行开始不被视为安全。本资料未提供具体安装命令或代码示例。