| name | adversarial-review |
| description | 对抗评审 skill。主线程把待评审内容（设计文档 / 代码 / 任意方案）原样打成证据包，并行起 Claude(Opus) 子线程与 codex(GPT 5.5) 做两份独立评审，再由 Opus 裁判逐条裁决采纳/驳回，产出最终报告。Claude 轮用 Agent 工具，GPT 轮用 codex。触发词："克劳德评审"、"对抗评审"。 |
对抗评审
一句话：同一份内容，Claude(Opus) 和 GPT(5.5) 各出一份独立评审，再由 Opus 当裁判逐条裁决。
主线程负责打证据包、并行发起两份评审、最后跑裁判轮并写报告。流程只有一条，没有模式分支。
0. 核心哲学
为什么要两份独立评审，而不是一份？
- 视角正交：Claude 和 GPT 是两套不同的模型，关注点、盲区、偏好都不同。同一份方案，两边会挑出不同的问题。合起来覆盖面远大于任何单一评审者。
- 生成与评审是不同语境：即使被评审的方案出自某个模型，换到「评审」语境（哪怕同型号模型）也能发现设计时忽视的盲区——设计时的目标是"让方案自洽完整"，评审时的目标是"找漏洞、找边界、找过度设计"，认知工具不同。
- 裁判收口：两份评审难免有噪声、有互相矛盾。Opus 裁判逐条裁决"哪条成立、哪条驳回"，把两份评审收敛成一份经得起挑战的结论。
不必隐瞒方案出处。 只要明确告诉模型"你现在是评审者"或"你现在是裁判"，Claude 和 GPT 都能公正工作——它们足够聪明，知道评审角色该干什么。是否知道方案是谁设计的，不影响评审质量。所以本 skill 不做任何"身份隐瞒"，只做清晰的角色设定。
1. 角色与模型
| 角色 | 调用方式 | 默认模型 | 降级（用户要"快/省"时） |
|---|
| 评审者 A | Agent 工具 | opus | sonnet |
| 评审者 B | codex exec | gpt-5.5（reasoning xhigh） | gpt-5.5（reasoning medium） |
| 裁判 | Agent 工具 | opus | sonnet |
Claude 侧默认 Opus（评审和裁判都用 Opus）。GPT 侧固定 gpt-5.5 超强思考模式，与 Opus 的高规格默认对齐。
同源亲和风险：裁判与评审者 A 同为 Opus，Claude 占两席、GPT 一席，裁判可能仅因「表述顺眼/同源」而系统性偏向 A 侧批判。为此裁判 prompt 内置抵消指令（§5.1）：对 A 侧批判额外加压审视、如实标注采纳来源分布。
降级：用户说"用 sonnet 快速过一遍 / 省点跑"时，评审者 A 与裁判降 sonnet，评审者 B 加 -c 'model_reasoning_effort="medium"'。codex 是 GPT 的唯一调用路径。
成本提示：默认（Opus + gpt-5.5 xhigh）质量最高、也最贵、最慢（评审轮常 60–180s，复杂方案更久）。设计早期快速迭代可用降级档，定稿前的核心审查用默认档。
2. 总体流程
主线程
│
├─ ① 打证据包（§3）—— 评审对象 + 约束 + 判断标准
│
├─ ② 并行发起两份评审（§4，同一份评审对象）
│ 评审者A：Agent(opus) 批判 ┐ run_in_background
│ 评审者B：codex(gpt) 批判 ┘ 并行、互不等待
│
├─ ③ 两边都完成 → 收齐 C_claude + C_gpt
│ （codex 输出经文件中转：其后台进程退出后，需再起一次 Bash 粘 $SCRATCH 字面值 cat gpt-out.txt 取 C_gpt）
│
├─ ④ 裁判（§5）：Agent(opus) 读 评审对象 + C_claude + C_gpt
│ → 逐条裁决采纳/驳回 → 写报告到指定路径
│
└─ ⑤ 验收（§11）→ 报告用户：报告在 [路径]，采纳 N 条 / 驳回 M 条
唯一需要向用户确认的是输出文件路径（§3 未给到就开口问）。其余无需路由、无需选模式。
3. 证据包
证据包的方法论直接复用 ask-sonnet/references/dispatch.md（或 ask-opus/references/dispatch.md，两份一致）的 RAM 框架：R（谁读）/ A（干什么）/ M（最小充分集），三种交付方式（内嵌 / 引用 / 混合），约束区内嵌原文，输出要求必须声明，附带最小必读清单。复杂场景回去读 dispatch；这里只补对抗评审专属的两条规则。
3.1 对抗评审专属规则
① 评审对象逐字内嵌、不压缩。
dispatch 的通则是"先浓缩、禁贴原始代码"——那是因为代码在普通问答里只是背景。但在对抗评审里，被评审的设计文档 / 代码本身就是评审对象（A 的宾语），压缩了就没法评。所以：
- 评审对象：原样内嵌，不压缩、不改写。设计文档贴全文；代码贴相关文件/方法的真实内容。
- 它周围的约束 / 判断标准 / 背景：仍按 dispatch 的最小化压缩。
- 体量逃生口：评审对象会被发送三次（评审者 A、评审者 B、裁判各一份）。若对象超大、贴全文会撑爆任一侧 prompt 上下文，则不内嵌，改用 §3.1② 的「同一份最小必读清单」把对象钉死（两侧与裁判读同一清单），并在证据包注明「对象过大，以引用方式钉定」。默认仍是内嵌；只有撑爆风险时才走此口。
② 钉对象、不钉视野。
两个评审者必须评的是同一份对象——评审对象要么内嵌（天然一致），要么作为同一份最小必读清单给到两边。但佐证上下文各自自由补读：不要求两份评审"读了完全相同的东西"。Claude 多读一段、发现 GPT 没发现的真问题，正是我们要的独立性，不是 bug。（这与 dispatch 松绑后的"最小必读 + 可自行补读"一致。）
3.2 打包清单
□ 评审对象（必填）
- 原样内嵌（设计文档全文 / 代码真实内容），不压缩
- 注明类型：设计文档 / 代码 / 其他方案
□ 输出文件路径（必填）
- 用户指定 → 直接用
- 用户未指定 → 问用户："评审报告写到哪个文件？"
- 不允许 Claude/GPT 自己决定路径
- **拿到路径后第一步：派生本轮 scratch 目录，并记住下方 echo 出的两个字面值**（见「scratch 隔离」）
□ scratch 隔离（并发安全，必做）
- 多 worktree / 多 agent 并发跑对抗评审时，临时文件若用全局固定名会互相覆盖 ——
A 的子线程会读到 B 的 prompt / 评审结果，导致「评审串台」。
- **派生一次（不是每次重算）**：本轮开始时跑下面这段一次。它把"输出路径哈希"当可追踪前缀、
再用 `mktemp -d` 原子加唯一后缀（run-id），生成本轮专属目录。**记住 echo 出的 `ABS_REPORT` 与 `SCRATCH` 两个字面值**，
后续每个 Bash 调用（写 prompt、读 gpt-out、§11 验收）**直接粘这两个字面值，不要重跑 mktemp**（重跑会建新空目录）：
```bash
REPORT='<用户指定的输出报告路径>' # 路径含单引号等特殊字符时需转义，或改 here-doc 传入
case "$REPORT" in /*) ABS_REPORT="$REPORT" ;; *) ABS_REPORT="$PWD/$REPORT" ;; esac
PHASH=$(printf '%s' "$ABS_REPORT" | shasum -a256 | cut -c1-12) # 仅作可追踪前缀，非隔离保证
SCRATCH=$(mktemp -d "/tmp/adv-review-${PHASH}-XXXXXX") # mktemp 原子保证唯一，这才是隔离保证
echo "ABS_REPORT=$ABS_REPORT"; echo "SCRATCH=$SCRATCH" # ← 记住这两行字面值，后续直接复用
```
- **为何隔离靠 `mktemp` 而非路径哈希**：路径哈希只防"路径不同"的任务，**挡不住两个并发 agent 写到同一报告路径**
（同 worktree 重跑、或固定输出文件名习惯）—— 那种情况哈希相同会串台。`mktemp -d` 的唯一后缀按"运行实例"隔离，
任意并发（含同路径）都落不同目录。代价：**放弃"同路径重跑复用同一 scratch"**——重跑本就该重算，每轮全新目录反而免去残留污染。
- **为何 `mkdir`/哈希都不再"每次重算"**：`mktemp` 是随机的、不可重算，所以隔离目录只能"生成一次 + 字面值携带"，
不能像旧版那样靠确定性公式在每个 Bash 调用里重算（这也顺带消除了 `$PWD` 在调用间漂移导致自串的风险）。
- **为何不用 `realpath -m` 绝对化**：BSD/macOS 的 `realpath` 不认 `-m`（GNU 专有），会报错。纯 shell `case + $PWD`
跨 macOS/Linux 可移植、不依赖文件已存在。（`shasum` 在 macOS 默认可用；纯 Linux 若无 `shasum` 换 `sha256sum`，
二者哈希均在行首，`cut -c1-12` 取值正确。）
- 残留目录 `/tmp/adv-review-*` 不会自动清理，靠系统 `/tmp` 回收；如需即时清理，本轮收尾可 `rm -rf "$SCRATCH"`（非阻塞）。
□ 约束（如有）
- 从 CLAUDE.md 摘出适用条款，内嵌原文（不写"参考 CLAUDE.md"）
- 用户本轮明确说的限制
- 没有就写"无"
□ 判断标准（如有）
- 用户说了"好方案应满足 X" / "重点看 Y" → 记录
- 没有就写"无"
□ 非范围（如有）
- 哪些内容不要评、不要动
- 没有就写"无"
发包前两条快速校验：(1) 有没有与评审无关的内容（聊天记录、历史上下文）→ 删除；(2) 有没有漏掉用户这轮明确说的要求 → 补上。
4. 阶段一·并行双评审
主线程把 §3 的同一份评审对象，配上同一套批判者角色设定，分别发给评审者 A（Agent/Opus）和评审者 B（codex/GPT）。两轮并行（§8），互不等待。
4.1 批判者 prompt 模板（A、B 共用）
你是一个尖锐、不留情面的设计/代码评审者。你现在的角色是评审者——你的唯一任务是从下面这份方案中找出漏洞、盲区、未覆盖的边界情况、隐藏假设和过度设计。
规则：
1. 每个批判点必须具体——指出方案中哪个部分有问题，而不是笼统地说"这里不好"
2. 每个批判点必须说明为什么它是问题——会导致什么后果
3. 每个批判点应给出修正方向——不是完整替代方案，而是"朝哪个方向改"
4. 批判点数量不限，但每个都必须是实质性问题，不要凑数
5. 不要客气，不要先夸再批，直接挑刺
6. 如果方案整体方向有根本性问题，直接说出来
输出格式：
## 批判报告
### 核心问题
[如果方案有根本性方向问题，列在这里；没有则写"无"]
### 具体批判
#### 批判 #1：[一句话标题]
- 位置：[方案中哪一部分]
- 问题：[具体什么问题]
- 后果：[会导致什么后果]
- 修正方向：[朝哪个方向改]
#### 批判 #2：...
---
【约束】[§3 摘出的原文，没有则"无"]
【判断标准】[§3，没有则"无"]
【最小必读】[评审对象已在下方内嵌；如需要可自行阅读仓库其他文件辅助判断]
以下是待评审的对象（类型：设计文档 / 代码）：
[评审对象，原样内嵌]
4.2 收集产出
- 评审者 A 的输出 → 保存为
C_claude
- 评审者 B 的输出 → 保存为
C_gpt
- 各自的成功判定见 §10；任一失败按 §9 降级。
5. 阶段二·Opus 裁判
两份评审都收齐后，主线程把"评审对象 + C_claude + C_gpt"打包给裁判（Agent/Opus），让它逐条裁决并写报告。
5.1 裁判 prompt 模板
你是这次对抗评审的最终裁判。你现在的角色是裁判——不是设计者，也不是评审者。你的任务是裁决两份评审意见，而不是重新设计。
你会收到：
- 原始评审对象 D
- 评审者 A（Claude）的批判报告 C_A
- 评审者 B（GPT）的批判报告 C_B
你要做的：
1. 把两份报告的批判点合并、去重，逐条审查
2. 判断每条批判是否成立，给出明确裁决：✅采纳 / ❌驳回（部分成立则采纳成立部分、说明驳回部分）
3. **对每条初判驳回的意见做自我反驳复核**：先写出"该批判若要成立，需要哪些前提成立"；**只有当这些前提有具体文本证据或高可信上下文支撑时，才翻转为 ✅采纳 / 降级为"部分采纳"**。仅"理论上可能但无证据"→ 维持驳回。无论翻转与否，都留下这层"成立所需前提 + 该前提是否有证据"的复核痕迹（留痕是程序要求，与是否翻转脱钩——别因为要留痕就倾向翻转）。
4. 每条裁决给出清晰理由；驳回必须写清"评审者哪里理解错了 / 逻辑有什么漏洞"，不能只说"我觉得不对"
5. 标注每条意见的来源：Claude / GPT / 两者都提（两者都提 = 高置信信号）
6. 汇总所有采纳项，给出修正后的最终结论
7. 单独汇总驳回项及原因
关键原则：
- 你的角色是裁判，专长是判断"这条批判有没有道理"，不是为评审对象辩护，也不是无脑接受批判
- 批判成立就大方采纳；不成立就明确驳回并说清理由
- 评审者可能批得很尖刻，但尖刻 ≠ 正确
- 两位评审者意见冲突时，明确判定谁对谁错并给理由
- **抵消同源亲和 + 与复核统一证据标准**：你与评审者 A（Claude）同为 Opus，"加压审视 A 侧"具体落为——**对 A 侧批判不接受"无证据采纳"**（仅表述顺眼、无实质论证的，不予采纳）。这与第 3 条自我反驳复核"有证据才翻转"是同一把证据尺：复核普遍要求"有证据才翻转"，加压额外要求"A 侧更不容许无证据"。两条不冲突、无需额外优先级排序；对 GPT 侧用同等证据强度，不偏不向
- 如实标注每条意见来源（§6 已有来源字段），并在报告第 5 节给出"采纳来源分布"，便于事后核对是否偏向某侧
- 你的产出是「对采纳项的整合收口」——整合 ≠ 重新设计：综合采纳项给出内聚结论即可，不要另起炉灶推翻方案
输出：严格按 §6 的报告模板，写入文件 [输出路径]。只写这一个文件，不要创建或修改其他文件。
---
【约束】[§3 原文，没有则"无"]
【判断标准】[§3，没有则"无"]
【阶段质量告警】[主线程填：评审者 A / B 是否产出 < 2 个实质批判点（§9/§10）。某方不足则在此标明，裁判须在报告中点明"某方评审不足"；都达标则写"无"]
=== 原始评审对象 D ===
[评审对象，原样内嵌]
=== 评审者 A（Claude）批判 C_A ===
[C_claude]
=== 评审者 B（GPT）批判 C_B ===
[C_gpt]
6. 最终报告格式
裁判严格按以下模板输出（写入 §3 指定的文件）：
# 评审报告：[主题]
> 评审日期：[日期]
> 评审对象：[设计文档 / 代码]
> 评审模型：[Claude 模型] + [GPT 模型] （如 Opus + GPT 5.5）
---
## 1. 评审对象概述
[3-5 句话总结被评审的内容]
## 2. 意见逐条裁决
### 意见 #1：[标题]
- 来源：Claude / GPT / 两者都提
- 意见：[评审者说了什么，原文或摘要]
- 裁决：✅ 采纳 / ⚠️ 部分采纳 / ❌ 驳回
- 理由：[为什么。驳回必须写清评审者哪里错了]
- 驳回复核：[仅驳回 / 部分采纳填：成立所需前提 + 该前提是否有证据支撑（呼应 §5.1 第 3 条）；纯采纳写"—"]
- 修正：[采纳则给出对原方案的具体修正；驳回则写"无需修正"]
### 意见 #2：...
[重复]
## 3. 修正后的最终结论
[把所有采纳项整合成内聚的、可直接使用的最终结论。是"对采纳项的整合收口"而非"原方案 + 补丁"罗列；整合 ≠ 推翻重设计。]
## 4. 驳回意见汇总
| # | 来源 | 意见 | 驳回原因（须体现"成立所需前提为何不成立"，而非仅凭直觉） |
|---|------|------|----------|
| 1 | GPT | [标题] | [一句话] |
（全部采纳则写"无驳回"。）
## 5. 双方共识与分歧
- **共识（两位评审者都提的点）**：[列出 —— 这些是高置信问题]
- **分歧（互相矛盾的点）**：[列出，并指明裁判最终判了哪边]
- **采纳来源分布**：[Claude 独有采纳 N / GPT 独有采纳 M / 两者都提采纳 K —— 供核对是否偏向某侧]
- （没有则写"无"）
7. 调用命令
7.1 评审者 A / 裁判（Claude）——用 Agent 工具
Agent(
description: "对抗评审·评审者A（批判）", # 裁判轮："对抗评审·裁判"
model: "opus", # 降级时 "sonnet"
run_in_background: true, # 评审轮并行用；裁判轮可前台
prompt: [§4.1 或 §5.1 制好的 prompt]
)
- 评审轮：只读分析、不写文件（prompt 已声明）。
- 裁判轮：让 Agent 直接把报告写入指定路径（prompt 已声明路径与"只写这一个文件"）。
7.2 评审者 B（GPT）——用 codex exec
SCRATCH='<§3.2 记住的本轮 SCRATCH 字面值>'
CODEX_CWD="$(git rev-parse --show-toplevel 2>/dev/null || echo /tmp)"
cat > "$SCRATCH/gpt-prompt.txt" << 'PROMPT_EOF'
[§4.1 制好的 prompt，含内嵌评审对象]
PROMPT_EOF
codex exec \
-m gpt-5.5 \
-c 'approval_policy="never"' \
-s read-only \
-C "$CODEX_CWD" \
--skip-git-repo-check \
--ephemeral \
-o "$SCRATCH/gpt-out.txt" \
"$(cat "$SCRATCH/gpt-prompt.txt")" \
< /dev/null \
> "$SCRATCH/gpt-log.txt" 2>&1
-C(=CODEX_CWD) 与 scratch 是两件正交的事：-C 管 codex 去读哪个项目（按 worktree 区分阅读上下文），$SCRATCH 管临时文件落在哪（按运行实例隔离，防并发覆盖）。-s read-only 保证 codex 写不了被评审工作区；它自身在 $TMPDIR 的运行时临时文件不在 $SCRATCH 内、也不计入越界（见 §11）。
- codex 没有 system/user 分离，角色设定合并进 prompt 首部即可。
- 沙箱与审批：
-s read-only（只读沙箱，可读文件辅助评审但物理上写不了任何东西）+ -c 'approval_policy="never"'（非交互必须，否则可能阻塞等审批）。注意 exec 子命令没有 -a flag（照顶层 help 写会直接报错），approval 只能走 -c 覆盖。禁止用 --dangerously-bypass-approvals-and-sandbox——评审是只读任务，无理由全开权限。
- 工作目录选择（
-C）：
- 评审代码 / 项目内设计文档 →
-C 指向被评审项目的根目录（主仓或对应 worktree）。codex 自动注入的只有 AGENTS.md 本体（其原生约定，不认 CLAUDE.md）；若 AGENTS.md 是指向 CLAUDE.md 的指针（常见于工程项目），模型通常会自行跟进阅读，但这是模型自觉而非机制保证——所以适用红线必须照 §3 内嵌进证据包，项目上下文只是补充视野。进项目的价值：评审者可自由补读周边代码与工程规约，与评审者 A 的视野对称（§3.1② 钉对象、不钉视野）。
- 评审与任何项目无关的独立内容 →
-C /tmp 隔离，避免无关项目上下文混入。
- 判别标准：项目根的 CLAUDE.md/AGENTS.md 是工程规约（红线、架构约束）→ 进项目；是人格/身份设定（个人外脑类项目）→ 隔离到 /tmp。
- 默认
gpt-5.5 reasoning xhigh（config 默认即是）；降级加 -c 'model_reasoning_effort="medium"'（合法档位：none/minimal/low/medium/high/xhigh）。codex 是 GPT 的唯一调用路径，失败按 §9。
- 配合 §8 用
run_in_background 发起。codex 后台进程退出后，再起一次 Bash（粘本轮记住的 $SCRATCH 字面值）cat "$SCRATCH/gpt-out.txt" 读取 C_gpt，日志在 $SCRATCH/gpt-log.txt。注意：codex 的 stdout 已重定向到 log，C_gpt 只能从 gpt-out.txt 文件取，不在退出通知里。
8. 超时与响应
- 上限 30 分钟（1800s）。子线程 / codex exec 一旦完成就立刻进入下一步，不空等。
- 两份评审并行发起：评审者 A 的 Agent 调用与评审者 B 的 codex exec 调用都用
run_in_background: true，互不阻塞；两者完成会各自通知，主线程收到通知即响应。
- Bash 单次 timeout 上限只有 10 分钟，所以 codex exec 必须走
run_in_background（后台进程不受 10 分钟限制）才能容纳 30 分钟的评审。不要用前台 Bash + 长 timeout 跑 GPT 评审。（此处 run_in_background 指 Bash 工具自带的后台参数——它让命令 detached、跨 turn 运行、不受前台 10 分钟约束；不是 shell 的 &，命令块里也无需加 &/nohup。）
- 裁判轮可前台 Agent 调用，完成即返回。
- 30 分钟仍未完成 → 按 §9 当超时处理。
9. 失败降级策略
| 失败场景 | 降级策略 |
|---|
| 评审者 A（Claude）超时（>30min）/ 调用失败 | 重试一次。仍失败 → 用评审者 B 单份评审继续裁决，报告里标注"仅 GPT 评审" |
| 评审者 B（GPT）超时 / 调用失败 | 重试一次。仍失败 → 用评审者 A 单份评审继续裁决，报告里标注"仅 Claude 评审" |
| 两份评审都失败 | 报告用户，终止流程（无可裁决的素材） |
| 某份评审产出 < 2 个实质批判点 | 按 §10（"≥2"的单一真值源）当质量告警、非失败：当作有效输出继续裁判，并把"哪方不足"填进 §5.1 裁判 prompt 的【阶段质量告警】区，要求裁判在报告中点明"某方评审不足" |
| 裁判超时（>30min）/ 失败 | 重试一次。仍失败 → 主线程用已绝对化的输出路径（同 §3.2 的 ABS_REPORT 字面值）把 D + C_claude + C_gpt 拼接写入，标注"裁判未完成，以下为两份原始评审" |
| 裁判产出格式不符模板 | 不重试，直接交付并说明格式有偏差 |
| 用户未指定输出路径 | 不执行，先问用户拿到路径 |
| 任一轮返回空响应 | 检查 prompt 是否有歧义或信息缺口，修正后重试；仍空按对应行处理 |
核心原则：不因一份失败就丢弃已完成的产出。两份评审只剩一份 → 用一份裁决并标注；裁判失败 → 至少交付两份原始评审拼接。
10. 各阶段成功判定
本表是"≥2 批判点"判定的单一真值源；§9 只引用本表、不另行定义。
| 阶段 | 成功 / 质量判定 |
|---|
| 评审者 A / B | 质量目标（非放行闸、非中止条件）：各产出 ≥ 2 个具体批判点（不是笼统的"可以更好"），每个指向评审对象的具体位置。取 2 是因为"单点批判可能是噪声、≥2 才显出评审者真在挑刺"；未达标不算失败，按 §9 当质量告警续跑 |
| 裁判（硬通过标准） | 每条意见都有 ✅采纳 / ⚠️部分采纳 / ❌驳回 标签 + 理由 + 来源；每条驳回 / 部分采纳项留有"成立所需前提 + 是否有证据"的自我反驳复核痕迹；修正后结论包含全部采纳项；报告第 5 节（共识/分歧 + 采纳来源分布）已填 |
11. 主线程验收清单
裁判完成后，主线程执行。$ABS_REPORT 与 $SCRATCH 不跨 Bash 调用持久——验收这次 Bash 调用里必须先把它们带回来：ABS_REPORT 按 §3.2 的 REPORT/case 两行重算（确定性，可重算），SCRATCH 用本轮记住的字面值（mktemp 随机、不可重算）。
□ 先带回变量：REPORT=...; case ... ABS_REPORT；SCRATCH='<本轮记住的字面值>'
□ 输出文件 "$ABS_REPORT" 存在且非空（mtime 在本轮之后）
□ 报告含"意见逐条裁决"+"修正后的最终结论"两节
□ 每条意见都有 ✅/⚠️/❌ 标签 + 来源标注；驳回 / 部分采纳项留有自我反驳复核痕迹
□ 没有评审意见被悄悄忽略（每条都有裁决）
□ 无越界写入【有界声明，只在以下范围内可验证】：
- 报告确实写到 "$ABS_REPORT"；scratch 产物都在 "$SCRATCH/" 内归本轮
- repo 内无意外改动（`git status --porcelain`，报告/ scratch 在 repo 外时此项只覆盖 repo 内）
- 不承诺"repo 外全局无越界"（无文件系统快照不可证）；codex 自身在 `$TMPDIR` 的临时文件不计入越界
□ 向用户报告：评审完成 + 文件路径 + 采纳 N 条 / 驳回 M 条
不通过 → 告知用户具体哪项不达标，由用户决定接受还是重试。
12. 与 ask-sonnet / ask-opus 的关系
- 对抗评审是 ask-sonnet / ask-opus 的上层编排，不是替代品。
- 证据包方法论与这两个 skill 共用
references/dispatch.md 的 RAM 框架；§3 的对抗专属规则是在它之上的补充。
- 评审者 A 和裁判的 Claude 调用，与 ask-sonnet / ask-opus 用的是相同的 Agent 工具机制。
- 日常单方问答 / 派活 →
/ask-sonnet 或 /ask-opus；需要 Claude + GPT 对抗性双评审 → 本 skill。
