# Codex Adversarial Review

> 用外部 CodeX CLI 对文档（spec/设计方案/分析报告/runbook）、代码/PR、或两者一起做对抗式独立评审。当用户说"发给 CodeX review""对抗式评审""找 CodeX 挑刺""第二意见""spec/代码评审""开工前/合入前把关"，或要求"把这个告警/问题分析清楚给一份完整报告"时调用。

- Skill: `igoingdown/codex-adversarial-review` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add igoingdown/codex-adversarial-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/igoingdown/codex-adversarial-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: igoingdown (https://skillmd.com/u/igoingdown)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/igoingdown/codex-adversarial-review

---


# CodeX Adversarial Review —— 对抗式评审（文档 / 代码 / 交叉）

把评审对象交给**外部 CodeX CLI**做独立第二意见。CodeX 用独立模型、独立读码、不预设你的结论对，职责是**证伪而非附和**。适合"方案已定将开工"或"代码写完将合入"的最后一道门。

**四个增强能力**：
1. **三种评审对象**：纯文档 / 纯代码 / 文档+代码（推荐）。
2. **文档↔代码交叉验证**：文档里每条关于代码的断言，回真实代码核对。
3. **Web Search 取证的 SOP**：最佳实践/反模式类建议**必须带权威出处 URL**，与在审代码交叉验证后给出。
4. **可观测性硬门槛**：上线代码必须有观测依据——异常分支带 CamelCase 检索关键词的错误日志 + 核心链路（正常/异常）漏斗打点 + 性能优化必附耗时打点；且观测本身不能拖垮线上——热路径日志量级可控、埋点/上报同步还是异步要说清对延迟的影响；缺失按 MAJOR 起报。详见 `references/review-instructions.md`。
5. **数据库查询与索引硬门槛**：新增/改动 SQL 的谓词列必须有索引覆盖，判据是「谓词有没有索引」而非「现在快不快」（表小时全表扫也只有几毫秒，涨到百万行才爆）。重点核：等值+范围要联合索引且等值列在前、后台清理任务的写操作**无匹配行时也要全表空扫**、写只落主库（主从 CPU 不对称的根源）、长事务持锁引发连接池雪崩、共享库一个慢查询拖垮全库、命中行多且需回表要上覆盖索引、DDL 必须随代码进仓库。缺索引按 MAJOR 起报。详见 `references/review-instructions.md`。

> ⚠️ **铁律：必须用外部 CodeX CLI（`codex exec`），绝不能用本 Agent 自己派生的 Sub-Agent 顶替。** 同模型、共享偏见 = 自己 review 自己，失去独立第二意见的意义。

## 前置条件

- 评审对象已就绪（文档落盘 / 代码写完 / PR 分支存在）
- `codex` CLI 可用（`which codex`，版本 ≥ 0.142.0）+ 已配模型（`~/.codex/config.toml`）——默认模型要是当前最强可用的那个；用户宣布新模型可用时当轮切默认，不逐 session 靠 `-m` 覆盖（见 `references/codex-invocation.md`「模型」）
- 启动加 `--search` 以启用 Web Search（SOP 取证的前提）

## 工作流

```
1. 定评审对象，写指令 codex-review-prompt.md
2. 异步启动 CodeX (codex --search exec, xhigh, bypass-approvals-and-sandbox, run_in_background)
3. 健康监控循环：定期采样进程/日志/子进程，异常即报，产出 codex-review.md
4. 本 Agent 逐条复核 findings + 核验 SOP 出处可达
5. 给净结论：must-fix / 夸大 / 误读 / SOP 站不住 + 上线建议
6. 要发到 PR 上的评论：先跟用户逐条对齐措辞与定级，确认后才发
```

**步骤 1 — 写指令**：把评审指令写成独立文件（留档、可复跑）。必含要素、A/B/C 三种对象取舍、强制输出结构，见 `references/review-instructions.md`；填空式模板见 `review-prompt-template.md`。

**步骤 2 — 启动**：用 `codex --search exec` 异步后台运行，命令与逐项要点见 `references/codex-invocation.md`。关键：顶层 `--search`（取 SOP 出处，必须放在 `exec` 之前）+ `model_reasoning_effort=xhigh`（Thinking=Max）。

**步骤 3 — 健康监控（不是被动等）**：CodeX xhigh 深评常跑 30-60+ 分钟，期间可能死掉、卡死或跑偏（实测发生过：递归再起子 codex、网络重试空转）。必须挂**监控循环**而非只等退出通知，每 60-90s 采样一次：进程活着吗、日志还在增长吗（mtime/size）、有没有意外子 codex。日志停滞 >5 分钟或出现子 codex 即为异常，**立刻把状态报给用户**（进程清单 + 判定依据，kill 仍须用户确认）。监控脚本与判定标准见 `references/codex-invocation.md`。注意：`codex-review.md` 落盘 ≠ 评审结束，CodeX 可能还会改写它，**以进程退出为准**。

两条配套纪律（用户明确要求过，属于本步骤的硬项）：

- **判定已死就地重启，不要等用户来催**：进程已退出却没有产出报告，或日志长时间零增长且无任何产物时，按原 prompt **直接重启这一路评审**——重启是恢复动作，不销毁任何东西，不需要等确认。重启后说明"第几次重启、上一次死在哪一步（tail 到的最后动作）、这次换了什么（如缩短评审对象、去掉全文内嵌）"。需要用户确认的只有 **kill 存疑进程**，尤其可能属于其他会话/其他人的那些（见循环评审第 3 条）。反复同样地死掉说明启动姿势有问题，别机械重启第三次，回去看是不是评审对象过长（第 4 条）。
- **进度主动播报，别等问**：长评审期间按固定节奏（每 10-15 分钟，或每次采样发现状态变化时）主动给一行进度："跑了多久 + 日志增长到多少 + 最近在做什么（tail 日志）"。真实翻车形态是用户在两三小时里连问三次「review 出来了吗」「为什么卡住了」「为什么卡了这么久，是不是死掉了」——问到第三次说明播报缺位，而且这时候往往真的已经死了很久，白等的时间全是损失。

**步骤 4+5 — 二次评估（最关键，别省）**：CodeX 会夸大/误读/定级偏重/给失效出处。逐条回代码复核 + 核验每个 SOP URL，再给用户净结论。判定四档（✅属实 / ⚠️定级过重 / ❌误读 / 🔗出处核验）、反模式清单、完整案例，见 `references/evaluation-and-antipatterns.md`。

**步骤 6 — 对外发言前对齐**：净结论落本地是内部产物，发成 PR 评论就是署用户名的对外发言。顺序固定「先核实 → 再向用户解释每条问题与定级 → 用户裁定（常见是改措辞、降一级）→ 才发评论」。未确认前 findings 只留本地文件，见 `references/evaluation-and-antipatterns.md`。

## 循环评审（review-until-pass）纪律

用户常要求"修完自动再发 CodeX 审，直到通过为止"。多轮循环最容易失控，按以下纪律执行：

1. **逐轮编号留档**：每轮产出 `codex-review-r<N>.md`（指令同理 `codex-review-prompt-r<N>.md`），从 r1 起算；每轮净结论必须写明本轮 verdict + 上一轮 findings 的逐条处置（已修 / 驳回 / 降级），不能只贴新报告。
2. **收敛条件要明确**：verdict 为 yes / yes-with-changes 即收敛停止。连续两轮出现同一批 findings（修了又被提）说明修法有分歧，**停下来找用户对齐**，不要无限打转烧钱。
3. **每轮启动前清点进程——只清账本、kill 必须用户确认**：
   - **启动即记账**：setsid 启动 codex 后立刻把 PID/PGID 写入当轮产物目录（如 `codex-r<N>.pid`）。账本是判定"残留"的唯一依据——发现的进程 ≠ 你启动的进程。
   - **清点只看自己**：用 `pgrep -u "$(id -un)" -f '^codex .*exec'`。禁止 `ps aux` 全局清单：共享机上会列出其他用户的进程，宽模式 `codex.*exec` 还会把 grep 自身、包装 shell 误算成"残留"，而它们可能是其他会话正在跑的正经评审。
   - **kill 是高危动作，必须先向用户列出清单（PID、启动时间、完整命令行、判定依据）并得到明确确认后才执行**——即使进程在自己账本里也一样；杀错一个并行会话的 codex，整轮评审白跑。无人值守场景（cron / headless / 自动循环）**一律不 kill**，只把清单写进产物留给用户处置。
   - 唯一免确认的例外：本轮内自己刚启动、且已确认失败要重试的那个 PID（账本可证）。`kill` 返回 `Operation not permitted` 说明进程不属于你，**严禁转 sudo 重试**。
4. **评审对象过长先减负**：待审文档很长（如超 ~2000 行，或多文件合计远超一次上下文）时，**不要把全文内嵌进 prompt**——prompt 里只放文件路径清单 + 关注点，让 CodeX 靠 `--cd` 自己按需读文件；仍然过长就按章节拆成多轮分片评审。全文内嵌长文档是"反复 API retry / 上下文溢出"的头号诱因，且每轮循环都会重复付出这个成本。
5. **每轮收窄后做全文一致性重扫**：多轮里方案会被逐步砍小（砍掉某个子项、改成"行为等价"的轻量做法）。只改被点到的那一段、不回头扫全文，就会留下互相矛盾的残段——上一轮的守恒式、影响面表格、验收口径还在描述已被砍掉的形态。每轮改完自己先通读一遍在审文档，把因收窄而失效的段落一并改掉，再发下一轮；否则下一轮的 findings 有一半在指这些残段，白烧一轮。
   另外，"行为等价"是一个需要论证的强断言：判定等价时不能只看"当前样本下两者差集为 0"，要答清"差集一旦非零会触发什么"——差集非零可能启动无上界的分支（fan-out / 重试 / 回退），那就不是等价而是新增了一条风险路径。
6. **不许只修被点到的问题——每轮要反思"为什么我没前置抓住"**：评审报出真问题时，除了修掉它，还要回答两件事：这个问题为什么自查没发现（是没读到那段代码、没模拟那个场景、还是自查清单缺这一项），以及**同样的疏漏根因还会在这次改动的哪些地方复现**——把根因应用回整个产物重新扫一遍同类问题，而不是等下一轮评审再逐个点出来。用户的追问形态是「review 能发现的问题你为什么没发现？根因是否有更大漏洞？」——只修 findings 不修产生 findings 的过程，每轮都会以新形态重犯。
7. **用户拍板可以推翻评审结论**：评审是给用户决策的输入，不是最终裁决。用户明确说「别管这条 review 了，有问题我来扛」时，按用户裁定执行——但要把被推翻的 finding 与用户的决策理由一起记录（写进 PR 描述或轮次产物），这样后续追溯时能区分"评审漏了"和"用户知情接受"。同理，把用户的决策原因与方案优缺点一并传达给下一轮评审方，避免评审方反复挑同一个已被拍板接受的点。

## 双路差异化并行评审（着急时的加速姿势）

时间紧、方案重时，用户会明确要求**同时起两个 CodeX、分工不同、各自内部再最大化并发**，而不是串行跑两遍。分工不是把同一份指令发两次（同模型同指令 = 冗余，浪费一路），而是给两路**不同的关注面**：

1. **一路做整体、一路做点状**：整体路评"全链路"——分支是否齐全、旁路是否覆盖、上下游契约、影响面；点状路只盯**这次改动里最危险的那一条路径**（例如全量重刷这条链路、失败退避这段逻辑），深挖到底。两路 prompt 各自写清自己的边界，避免都去评同一块、都不评另一块。
2. **两路可以用不同模型**：用户会指定两路走不同模型（如整体用一个、点状路径用另一个），利用模型差异扩大证伪面。按用户指定分配，别自作主张合成一路。
3. **每路都用后台异步 + 独立产物**：两路各自 `codex-review-<scope>.md` / `codex-review-prompt-<scope>.md`，各自记账 PID（见循环评审第 3 条），监控循环同时盯两路的进程与日志增长。
4. **合并净结论时按路分栏、再去重**：两路可能报同一问题（合并计一次)、也可能各报各的盲区（正是分工的收益）。逐条仍走复核四档，冲突项以回代码复核为准，不因"两路都提了"就直接采信。
5. **加速指令要显式下达给 CodeX**：启动每一路时在 prompt 里明确要求它自己最大化并行、尽快给稳定结论——这是用户反复强调的一条（"让 CodeX 也提升并发")。但并行只加速取证，不降低复核标准：两路都回来后仍要逐条回代码验证。

## 评审前必须把前提落进被审文档

真实翻车（用户自己复盘出来的）：前六轮循环评审全部建立在一个**早已被推翻的前提**上。推翻它的调研结论只存在于会话记忆里，一字没写进 spec，然后就拿着过时前提去评审——第六轮终于判 yes-with-changes、0 BLOCKER，但那个通过是在错误前提下给的，六轮里相当一部分是白跑的。

由此固化两条：

- **评审只能证伪"设计对不对"，证伪不了"这事该不该做"**。CodeX 读到的只有你给的文档与代码；文档里没写的前提，它默认成立并在此之上挑刺。所以"评审通过"不等于"方向正确"，别把 verdict 当立项依据。
- **提审前先核前提是否已落档**：本任务依赖的关键结论——尤其是**中途推翻过既有认知的那些转折**（"原以为 A，实测其实是 B，所以这个方案的出发点变了"）——必须写进被审文档的背景/前提章节，并注明证据来源。只活在会话记忆里的转折等于不存在：会话一压缩、一换轮，下一轮（以及评审方）就会在过时前提上继续推演。提审前用一句话自查：**"如果评审方只看这份文档，他会不会以为某个已被推翻的前提仍然成立？"** 会，就先补文档再提审。

## 「spec 过审再实现」是默认门禁：用户说「直接上」不是免审，设计换了要重审

真实翻车：一份 spec 经七轮循环评审收敛之后，用户提出了一个更简单的替代设计，并拍板「参数取 N，直接改，直接上，这对策略没影响，纯优化，做好测试和验证」。本 Agent 把这句话读成「跳过评审直接写码」——撤掉旧 spec、建 worktree 开始实现；用户当场打回：「你应该先把 spec 写好，发给 CodeX 做一次深度 review，直到 review 通过我们才进入实现。这是最基本的 discipline，你务必遵守。」半截实现全部撤回。固化三条：

1. **门禁默认开着，只有点名评审本身的话才算免审**。「直接上 / 直接改 / 快 / 纯优化 / 对策略没影响」是对方向与优先级的拍板，意思是「别再来回对齐了，进下一步」——而下一步是**写 spec 送审**，不是写代码。能关掉门禁的只有明确指向评审的表述（「这次不用 review」「别管 review 了，有问题我来扛」，见循环评审第 7 条），且那也只是本次的知情豁免，要记进产物。拿不准就问一句「spec 送审通过后再动手，还是这次免审？」，一轮问答远比撤回半截实现便宜。
2. **设计变了，旧 verdict 作废**。用户中途换方案（更简单的形态、不同的数据结构、砍掉或新增一层），哪怕比原方案简单得多，也是一份新 spec：起新版本号、写清与上一版的差异和为什么换、送审、通过后再实现。「上一版过了七轮」对新形态没有任何背书；「比原来简单所以风险更小」正是要评审去证伪的断言，不是跳过评审的理由。
3. **「纯优化、对策略无影响」是待验证的结论，不是前提**。改生成粒度、改缓存复用、改批次切分——这类自称不改语义的改动，评审要核的恰恰是：输出分布会不会变、正在跑的实验读数会不会被污染、失败率会不会随调用次数变多而抬升、回滚路径是什么。把这些写进 spec 的风险节送审；spec 写好了 ≠ spec 过审了，两步之间不能省。

## 本地评审 vs 托管 CI 评审机器人

PR 上常同时存在两条评审通路：本 skill 的**本地 CodeX**，和代码平台上挂的**托管评审机器人**。两者不能互相顶替：

- **本地评审是合入门禁**。托管机器人会因配额、鉴权、超时、仓库配置等原因静默不出结论或只给浅评，实测发生过。用户明确要求过「线上 CI 评审有问题，先在本地跑 codex review」。所以「等 CI 机器人给结论」不算完成本 skill 的第 4 步，本地评审必须自己跑。
- **托管机器人的结论要主动去看，并入净结论**。用户会同时问「本地 codex 验过了吗」和「线上 CI 的 review 反馈了什么问题」。答复里两条通路分别给状态：本地 verdict + findings 处置，托管侧有没有出结论、结论是什么、与本地是否冲突。冲突项按本 skill 的复核四档（属实 / 定级过重 / 误读 / 出处核验）逐条裁定，不因为「机器人说的」就直接采信或直接忽略。
- **读托管 CI 评审要读全正文，并把要点写进持久记忆——这是用户明令的严格纪律**。用户的原话是「每次提完 PR 要关注 CI 的 review 正文，并写进记忆，这是一个非常重要的、严格的纪律」。落法：① 不能只看 CI 的 pass/fail 状态灯就翻篇——通过也常在正文里挂了 nit / 潜在风险 / 后续 follow-up，必须把正文逐条读完；② 把其中值得沉淀的（复现出的真 bug、被反复提的同类问题、机器人特有的误报形态）按项写进记忆，供后续同类 PR 复用，而不是随会话丢失；③ 答复用户时给出「正文读了、要点是什么、哪些已落记忆」，而不是一句「CI 过了」。
- 托管机器人长时间不出结论时，报「未出结论 + 已等多久 + 不阻塞合入」，不要把它当成隐性阻塞在那里干等。

## PR 被平台审批规则卡住时：归因与处置

评审全过之后，PR 仍可能被代码平台的审批规则挡住（提示"需要某团队/某人 approve 才能合入"）。实战里在这一步连猜两次归因都错、被用户拿反例打回，教训固化为四条：

1. **归因只认平台规则实证，逐级查到底**：PR 的 reviewRequests → CODEOWNERS → 分支保护 → **rulesets API**。最容易漏查的是 ruleset 里按 `file_patterns` 配置的路径级 required-reviewer 规则——"其他 PR 都不用、只有这个 PR 要"的差异往往就来自 diff 是否碰到了某个受保护路径。没拿到规则原文前不下结论，"大概是有人手动指定的"不算归因。
2. **用户给出反例（"我之前的 PR 就不需要"）时，反例就是最好的判别证据**：对比两个 PR 各自的 diff 路径与规则的 file_patterns，用差异定位规则，而不是为原结论辩解。
3. **规避动作先推演规则是否同样命中**：删 reviewer、废弃重提新 PR——路径规则跟着 diff 走，只要新 PR 仍改同一路径就照样被卡（实测重提后审批要求原样出现，白提一个重复 PR）；ruleset 强制的 reviewer 用 API 删除会返回成功但实际删不掉。移除/变更类操作后必须读回状态验证，HTTP 200 不等于生效。
4. **提 PR 前预检 diff 路径**：diff 若命中额外审批路径且确属必要（例如埋点必须落在该层才是唯一可靠信号），在 PR 描述里写明为什么必须动这个路径——用户问"我为什么要改这里"时，答案应当已经在描述里，同时也给审批人减负。

## 声明「只改 X」的 PR：纯度是硬门槛

用户常刻意把一件事拆成"先上观测、再做功能"两个 PR：观测 PR 无行为变更、风险低，可以先合先上线，功能开发一边进行一边已有观测兜底。这类 PR 一旦混进功能改动，低风险的前提就没了，而用户在同一天里会反复追问同一件事——「这个 PR 只改了可观测性吧」「除了可观测性你还改了什么？这些改动是做什么功能的」「我看好像不只是可观测的问题，你确认清楚」——问到第三遍说明前两遍答得不实。评审这类 PR 时按以下门禁：

1. **先按 diff 自证纯度，不按意图自证**：逐文件说明每处改动属于"纯观测"还是"行为变更"，判据是**移除它会不会改变线上行为**（新增日志/打点/指标 = 纯观测；改判断条件、改默认值、改调用顺序、动数据结构 = 行为变更，即使动机是"为了能观测"）。给结论时给出这份逐文件清单，而不是一句"只加了日志"。
2. **发现混入就剥离，不要就地解释**：把行为变更拆到独立分支/PR，观测 PR 回到零行为变更。用户的第一诉求是"先把观测剥出来先上"，不是"说清楚为什么混着也没事"。剥离后说明拆成了哪几个 PR、各自的风险与上线顺序。
3. **确有无法剥离的必要改动时，在 PR 标题与描述里显式声明**：例如观测所需字段必须由某层透出。写清为什么不可剥离、影响面、以及它是否改变了任何对外行为——沉默地混在"只改观测"的标题下，等于让审阅人按错误的风险等级放行。
4. **提审给 CodeX 时把"声明的范围"写进 prompt**：让评审方专门核一条"diff 是否超出声明范围"，超出的按 MAJOR 报。这比事后由用户逐个追问便宜得多。

同一门禁适用于任何"我预期只做 X"的改动（只修 bug 不改功能、只加配置不动逻辑、只重命名不改行为）。

## 久放的 PR：先重估价值，再谈解冲突

PR 挂久了（等审批、等排期、被别的事插队）之后，用户的第一问不是"怎么合"，而是**"这个 PR 现在还有价值吗、还有必要上吗"**。这类追问反复出现（「基于最新代码分析一下，看看还有必要上吗」「目前这个 PR 还有什么价值」「有同功能的 PR，你找找」），顺序不能颠倒——先重估，别一上来就埋头解冲突：

1. **先在最新主干上重估必要性**：PR 要解决的每个问题，回最新代码看是否已被别人的改动覆盖。全被覆盖 → 结论是关掉，并说明被哪些改动替代；部分覆盖 → 明确划出仍有增量价值的那部分，其余从 PR 里摘掉。
2. **主动查同功能 PR**：同一问题常有人并行提过。搜开放与近期已合的 PR，按改动的文件和路径找重叠，给出"重复 / 互补 / 冲突"三态判定，别等用户来提示存在另一个 PR。
3. **解冲突后逐项验证关键修复是否还在，不许信 MERGEABLE**：合并的另一侧可能基于旧版开发、不知道本 PR，把评审要求的修复整体改回去（真实形态：一次合并把带类型的哨兵错误改回无类型、重新引入已被判定为误拒的预检、把精确读回退成推算值——三样正好是上一轮评审点掉的）。发现远端已有别人做的解冲突提交时，**不要覆盖重做**，逐项核它是否真保住了每处修复，缺哪项补哪项。
4. **底层类型/契约变了就重跑结论，不许推断**：冲突方改了字段类型、精度、接口签名时，之前在旧形态上得出的结论全部作废，在**真实的新形态**上把每条结论重跑一遍（如小数精度下的边界值是否仍被正确拒绝）。"改的是类型，逻辑没动，所以结论不变"是最容易翻车的推断。
5. **重估结果无论正负都写进 PR 描述**：用户拿这份描述去找人 review。把"为什么现在仍要合 / 哪部分已被替代摘掉 / 冲突怎么解的、解完验证了什么"写进去，别只留在会话里。

## 评审对象是分析报告 / runbook 时：完整版过审 → 简洁版再过审 → 才交付

"把这个告警 / 这个问题分析清楚，给一份完整报告"这类任务，用户反复逐字下达同一套流程：先写完整分析（根因、影响面、方案与约束、成本收益风险，结合代码与线上数据/日志交叉验证）送评审；通过后压成**结论先行的简洁版**落云文档；**简洁版再送一次评审**；通过后才发到用户自己的通道。runbook 也一样：用户要"完整版和简洁版都更新"，自己按简洁版执行，改完的简洁版照样要过一遍评审。同一套步骤被多个 session 逐字重复，说明它还不是默认——以下把它固化为默认链，用户不必再逐条列步骤：

1. **两个版本、两个读者，缺一不可**：完整版是 spec 形态——现象、根因、影响面、方案与约束、成本/收益/风险、证据与交叉验证过程——供评审与留档；简洁版**结论先行**，只留判断、动作项与关键数字（口径紧邻），证据引用指向完整版对应章节，落云文档，是给用户读和执行的**主交付物**。只交完整版等于让用户自己压缩；只交简洁版等于结论没有可审的依据。
2. **两次评审证伪的是两件不同的事**：完整版评审证伪"分析对不对"（根因逻辑、遗漏分支、交叉验证是否真做了、把握度是否如实）；简洁版评审证伪"**压缩有没有失真**"——结论是否与完整版一致、hypothesis 有没有被压成事实、动作项与数字口径有没有丢、读者能否只读它就采取行动。简洁版评审的 prompt 里附完整版路径，明确要求评审方逐条对照，而不是重评一遍分析。
3. **顺序固定，不跳步**：完整版 verdict 收敛（yes / yes-with-changes）之后才写简洁版；简洁版评审通过之后才交付；交付到用户自己的通道，由用户决定是否转发给第三方（见通用纪律 skill 的对外沟通条）。"完整版过了所以简洁版不用审"和"先把简洁版发了再补审"都是跳步。
4. **runbook 的两版并存并同步更新**：完整版留过程、备选方案与排除理由；简洁版只留当前阶段的执行步骤，用户拿它照做。每个里程碑之后两版一起重排（完成项折叠、剩余项置顶——见通用纪律 skill 的活文档条），改动后的简洁版再过一遍评审，重点核"这一步用户按当前通道能不能照做、前置条件有没有写"。
5. **用户开口就是这类任务时默认走这条链**：分析类任务从完整版 → 评审 → 简洁版 → 评审 → 交付五步起手，无需等用户列步骤；用户只想要其中一部分时会明说。每一步的产物按循环评审纪律留档（`codex-review-r<N>.md`、简洁版评审单独编号），最后回复里给出两版链接与两轮 verdict，而不是只发一个文档。

## 输入与输出

**输入**：评审对象（文档路径 / 代码范围 / 两者）+ 关注点（可选）。

**输出**：
- `<工作目录>/codex-review-prompt.md` —— 评审指令（留档）
- `<工作目录>/codex-review.md` —— CodeX 报告（含 Findings + Sources cited 出处清单）
- 本 Agent 对报告的**二次评估** + 上线/合入建议

## 为什么不用原生 `codex review`

CodeX 自带 `codex review` 子命令（`--base` / `--commit` / `--uncommitted` 自动选 diff 范围）。看起来能简化本 skill，但 0.133 实测有两个致命限制，**不适合替代本 skill 的对抗式取证评审**：

1. **`codex review` 不支持联网搜索。** 顶层 `--search` 对 `review` 无效，`-c tools.web_search=true` 也救不回——实测同一 prompt 在 `review` 下返回 `WEB_SEARCH_UNAVAILABLE`，而 `codex --search exec` 能真实搜到权威 URL。本 skill 的铁律「SOP 必带权威出处」依赖搜索，换 `review` 直接失效。
2. **范围 flag 与自定义 PROMPT 互斥。** `--base` / `--commit` / `--uncommitted` **不能和 `[PROMPT]` 同时使用**（报 `cannot be used with '[PROMPT]'`）。即「自动选范围」和「注入对抗式指令」二选一，等于它唯一的优势也用不上。

因此本 skill 固定走 `codex --search exec`（注入完整对抗式 prompt + 联网取证），不使用 `codex review`。`codex review` 仅适合「纯代码 diff、不需 SOP 取证」的轻量场景，不在本 skill 范围内。