review-loop 是一个围绕 review-multi-model 构建的循环包装技能，核心思路是：审查 → 应用经确认的修复 → 再审查 → 再修复，直到某一轮审查不再发现“重要”的问题。资料指出，一次修复可能引入新缺陷，清除一个问题后的审查常会暴露上一轮看不到的另一个问题，因此单次审查加修复很少能到达稳定点。
用途与原理
循环只针对工作区（working tree）运行。每轮重新审查上一轮刚编辑过的代码，因此修复必须写入工作区，才能被下一轮观察到。这与 review-multi-model 的分支模式（工作区对比合并基）对应：每轮对工作区做 diff，从而看到上一轮的修复。技能强调不要进入计划模式，直接执行、迭代，并在对话中内联呈现每轮进度和最终收敛总结；结果只写入 review-multi-model 自己的临时目录。
审查对象与参数
默认以分支模式循环。若用户传入 PR 参数，该 PR 必须已检出（最好在独立 worktree 中），循环才能在分支模式下针对 PR 自身的基线分支（其合并目标，例如 release/1.x，可能不是仓库默认分支）进行审查。需先获取该基线：REVIEW_BASE=$(gh pr view <n> --json baseRefName -q .baseRefName) || exit 1，失败即中止，不能让基线静默回退到默认分支；并在循环前执行 git fetch origin "$REVIEW_BASE"，避免陈旧本地引用把已合并变更混入 diff。不要在 gh pr diff 上循环，因为它反映已推送的 PR，而非本地未提交的修复。不支持 --staged，也不是直通参数，因为修复不会重新暂存，git diff --staged 每轮都显示未变的暂存区，循环无法收敛；如需一次性暂存审查，可运行 /review-multi-model --staged。若 PR 未检出，应在第 1 轮前说明并停止（先 gh pr checkout <n>），不要自行切换用户的分支或 worktree。--claude-only / --codex-only 原样透传；修复步骤始终开启。
模型面板与降级
面板由 Claude 与 Codex 组成。Codex 不可用（用量限制、未登录）时，改用第二个独立的 Claude 审查者（全新上下文、最强模型）填补席位，并在报告中说明 Codex 未运行；两路独立上下文的审查仍能发现互补缺陷。
什么算“重要”发现
审查结果分两类。重要（继续循环）：真实用户、CI 或产品工具会触发的行为缺陷（错误输出、崩溃、卡死、数据丢失、CI 中断、错误的客户可见信息）、上一轮修复引入的回归；攻击者能获利的任何安全缺陷（跨租户访问、密钥、他人数据）；完整性缺口（没有 story 的 UI 状态、没有对应测试的行为变更或夸大覆盖的测试、代码已与之矛盾的注释或文档，包括内部架构文档、用户文档、技能）。打磨类（不继续循环）：不涉及错误的命名与措辞偏好、重复测试夹具、需要手工构造且最坏只伤及自身的输入。不确定时问：“如果人类审查者提出，我会因此阻塞 PR 吗？”不会就是打磨。
范围控制
只修复用户所要求变更范围内的发现。相邻代码的既有缺口、相关子系统、“顺便加固”等放入最终报告的后续清单，不进入 diff；每个越界修复都是下一轮要重新审查的新表面，正是循环“永远发现新东西”的根源。
一轮迭代的构成
一次迭代 = 一次完整的 review-multi-model 运行并应用其修复：审查阶段（计算工作区 diff → 双审查者 → 裁决 → 呈现）加修复步骤（--fix，应用经确认、达成一致的修复）。每轮严格遵循 review-multi-model 技能原文，不重新实现审查。每轮全新开始（新 diff、新临时目录、两个新审查者），修复引入的回归会在下一轮显现。
流程：先审查，记录已确认发现数、是否出现有后果的未验证项、所请求面板是否完整运行、每个发现的指纹。在改代码前判断：无重要发现且无有后果的未验证项 → 收敛，就地应用打磨类修复、运行门禁并停止，打磨修复不需要确认轮；触发无进展或仅有不可应用发现的停止条件 → 停止并报告；否则进入修复。修复时应用已确认修复，并对自身修复做完整性清扫（新增渲染分支要配 story，行为变更要检索并更新描述它的注释/文档并补测试），随后进入下一轮确认。改变行为的修复总需要一轮确认；全部为打磨修复的轮次不需要。--max-iterations 限制运行轮数，默认 5。收敛由“无重要发现的审查”判定，绝不在行为修复后假定收敛；达到上限且最后一轮仍有发现时，报告这些已应用但未确认的修复及最后一轮仍开放的发现，并建议提高 --max-iterations 重跑确认。
发现指纹与停止条件
指纹按缺陷及其位置（文件加具体构造/区域，或修复会改变的对象）语义匹配：同一缺陷同一位置即视为“相同”，即使措辞不同或行号漂移；不要按精确措辞或行号匹配。停止条件按首个满足者执行：收敛（成功，含空 diff 也算收敛）；轮数上限（默认 5，健康循环通常 2 到 4 轮收敛，超过 5 仅当用户传入更高上限或第 5 轮本身发现重要缺陷时再加一轮确认后停止）；收益递减（连续两轮无重要发现，或某轮唯一重要发现是上一轮修复引入的回归且该修复本身是打磨或越界，则停止并回滚越界修复）；无进展/震荡（对同一指纹做过修复却持续被报告为停滞；修复后消失又重现为震荡；两者都停止并标记该发现）；仅剩不可应用发现（修复步骤有意跳过的低置信度或需人工决策项，或有后果的未验证项）则停止并列出。绝不死循环，不确定集合是否在缩小时宁可停止并报告。
护栏与报告
只改工作区，不提交、不推送、不开 PR（除非用户在收敛后要求）。每个修复是否生效由下一轮全新 diff 再审查作为安全网验证，不得未经验证就宣称“已修复”。目标是解决重要问题而非追求零计数，每轮约花费用户 10 分钟以上实际时间，因此一轮只发现一个缺失 story 往往是清扫被跳过的信号。每轮进度应说明发现类型（如“第 2 轮：1 个真实缺陷——畸形链接崩溃；3 个缺失 story；2 处过时注释”），让用户不必打断询问。循环结束后报告轨迹与最终状态、停止原因、批量应用的打磨项、未解决事项和越界后续清单；若收敛则说明面板认为 diff 干净；若因上限或卡住而停止，列出开放项并建议下一步（人工决策或针对性手工修复）。最后可选：用户要求时提交累积修复。报告还应把轨迹当作规则数据，指出反复出现的缺陷类别，并对可泛化的类别建议 add-rule。
适用场景与限制：适合已有代码变更、希望多模型反复审查直至稳定的开发流程；依赖 review-multi-model 技能、Claude 与 Codex 面板以及 git 工作区；不支持 --staged，不处理未检出 PR，不自动切换分支，不提交代码；轮数受默认上限约束；具体安装方式与命令资料暂未提供。