用途：这是一个 PR 之前的多模型代码审查流程，用两条独立审查通道并行检查代码差异，然后对每条合并后的发现做对抗性验证，作为发布前的质量把关。
主要能力：
- 并行双通道审查。Opus 通道通过 Agent(model: 'opus', effort: 'high', run_in_background: true) 启动；Codex 通道直接执行 codex exec，不使用中继代理，由 Root 主循环用后台 Bash 自行运行。
- 共享审查契约。两条通道使用同一份契约：仓库路径（必填，绝对路径）、base（默认 main）、focus（默认 correctness、security、edge cases、API contracts、maintainability）。审查 git diff <base>...HEAD，若为空则改查已暂存与未暂存的变更。要求完整读取变更文件而非只看 diff 片段，只读、不得编辑任何文件。发现需给出 file:line、理由与精确修复方案；若改动干净，给出 verdict "ship" 且零发现，不得虚构问题。
- Codex 通道命令示例：codex exec -m gpt-5.6-terra -c model_reasoning_effort="max" -s read-only --cd <repo> --output-schema <skill-dir>/references/findings-schema.json --output-last-message <scratchpad>/mmr-codex-findings.json - < <scratchpad>/mmr-prompt.md，超时 600000ms。模型路由按 MODELS.md：该通道固化 gpt-5.6-terra 的 max 档；Terra 不可用或差异常规时改用 gpt-5.6-luna 的 max 档，不使用已退役的 Sol worker 档。
- 通道失败语义。某条通道报错或输出不可用时属于覆盖降级，必须在最终报告中明确说明；存活通道的发现成立，但其"无问题"结论不成立，单通道审查不得判定 ship。两条通道都失败则不给结论，报告失败并停止。
- 对抗性验证。用 Agent(model: 'opus', effort: 'high') 启动验证代理，逐条对照实际代码核实：打开引用的 file:line，确认问题在当前 diff 上真实存在（非过期、假设性或既有代码问题），跨通道去重（两通道一致时 confirmedBy 设为 "both"），用具体证据驳回误报，按严重程度排序。结论：存在已确认的 critical/high 则为 "blocker"，仍有已确认发现则为 "changes-recommended"，否则为 "ship"。发现数 ≤3 时 Root 可内联验证。
使用方式：输入 repo（绝对路径，必填）、base、focus；填充 <skill-dir>/references/adversarial-prompt.md（TARGET_LABEL、USER_FOCUS、REVIEW_COLLECTION_GUIDANCE、REVIEW_INPUT），写入 scratchpad 的 mmr-prompt.md；结果先给总体结论，再按严重度列出已确认发现，并列出被驳回发现及理由；若有通道失败需醒目标注覆盖降级。
适用场景：提交 PR 前或发布前的代码审查，需要独立第二意见、对安全性/正确性/边界情况做交叉检查时。
限制：只读，不自动应用修复；仅当用户要求或已有获批的实现任务覆盖时才由主循环改代码。Opus 通道需要 shell 访问来收集 diff，其只读性依赖提示词遵守而非工具范围强制，报告中应如实说明，不得声称是强制只读。Opus 通道不要替换为 subagents/claude 接口角色，因为它们需要命名接口域、证据通道候选与 better-interface 的 schema，通用 diff 审查不具备。具体收费、价格与效果资料暂未提供。