review-all

全面审查 - 双重纯净 Agent 代码审查

作用及此设计的原因

两位独立审查者检查同一项更改，然后对审查结果进行协调。价值不在于“进行两次审查”，而在于一致性信号：当两位纯净 Agent 独立指出同一个问题时，可信度很高。如果只有一位指出某个问题，就值得仔细审视。

要让这个信号有用，需要具备四项特性，此流程旨在保护这些特性：

1. 每位审查者使用纯净上下文。 每位审查者都必须从全新上下文开始，不得了解此次编排流程或另一位审查者的情况，否则他们就不再独立。使用纯净上下文启动两位 Agent；如果 Agent API 支持 fork_context 标志，将其设为 false。不要把任一审查者的输出粘贴给另一位审查者。
2. 审查同一目标。 只有双方查看了完全相同的差异时，一致性才有意义。只解析一次目标，并将相同的 base...HEAD 范围交给双方。
3. 两种互补的审查路径。 一位纯净 Agent 运行 Codex 原生的 codex review --base "$base" 命令。另一位纯净 Agent 根据 references/review-guide.md 直接进行审查，该指南基于 Google 的“代码审查中应关注什么”： https://google.github.io/eng-practices/review/reviewer/looking-for.html
4. 真正的并行处理。 在等待任一结果之前，同时启动两位 Agent。不要串行进行审查。

此技能仅用于审查。绝不要传入 --fix / --comment，绝不要应用补丁，也不要告诉用户你即将更改代码。

不是用于完成 PR 的循环流程

此技能应在一批修复完成后运行一次；如果仍有有效的 P0-P2 级问题，最多可在第二批修复后再运行一次。不要在每次单独修复后重新运行 review-all。

流程

第 1 步 — 解析共同目标（一个基准，一个范围）

目标是 base...HEAD（当前分支的 merge-base 差异），这样两位审查者看到的内容恰好都是此分支新增的提交。

current=$(git rev-parse --abbrev-ref HEAD)

# Base precedence: user-provided --base > origin's default branch > main > master
base="$ARG_BASE"   # whatever the user passed, may be empty
if [ -z "$base" ]; then
  base=$(git symbolic-ref --quiet refs/remotes/origin/HEAD 2>/dev/null \
         | sed 's@^refs/remotes/origin/@@')
fi
[ -z "$base" ] && git show-ref --verify --quiet refs/heads/main   && base=main
[ -z "$base" ] && git show-ref --verify --quiet refs/heads/master && base=master

echo "current=$current base=$base"
git diff --shortstat "$base"...HEAD
git diff --name-only "$base"...HEAD

第 2 步 — 预检（尽早失败，不浪费审查资源）

如果存在以下任一情况，请停止并明确告知用户：

• 当前不在 git 仓库中。
• 无法解析基准分支 → 询问用户要与哪个基准进行比较。
• current 就是基准分支 → 没有可供比较的内容；请用户指定一个基准。
• 差异为空（git diff --shortstat "$base"...HEAD 没有输出）→ 没有已提交的更改可供审查。提醒用户，此模式只审查已提交的更改；如果其工作尚未提交，应先提交。
• Codex 尚未准备就绪：codex login status 未报告已登录的账户。告知用户这一情况，并提出仅运行 Google 评审准则审查的选项。

步骤 3 — 并行启动两个全新上下文的 Agent

使用当前环境提供的 Agent/子 Agent 功能。等待之前，先启动两个审查 Agent。如果 API 提供 fork_context，请为每个 Agent 将其设为 false。只向每个 Agent 提供仓库路径、解析后的基准分支和任务。

Agent A：Codex 审查命令 Agent

任务提示词：

你是一个在全新上下文中运行审查命令的 Agent。在 <repo path> 仓库中，针对已提交的分支差异运行 Codex 原生审查命令：

codex review --base <base>

这项任务仅供审查。不要传入 --fix 或 --comment，不要向 GitHub 发布任何内容，也不要修改文件。返回原生命令输出；如果可行，同时返回规范化的 JSON 数组，格式为： {"file":"...","line":<int or null>,"priority":"P0|P1|P2|P3","category":"design|functionality|complexity|tests|naming|comments|consistency|documentation|security|other","title":"<one line>","description":"<evidence and impact>"} 如果命令未发现问题，在原始输出摘要后返回 []。如果命令失败，返回确切的失败信息并停止。

Agent B：Google 评审标准 Agent

阅读此 SKILL.md 旁边的 references/review-guide.md，然后将以下完整标准作为任务内容提供给 Agent：

你是一名在全新上下文中工作的独立代码审查员。在 <repo path> 仓库中，只审查 git diff <base>...HEAD 中已提交的更改。按照以下基于 Google《代码审查应关注的内容》的评审标准进行审查：

<在此粘贴 references/review-guide.md 的完整内容>

限制：这项任务仅供审查。不要传入 --comment 或 --fix，不要向 GitHub 发布任何内容，也不要修改任何文件。以系统上下文作为判断更改的参考，但每项发现都必须以差异为依据（更改行，或本应由更改触及却未触及的内容，例如缺少测试）。跳过 linter、formatter、typechecker 或 compiler 能发现的小问题。

仅以 JSON 数组形式向我返回发现，不要包含其他内容。每项发现的格式： {"file": "...", "line": <int or null>, "priority": "P0|P1|P2|P3", "category": "design|functionality|complexity|tests|naming|comments|consistency|documentation|security|other", "title": "<one line>", "description": "<why it's a problem, with evidence>"} 按照评审标准中的 P0–P3 等级分配 priority。如果没有发现问题，返回 []。如果更改有特别出色之处，可以添加一项 priority 为 P3、category 为 other、标题为“Good: …”的发现。

两个 Agent 都启动后，等待它们返回结果。

步骤 4 — 收集两方结果

• 等待 Google 评审标准 Agent 返回 JSON。
• 等待 Codex 审查命令 Agent 返回原始输出和/或规范化 JSON。从语义上解析 Codex 原生输出，不要依赖严格的正则表达式。原生审查器的输出通常如下：
  • 前置内容块（Codex 版本、工作目录、模型，以及差异和所运行 shell 命令的转储）——全部跳过。
  • 发现内容出现在 codex 标记之后，先是一行摘要，随后是 Full review comments:，然后是一系列条目，格式如下：- [P2] <title> — <path>:<start>-<end>，每个条目下方附有描述段落。每个条目代表一项发现。
  • 发现内容块通常会打印两次（流式输出一次，最终消息中再次输出）。请去重——它们是相同的发现，并非新发现。
  • Codex 已为每项发现标注 [P0]–[P3]；保持这些标签不变——它们与 Google 评审 Agent 使用的是同一套等级，无需重新映射。
  • 无害的 git: warning: confstr() / xcrun_db 行来自只读沙箱；请忽略。

如果其中一方失败（Codex 出错，或 Agent 未返回可用结果），请根据现有结果继续，并在报告中明确说明——清楚标注的部分审查胜过悄然遗漏。

步骤 5 — 合并、去重、排序

将双方的结果统一为相同的发现格式，然后进行协调：

• 去重：依据相同文件、重叠或相邻行，以及相同的根本问题 （按语义匹配，而非字符串匹配——两个 Agent 的表述会有所不同）。
• 标记每条发现的来源：both、google 或 codex。
• 确定每条合并发现的优先级：如果两位审查者都标记了某个问题，但指定的优先级不同，则采用较高（更严重）的优先级，并注明分歧。
• 排序：主要按优先级（P0 → P3）排序。在同一优先级内，优先列出两位 Agent 都认同的发现——独立达成一致是此技能能提供的最强置信信号。
• 明确呈现分歧，而不是掩盖分歧：如果两位 Agent 对某个问题是否属于 bug 意见不一，简要展示双方立场。这种分歧往往是报告中最有价值的部分。

步骤 6 — 提交一份统一报告

先给出结论，然后列出优先级概览表，接着按优先级分组列出发现。为每条发现标注优先级、来源（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
Codex review and Google-rubric review examined the same diff independently; <X>
findings agreed.

### Findings overview
| Priority | Count | Where | Summary |
| -------- | ----- | ----- | ------- |
| P0 | <n> | <file:line or —> | <short or "none"> |
| P1 | <n> | … | … |
| P2 | <n> | … | … |
| P3 | <n> | … | … |

### P0      ← show only tiers that have findings
1. [P0] **<title>** — `file:line` · _both_ · functionality
   <merged description>

### P1
...

### P2
...

### P3
...

根据优先级推导结论（采用与 kelos 审查者相同的逻辑）：

• 如果存在任何 P0 或 P1 发现，总体正确性为“补丁不正确”；否则为“补丁正确”。此处忽略 P2/P3 级的小问题。
• 存在 P0/P1 时，选择 REQUEST CHANGES；只有 P2/P3（或没有发现）时，选择 APPROVE；确实需要作者提供信息才能作出决定时，选择 COMMENT。

保持简洁：不使用表情符号，引用 file:line，明确标出达成一致（both）的发现，因为这是置信度最高的信号；不要把仅由单个模型发现的问题包装成共识。如果两位 Agent 都没有发现问题，就如实说明并结束。最低优先级分组下可以用一句话指出一项值得注意的优点，标为“Good:”，保持客观，不要奉承。

备注与边缘情况

• 仅审查已提交的更改。 codex review --base 和 base...HEAD 都会忽略未提交或未跟踪的文件。如果用户希望审查这些文件，必须先提交（未来可以通过 --working-tree 模式支持这种情况）。
• 大型差异。 Codex 可能需要一些时间；这正是它在独立、干净的 Agent 中运行的原因。不要过早终止它。
• 参数。 接受可选的基准覆盖参数（例如 review-all --base develop 或 review-all develop）。如果未提供，则按步骤 1 自动解析。
• 不要重复审查。 两位审查者必须审查完全相同的范围；绝不能让一位审查工作区，另一位审查分支范围。