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 范围内。