多模型审查（Codex + Claude）

多模型审查（Codex + Claude） 是做什么的？

独立的审查员在同一提交上读取相同的提示。此会话是唯一的修复者。在 Opus 5.5 高投入度会话中运行。

选项： $ARGUMENTS

设置

• 轮次上限：Code 20 到 50（默认 20；选择器中的 Standard、Long 和 Max 分别为 20、35 和 50），Docs 2，Final 2，外加 2 到 6 个备用轮次用于证据轮次（默认 2）。硬停止：它们的总和，默认为 26。每个阶段在其第一个干净的轮次结束，因此上限是上限值。旧的运行保留其自己的上限和限制。
• 审查员：默认为 Terra (gpt-6.1-terra) 和 Opus (Opus 5.5)。可选：Fable (Fable 5.2)、Astra (gpt-6-astra)、Sol (gpt-6.1-sol)、Sonnet (Sonnet 5.5)、Haiku (Haiku 5.5) 和 Luna (gpt-6-luna)。在此更改之前开始的运行将其 Opus 审查员称为 claude。
• 每次运行为每个审查员设置投入度：低、中、高、非常高或最高。默认值：Codex 最高，Claude 模型非常高。
• 默认面板：terra:max:fast opus:xhigh code:20 spare:2。
• 为每个 Codex 审查员设置 Codex 快速模式（优先级层），每次运行。它从不适用于 Claude 模型。
• 每个 Codex 运行在静默 10 分钟或总计 60 分钟后停止。崩溃和空答案获得 1 次重新运行。答案永远不会因为其格式而重新运行。

下面的助手强制执行这些限制，并将所有状态保存在 ~/.claude/multimodel-review/ 中，位于每个仓库之外，因为长时间运行会被压缩，且无法从内存重建报告。每次写出其完整路径，如果 shell 不在仓库内，则在子命令前添加 --repo <path>：

python3 ~/.claude/skills/multimodel-review/scripts/mmr.py status

下面，mmr <command> 是该完整调用的简写。

启动或恢复

1. 运行 mmr status。如果存在未完成的运行，则从其显示的内容继续，使用其列出的审查员。如果显示“旧位置”，则在每个审查员完成后运行 mmr migrate，然后仅使用新路径。
2. 在任何其他步骤之前选择选项，以便所有者立即看到它们：
   • 如果上面的选项行仅为 pick（或 picker）：显示选择器（接下来的两个项目符号）。
   • 否则，无论它是否为空：运行 mmr options "<options>" 并且不显示选择器。空表示默认值 terra:max:fast opus:xhigh code:20 spare:2。如果失败，则向所有者显示其单行错误并停止。每个审查员为 name[:effort][:fast]：投入度默认为 Codex 最高和 Claude 模型非常高，并且除非给出 :fast，否则 Codex 模型以标准速度运行。code:<20-50> 和 spare:<2-6> 是可选的（默认值 20 和 2）。
   • 选择器，如果 show_widget 可用：首先使用模块 ["interactive"] 调用 read_me。然后运行 mmr picker 并将其 Widget code: 行之后的所有内容作为 widget_code 传递，标题为 multimodel_review_options。结束轮次并等待。其按钮发送“使用 开始审查。”，形式相同，例如“terra:max:fast opus:xhigh code:20 spare:2”。在其上运行 mmr options "<options>"。如果所有者的消息表明选择器未加载，则运行 mmr picker --offline 并改为显示该内容。
   • 终端中的选择器（无 show_widget）：一次 AskUserQuestion 调用，包含四个问题：审查员（多选：Terra, Opus, Fable, Astra; Sol, Sonnet, Haiku 和 Luna 通过 Other）、Codex 模型快速模式（多选：Terra, Astra, Sol, None; Luna 通过 Other）、投入度（Codex 最高和 Claude 非常高、全部高、全部中）和审查长度（Standard code:20、Long code:35、Max code:50）。忽略不属于所选审查员的快速模式选择。以键入形式写入答案并运行 mmr options "<options>"。
3. 使用 Write 工具将 3-5 行意图写入暂存文件：变更应做什么以及为谁做。从请求、此对话、PR 文本、提交或未提交的差异中获取。没有它，审查员无法判断“错误行为”。如果不清楚，使用按钮向所有者提出一个问题。
4. 读取 git status --short。所有未忽略的内容都将被提交到快照中，因此挑出与此变更无关的任何内容（无关文件夹、笔记）并将其作为 --leave-out <path> 传递。如果无法判断，使用按钮提问。
5. 运行 mmr init --intent-file <file> --trailer "<attribution line>" --spec "<options>"，使用与 mmr options 打印的 Init: 行完全相同的选项，仅在所有者指定了 --base <base> 时添加，并根据需要添加 --leave-out <path>。基础默认为远程的默认分支，审查从合并基础开始。调用此技能表示所有者同意 init 执行的操作：
   • 在基础分支或游离 HEAD 上，它首先创建 multimodel-review/<time>，因此 WIP 提交永远不会落在基础上。
   • 未提交的工作成为一个 WIP 快照提交，因此所有审查员读取相同的提交。不推送任何内容。
   • 退出码 5 表示某些文件看起来像秘密、超过 20 MB 或是嵌入式仓库。尚未更改任何内容。使用按钮询问所有者：将其排除（--leave-out）或包含它们（--allow-flagged）。
   • “没有要审查的内容”表示没有提交和未提交的工作。询问所有者要审查哪些提交，然后传递 --base <commit>。
6. 如果 init 创建了分支或快照，则用一行告知所有者。

一轮

1. 运行 mmr next --phase <code|docs|final|evidence>。它构建提示文件并打印其路径、运行设置以及每个 Claude 审查员的一行 Claude Agent，包含其模型、投入度和答案文件。退出码 3 表示已达到上限：转到完成。
2. 启动每个 mmr status 列出的审查员，在一条消息中：
   • 每个 Codex 审查员（terra, astra, sol, luna）：使用 run_in_background 的 Bash：mmr codex --reviewer <name>。助手以 -s read-only、关闭应用、插件和子代理、启用网络搜索、其自己的日志和时间限制运行 Codex。切勿使用 workspace-write 或 --dangerously-bypass-approvals-and-sandbox、配套脚本或救援子代理。
   • 每个 Codex 审查员一个 Monitor：mmr monitor --reviewer <name>，带 timeout_ms: 1800000。它每 60 秒检查一次，并根据 PID 退出决定“已完成”，绝不根据输出文本。
   • 每个 Claude 审查员（opus, fable, sonnet, haiku；旧运行中为 claude）：一个新的 Agent，带有 subagent_type: "multimodel-reviewer"、来自其 Claude Agent 行的 model 和 effort，以及提示“Review round file: ”。该 Agent 具有读取和网络工具，但没有 shell 或编辑工具。如果该类型不可用，则使用具有相同模型和投入度的 Plan，并告知其仅使用 Read、Grep 和网络搜索。
3. 处理 Monitor 事件：
   • FINISHED：无需执行任何操作。
   • FAILED：按照步骤 5 重新运行，并且仅当重新运行也失败时告知所有者一行。
   • QUIET：不是失败，因为高投入度可以静默思考数分钟。不采取任何操作；助手在静默 10 分钟后停止审查员。
   • RE-ARM：重新启动该 Monitor。
4. 当 Claude Agent 返回时，将其最终消息原封不动地写入步骤 1 中的答案文件，然后运行 mmr claude-result --reviewer <name> --seconds <duration_ms / 1000>。
5. 运行 mmr barrier。在通过之前不要编辑任何内容。如果结果为空或缺失，则仅重新运行该审查员，在相同的提交上；该轮次不再计数。对于 Claude 审查员，生成一个新的 Agent 并重复步骤 4。助手拒绝第三次尝试以及在停滞或超时后的任何重试：然后运行 mmr stop --reason "<why>" 并转到完成。例外：在格式规则被删除之前的运行可能在真实答案上显示 malformed。运行 mmr reread --reviewer <who>，它会读取保存的答案，而不进行新的审查员运行。
6. 分类（请参阅修复者规则），并使用 Write 工具将 triage.tsv 写入轮次文件夹。
7. 修复接受的发现，运行受影响的测试，并进行一次 WIP 提交。失败的测试会阻塞该轮次，因此错误的修复无法到达下一个差异。
8. 运行 mmr close --tests "<exact test command>" 或 --tests "none: docs only"。如果没有任何内容被接受，则省略 --tests。遵循其打印的 Next: 行。

triage.tsv 是制表符分隔的，每行一个合并的发现，并且仅当每个审查员都回答“NO BLOCKING ISSUES.”时才能省略：

reviewers	sev	loc	status	summary	note
terra,opus	P1	src/a.py:42	accepted	Retry drops the last item	src/a.py: Keep the last item on retry
terra	P1	src/b.py:9	rejected	Null token crashes	Token is non-null: src/auth.py:30 returns early

• status 是 accepted、rejected 或 open。open 仅用于最后一个允许的轮次，其中修复将不会被审查。
• note 是更改的内容（已接受）、以代码引用的原因（已拒绝）或为何保留（未关闭）。已接受和已拒绝的备注会反馈到下一个提示的修复列表和分类帐中。
• 拒绝阶段外的发现为“Out of phase”。
• 审查员可以以任何格式回答，因此请自己阅读每个答案。发现计数是最佳估计。没有 P0/P1/P2 标签的答案计为一个发现：添加一行说明其提出的内容，如果未提出任何内容，则添加一个 rejected 行。

WIP 提交：消息 WIP multimodel-review round <N>，写入文件并使用 git commit -F 传递，加上会话的归属行。切勿推送。

阶段

1. 代码审查： 第 1-2 轮审查与基础相比的完整差异。从第 3 轮开始，仅审查差异加上修复列表。审查员可以打开任何文件以获取上下文。在差异之外，它们仅报告 P0，除非差异导致失败：然后发现以其真实严重性锚定到差异行。
2. 清理（仅修复者）： 在文档阶段之前运行，以便此处编写的任何文本都获得 P2 审查。
   • 文档：仅更新因此次变更而过时的文档。精简，不要扩展。
   • 测试：仅删除调试或脚手架测试以及已删除代码的测试。保留回归测试。
   • 运行完整的测试套件。如果失败，则修复它；如果无法通过小修复解决，则停止并报告。
   • 提交，然后在运行文件夹中写入 cleanup.md：每次删除及其原因，以及确切的测试命令和结果。next --phase docs 在没有它的情况下拒绝。
3. 文档审查： 一轮完整差异审查，P2 级别，修复，然后一轮差异审查。然后阶段结束；剩余的任何内容都记录为未关闭。
4. 最终审查： 一轮完整差异审查，使用所有审查员，P0/P1 级别。如果发现被接受，则修复它并运行一轮差异审查。如果仍然失败，则将其标记为未关闭；助手停止运行。

收敛

• 当修复者不接受处于该阶段严重性级别的任何发现时，一轮是干净的。以代码引用原因拒绝的发现不会阻塞。
• 一个阶段在其第一个干净的轮次收敛。
• 代码审查收敛后的新证据（设备或模拟器运行）：更新受影响的代码或文本一次，提交，然后运行 mmr next --phase evidence --note "<运行显示的内容以及更改的内容>"，一轮差异审查，P0/P1/P2 级别。仅当 P0/P1 被接受时，代码审查才会重新打开，并且 close 会说明这一点。
• 在阶段上限或硬停止时：停止并报告剩余内容。

修复者规则

• 合并和去重，保留每个提出发现的审查员，以便统计保持准确。根据代码验证每个发现；拒绝无法验证的发现，并附上一行原因。
• 仅根据代码判断发现，无论由谁提出。您也是 Claude 模型，因此将 Claude 审查员的发现置于同一标准。拒绝由 2+ 个审查员提出的发现或任何 P0，需要特定的代码引用；报告将这些列为有争议，供所有者处理。
• 最小修复。不重构，不添加新功能。仅为真正的 P0/P1 错误添加回归测试。
• 少写散文：更倾向于删除或缩窄错误的句子而不是添加。新注释最多一行。在审查期间不添加新的文档部分。
• 如果钩子拒绝路径，则停止并向所有者报告。切勿绕过它，无论是使用 shell 复制还是任何其他方式。
• 保持 shell 命令 dcg-safe：使用 Write 工具写入文件，并且不要将变量、通配符或重定向到变量路径放入命令中。

完成

在收敛和任何停止时运行此步骤。

1. 运行 mmr archive 以归档每个 Codex 聊天，包括重新运行。
2. 运行 mmr report。它打印每个阶段的轮次、审查员表格、未关闭项、有争议的发现、测试命令和压缩命令，并保存 report.md。
3. 向所有者报告，简短且先回答：每个阶段的轮次、未关闭项、确切的验证命令和结果。
4. 为每个审查员显示一个简单的内联可视化：提出的发现、接受的、拒绝的、独有的、P0-P1 与 P2、干净轮次、平均每轮分钟数。用一行说出您的赢家。默认规则是接受最多的独有 P0/P1，如果推翻此规则，您应该说明，因为您也在判断自己的模型。
5. 将 WIP 提交保留在原位，因为证据轮次需要差异范围。使用按钮询问是否现在压缩，并且仅在确认后从报告运行压缩。

更改此技能

此文件夹是公共仓库 github.com/dknchris/multimodel-review。提交每个更改，并且仅在所有者要求时推送。选择器的代码是 assets/picker.js：mmr picker 仅在其最新提交被推送后从 CDN 加载它，并以内联方式发送（较慢），直到那时。每次更改后运行 python3 tests/test_mmr.py。