需要高置信度代码审查时，用两个独立干净上下文代理并行审查同一…

在提交 PR 前或批量修复后，对已提交的分支差异做一次双代理交叉复核，通过独立一致性信号提高审查置信度。

适用场景

解决思路

1. 解析共享审查目标：目标为 base...HEAD（当前分支的 merge-base 差异），让两个审查者看到完全相同的提交。base 优先级：用户传入的 --base > origin 默认分支 > main > master。用 git rev-parse --abbrev-ref HEAD 取当前分支，用 git symbolic-ref --quiet refs/remotes/origin/HEAD 解析 origin 默认分支，再用 git show-ref --verify --quiet refs/heads/main 或 refs/heads/master 兜底，最后用 git diff --shortstat 和 git diff --name-only 确认范围。
2. 预检快速失败：不在 git 仓库内、无法解析 base 分支、当前分支就是 base 分支、差异为空（git diff --shortstat 无输出）、或 codex login status 未显示已登录时，停止并明确告知用户；差异为空时提醒本模式只审查已提交变更，未提交需先 commit；Codex 未就绪时报告并提议只跑 Google 评分标准审查。
3. 并行启动两个干净上下文代理：在当前环境支持的 agent/subagent 设施中，等待任一结果前先同时启动两个审查代理；若 API 支持 fork_context 标志则设为 false；每个代理只给仓库路径、解析出的 base 和各自任务；不要把任一审查者的输出粘贴给另一个。
4. 代理 A 运行 Codex 原生审查命令：在仓库中执行 codex review --base <base>；仅审查，不传 --fix 或 --comment，不向 GitHub 发布内容，不修改文件；返回原生命令输出，并尽量返回规范化 JSON 数组，字段为 file、line、priority（P0|P1|P2|P3）、category（design|functionality|complexity|tests|naming|comments|consistency|documentation|security|other）、title、description；无发现返回 []，命令失败返回确切失败信息并停止。
5. 代理 B 按 Google 评分标准独立审查：读取 SKILL.md 旁的 references/review-guide.md，把完整评分标准粘贴进任务提示；只审查 git diff <base>...HEAD 中的已提交变更；仅审查，不传 --comment 或 --fix，不向 GitHub 发布内容，不修改文件；用系统上下文作为判断镜头，但每条发现都要锚定到差异（变更行，或变更本应触及却未触及的内容，如缺失测试）；跳过 linter、formatter、typechecker 或编译器能捕获的吹毛求疵；只返回 JSON 数组，字段为 file、line、priority、category、title、description；无发现返回 []；若变更做得特别好，可加一条 priority 为 P3、category 为 other、标题以 Good: 开头的发现。
6. 收集双方结果：等待 Google 评分标准代理的 JSON；等待 Codex 命令代理的原始输出和/或规范化 JSON；语义化解析 Codex 原生输出，不要依赖僵硬正则；跳过前言块（Codex 版本、workdir、模型、diff 转储及其运行的 shell 命令）；发现出现在 codex 标记后的摘要行、Full review comments: 以及形如 - [P2] <title> — <path>:<start>-<end> 的条目，每条目带描述段落，每条目即一条发现；发现块常被打印两次（流式输出后作为最终消息重复），需去重；Codex 已用 [P0]–[P3] 标记，保留原标签，与 Google 评分标准同一尺度无需重映射；忽略只读沙箱产生的无害 git: warning: confstr() / xcrun_db 行；若一方失败，用已有结果继续并在报告中明确说明。
7. 合并、去重、排序：把双方规范化为同一发现结构后调和；按相同文件 + 重叠/相邻行 + 同一底层问题去重（语义匹配而非字符串匹配）；给每条发现标记来源 both、google 或 codex；合并优先级时若双方都标记但优先级不同，取更高（更严重）者并注明分歧；主要按优先级排序（P0 → P3），同优先级内先列双方一致同意的发现；显式呈现分歧而非隐藏，若双方对某处是否为 bug 有冲突，简要展示双方立场。
8. 输出统一报告：先给结论，再给优先级概览表，然后按优先级分组列出发现；每条发现标注优先级、来源（both/google/codex）和评分维度；报告格式为 ## Review-all: <current> vs <base> (<N> files, +<adds>/-<dels>)，**Verdict:** APPROVE / REQUEST CHANGES / COMMENT，**Overall correctness:** patch is correct / patch is incorrect，说明两个审查独立检查同一差异且 X 条发现一致；### Findings overview 表格列为 Priority、Count、Where、Summary；### P0 起只显示有发现的层级，条目形如 1. [P0] **<title>** — `file:line` · _both_ · functionality 加合并描述。
9. 推导结论：若存在任何 P0 或 P1 发现，Overall correctness 为 patch is incorrect，否则为 patch is correct，P2/P3 不影响此判断；有 P0/P1 时 REQUEST CHANGES，只有 P2/P3 或无发现时 APPROVE，确实需要作者输入才能决定时 COMMENT。
10. 保持报告紧凑：不用 emoji，引用 file:line，清楚标记双方一致的 both 发现（最高置信信号），不要把单模型发现包装成共识；若双方都无发现，说明后停止；显著优点可在最低层级下加一行 Good: 说明，实事求是而非奉承。
11. 接受可选 base 覆盖参数（如 review-all --base develop 或 review-all develop）；未提供时按步骤 1 自动解析；不要重复审查，两个审查者必须拿到完全相同的范围，绝不让一个漂移到工作树而另一个停留在分支范围。
12. 本技能仅审查，不应用修复：绝不传 --fix / --comment，绝不应用补丁，绝不告诉用户即将修改代码；在批量修复后运行一次，若仍有有效 P0-P2 发现，最多在第二次批量修复后再运行一次，不要在每个单独修复后重跑 review-all。

适用边界 · 注意事项

• 不要用它来应用修复，它是只读审查，绝不传 --fix / --comment、不应用补丁、不修改代码。
• 不要在每个单独修复后重跑 review-all；应在批量修复后运行一次，若仍有有效 P0-P2 发现，最多在第二次批量修复后再运行一次。
• 未提交或未跟踪的文件不在审查范围内（codex review --base 和 base...HEAD 都忽略它们）；若要审查这些内容，用户必须先 commit。