codex-code-review

使用 Codex 进行对抗式代码审查

担任主要代码审查员。通过与 OpenAI Codex CLI（外部审查员）就审查发现进行辩论，产出高置信度的审查结果。不要假设调用此技能的是哪个 Agent 或提供方。

你只能读取。不要使用文件编辑或写入工具。不要修改或创建仓库中的文件。不要提出或应用修复方案。只报告审查发现。

参考文件

到达相关步骤时阅读以下文件：

• references/debate-protocol.md - 辩论循环机制、收敛规则、错误处理、角色互换辩论。第 6 步之前阅读。
• references/prompt-template.md - Codex 调用的提示词模板和输出解析指南。第 4 步之前阅读。

深度模式

根据用户的请求确定深度模式：

快速：Codex 单轮审查，不进行辩论。用户说“快速”“快点”“单轮”等类似表述时使用。

深入：所有严重和警告级别的审查发现都进入对抗式辩论循环。信息级别的审查发现直接通过。用户说“深入”“全面”“逐条辩论”等类似表述时使用。

自动（默认）：根据以下规则决定是否进行辩论：

• 差异少于 200 行且存在严重或警告级别的审查发现：全部进行辩论
• 差异超过 200 行：仅辩论严重级别的审查发现，警告和信息级别的直接通过
• 涉及身份验证、加密、支付、权限或安全敏感路径的文件：无论差异大小，所有严重和警告级别的审查发现都要辩论
• 仅有信息级别的审查发现：跳过辩论
• 审查发现达到 10 条或以上：仅辩论严重程度最高的前 5 条

在报告开头说明选择的模式及原因。

第 1 步：理解请求

阅读用户提供的参数。参数可能包括：

• 要直接审查的文件路径
• 要检查未提交更改的目录
• 用于比较差异的分支名称
• 要审查的提交 SHA
• PR 编号或 GitHub PR URL
• 深度偏好（例如“快速”“深入”“全面”）
• 关注领域（例如“重点检查 SQL 注入”）

按自然方式理解这些参数。如果某个词看起来像文件路径，检查它是否存在。如果看起来像分支，使用 git 检查。如果看起来像目录，进入该目录。如果看起来像 PR 编号或 GitHub PR URL，使用 gh pr view <number> --json number 验证（不要获取差异——Codex 会自行运行 gh pr diff）。如果某个参数无法解析为任何目标（既不是文件、目录、分支、提交 SHA，也不是 PR），请告知用户：“无法解析“”：它不是文件、目录、分支、提交 SHA 或 PR 编号。”

如果未指定目标，则审查当前工作目录中的未提交更改。

第 2 步：检查前置条件

运行 which codex。如果未找到，则停止并报告：“未安装 codex CLI。请使用以下命令安装：npm install -g @openai/codex”

对于非文件审查模式，使用 git rev-parse --git-dir 验证当前位于 git 仓库中。

步骤 3：确定审查目标

根据用户的请求，弄清楚 Codex 需要审查什么。不要自行生成差异内容或读取文件内容——Codex 拥有完整的文件系统访问权限，可以自行完成这些操作。你的任务是清楚地描述目标，让 Codex 知道该查看哪些内容。

• 未提交的更改：使用 git status 快速检查是否确实有更改。如果没有，请报告：“未发现未提交的更改。”传给 Codex 的目标描述为：“<absolute repo path> 中未提交的更改（已暂存和未暂存）”。
• 分支差异：使用 git rev-parse 验证分支是否存在。目标描述为：“<absolute repo path> 中当前分支相对于 <branch> 的更改”。
• 提交：验证 SHA 是否存在。目标描述为：“<absolute repo path> 中由提交 <SHA> 引入的更改”。
• PR：使用 gh pr view 验证 PR 是否存在。目标描述为：“PR #<N> 中的更改——Codex 应运行 gh pr diff <N> 查看差异——已在 <absolute repo path> 中检出”。
• 文件路径：验证文件是否存在。目标描述为：“文件 <absolute paths>”。

将所有路径解析为绝对路径。你将在下一步把此目标描述传给 Codex。

步骤 4：获取 Codex 的初步审查结果

阅读 references/prompt-template.md，了解确切的提示词格式和输出解析指南。提示词通过描述告知 Codex 要审查的内容——绝不要将差异、文件内容或代码粘贴到提示词中。Codex 会自行读取文件并运行 git 命令。

使用审查提示词调用 codex exec。始终传入 --full-auto。使用 heredoc 语法通过 stdin 管道传入：

codex exec --full-auto - <<'CODEX_PROMPT'
<prompt content here>
CODEX_PROMPT

在 shell 命令中始终将用户提供的值括起来。优先使用 heredoc，而不是 echo "$PROMPT"，以避免 shell 解释提示词内容。

在不阻塞工作流的情况下运行 Codex

Codex 运行较慢。彻底审查通常需要 3–10 分钟；对于较大的差异，有时会更久。运行时支持时，请使用后台运行或非阻塞进程功能，并设置 10 分钟的上限。如果运行时只支持前台命令，则在前台运行 Codex，并在相同的时间上限内等待其完成。不要轮询、休眠或反复尝试。

Codex 运行期间，如果运行时允许，请开展其他有用的工作：重新阅读已更改的文件，为步骤 6 中角色互换的讨论拟定独立发现，或准备报告结构。

如果达到 10 分钟上限，请使用运行时提供的机制检查进程的增量输出。如果 Codex 仍在取得进展，则使用相同的提示词重新启动一次有时间限制的运行。只有当 Codex 正常退出且没有任何进展时，才将此次运行视为失败。

跳过 Codex 是失败，不是备用方案

这项技能的全部价值在于 Codex 提供的独立审查。仅由主审查者给出结果会悄然违背这一目的。将“Codex 花了太长时间”视为“继续等待”，而不是放弃外部审查的理由。

只有以下理由可以接受在没有 Codex 的情况下继续：

• codex 未安装（已在步骤 2 处理）
• 退出代码非零，且有明确错误（身份验证、网络或 API 故障）——原样呈现错误
• 正常退出后确实没有任何输出

以下理由均不可接受：

• “已经等了很久”
• “我担心缓存会过期”
• “我觉得用户在等”
• “差异太大，所以我自己审查就行”

如果 Codex 确实因上述标准而失败，请停止并告知用户：Codex failed: <reason>. Retry, or proceed with a primary-reviewer-only review? 等待用户决定。不要悄悄降低审查标准。

**输出验证：**确认输出包含 NO_ISSUES_FOUND 或至少一个 FINDING: 标记（不区分大小写）。如果输出格式与预期不完全一致，请参阅提示词模板说明中的解析指南。

如果 Codex 返回了 NO_ISSUES_FOUND：在 Deep 或 Auto 模式下，不要停止——继续执行步骤 6，进行角色互换的讨论。在 Quick 模式下，报告审查无问题并停止（Quick 模式按定义只进行一轮审查）。

第 5 步：按深度模式分类审查结果

• Quick：跳过辩论。所有审查结果都直接写入报告。
• Deep：辩论所有严重和警告级别的审查结果。信息级别的审查结果直接通过。
• Auto：应用上述启发式规则。记录推理过程。

第 6 步：对抗式辩论循环

阅读 references/debate-protocol.md，了解完整的辩论机制、收敛规则和角色反转辩论协议。

对于每个辩论候选项：

1. 阅读被引用行所在的源文件（上下文范围为 20–30 行）
2. 将 EVIDENCE 引文与源文件进行比对，确认行号正确。如果行号有误，找到正确行号并改用该行号。
3. 遵循辩论协议：用具体代码证据提出质疑，让 Codex 回应，并持续迭代，直到达成共识或进行 5 轮辩论。

Codex 发言轮次： 使用你的质疑调用 codex exec。描述 Codex 应检查的文件和行范围，不要将代码粘贴到提示词中。Codex 可以自行读取源文件。请 Codex 使用 DEFEND、RETRACT 或 REVISE 作答。

当 Codex 返回 NO_ISSUES_FOUND 时，进行角色反转辩论：独立扫描变更，查找 Codex 遗漏的问题。提出 2–3 条你自己的审查结果，并提交给 Codex 进行辩护。

如果当前运行时支持并行任务或子进程，不同审查结果的独立辩论轮次可以并行进行。

第 7 步：报告审查结果

输出结构化报告。不要包含已驳回的审查结果。

## Code Review Results

Mode: <quick | deep | auto (with reasoning)>
Reviewed: <what was reviewed>
Debated: <N findings challenged> | Passed through: <M findings>
Findings: <X confirmed, Y unresolved, Z dismissed>

### Confirmed Issues

#### [SEVERITY] <title>
**File:** `<path>:<line>`
**Evidence:**
\`\`\`
<the relevant code>
\`\`\`
**Problem:** <description>
**Agreed by both reviewers after N rounds**

### Unresolved (Disagreement)

#### [SEVERITY] <title>
**File:** `<path>:<line>`
**Codex's position:** <summary>
**Primary reviewer's position:** <summary>
**Recommendation:** <your best judgment>

### Info

#### <title>
**File:** `<path>:<line>`
**Note:** <description>

省略空章节。如果没有任何审查结果：“两位审查者一致认为：未发现重大问题。”

注意事项

• codex exec 将结果输出到 stdout。无需使用临时文件或 -o 标志。直接调用并读取输出即可。
• 切勿在 Codex 提示词中传递差异、文件内容或代码块。Codex 可以访问文件系统——告诉它去哪里查看，而不是代码内容是什么。
• 审查其他目录中的文件时，在执行 cd 之前，将所有路径解析为绝对路径。
• 始终在 shell 命令中为用户提供的值加引号，以防止注入。

调用示例

/codex-code-review
/codex-code-review /path/to/other/repo
/codex-code-review src/auth.ts src/api/handler.ts
/codex-code-review main
/codex-code-review abc1234
/codex-code-review #42
/codex-code-review quick review
/codex-code-review deep review of branch main
/codex-code-review focus on SQL injection vulnerabilities