grill-me-codex

Grill-Me-Codex — 接受拷问，然后接受审查

两个阶段，各司其职：

• 阶段 1 解决头号失败模式：做错东西。 Claude 会不断追问你，直到意图明确——不对模糊之处擅自猜测。（此阶段使用 Matt Pocock 的 grill-me，采用 MIT 许可，详见 THIRD-PARTY-NOTICES.md。）
• 阶段 2 解决第二大失败模式：计划听起来没问题，实际却会出岔子。 由另一个模型（Codex）对已确定的计划进行对抗性审查。跨模型审查 = 避免自说自话。

你只需在两个节点介入：回答拷问问题，以及为收敛后的计划签字确认。Codex 全程只读，绝不会动任何文件。

---

阶段 1 — 拷问（你 ↔ Claude）

对计划的方方面面都要不厌其烦地问我，直到我们达成共识。逐一梳理设计树的各个分支，逐个解决决策之间的依赖关系。对每个问题，请给出你的建议答案。

每次只问一个问题，等我回答后再继续。

如果可以通过检查代码库来回答问题，就去检查代码库，不要问我。

决策树梳理完毕且双方达成一致后，按以下结构将商定的计划写入 PLAN.md，然后进入阶段 2：

# Plan: <task>
_Locked via grill — by Claude + <user>_

## Goal
<one paragraph — reflects what the grilling actually settled>

## Approach
<numbered, concrete steps>

## Key decisions & tradeoffs
<the contestable choices the grill resolved — name them so Codex has something to bite>

## Risks / open questions
<anything still genuinely open>

## Out of scope
<bounds the grill established>

初始化 PLAN-REVIEW-LOG.md：

# Plan Review Log: <task>
Act 1 (grill) complete — plan locked with the user. MAX_ROUNDS=<n>.

---

阶段 2 — 审查（Claude ↔ Codex）

现在将已确定的计划交给 Codex 进行对抗性审查。同一引擎，端到端验证了机制（2026-06-04）。

前提条件（快速验证一次）

• codex --version ≥ 0.130（较旧的 CLI 会在默认的 gpt-5.5 模型上报错）。
• Codex 已通过身份验证（此前运行过 codex login；ChatGPT 账号即可）。如果出现身份验证或模型错误，请报告，不要静默重试。
• 不要指定 -m。 使用配置默认值。在 ChatGPT 账号身份验证下，指定 gpt-5.x-codex 变体会返回 400 错误。
• 在第 1 轮前回显当前模型，以便用户确认：读取 ~/.codex/config.toml 中的 model 行（若不存在，则报告“CLI default”）。将其与已解析的可调参数一同说明，例如 Reviewer model: CLI default (config unpinned) — codex-cli 0.137.0。如果用户有异议，就停止，让他们先调整配置，再开始审查，以免浪费一轮。

可调参数（从参数读取，否则使用默认值）

变量	默认值	含义
MAX_ROUNDS	5	审查轮数上限。循环一定会在此处终止。
PLAN_FILE	PLAN.md	阶段 1 生成的计划。
LOG_FILE	PLAN-REVIEW-LOG.md	仅追加的论证记录。即产出物。

例如，若调用时传入 rounds=3，则将其用于 MAX_ROUNDS。开始前回显已解析的值。

每轮发送的审查提示词

你是实现计划的对抗性审查者。请保持怀疑态度，具体指出问题——你的任务是找出会出什么岔子，而不是一味赞同。阅读 PLAN.md 中的计划，以及所需的任何仓库文件（你处于只读状态）。指出具体缺陷：安全漏洞、竞态条件、遗漏的边界情况、架构冲突、错误假设、可观测性缺口、更简单的替代方案。针对每个问题，给出一行修复建议。不要修改任何文件。回复末尾必须恰好有一行：如果计划足够完善、可以实施，则写 VERDICT: APPROVED；如果仍有实质性问题，则写 VERDICT: REVISE。

第 1 轮 — 新会话（捕获 thread_id）

codex exec -s read-only --json -o /tmp/codex-verdict.txt "$(cat REVIEW_PROMPT)" \
  < /dev/null 2>/dev/null | grep '"type":"thread.started"'

从 {"type":"thread.started","thread_id":"..."} 行中解析 thread_id → 即为 THREAD_ID。审查意见位于 /tmp/codex-verdict.txt。通过 verdict 文件和 thread.started 行确认成功；如果两者都不存在，则本次运行失败（身份验证/模型错误）——停止并告知用户。2>/dev/null 用于隐藏外观上的 MCP/身份验证 stderr 噪声。< /dev/null 是必需的：codex exec 除提示词参数外还会读取 stdin，因此在非交互式驱动程序（Claude Code 的 Bash 工具、CI、任何非 TTY 管道）下，它会一直阻塞等待 stdin EOF——CPU 占用接近 0% 的静默挂起。重定向可立即向其发送 EOF。

轮次 2..MAX — 恢复同一个会话（Codex 会记住之前的评审意见）

# resume REJECTS -s. Force read-only via -c sandbox_mode, or Codex inherits
# config.toml (possibly danger-full-access) and could WRITE files. This is the
# single most important safety line in the skill — verified 2026-06-04.
codex exec resume "$THREAD_ID" -c sandbox_mode="read-only" --json \
  -o /tmp/codex-verdict.txt \
  "I revised the plan. Re-review PLAN.md — check whether your prior findings are addressed and flag anything new. End with VERDICT: APPROVED or VERDICT: REVISE." \
  < /dev/null 2>/dev/null >/dev/null

codex exec 和 codex exec resume 都支持 --json 和 -o/--output-last-message。恢复调用也必须使用 < /dev/null 重定向——与第 1 轮一样，非交互式 stdin 会导致挂起。

超时保护（两轮均适用）： 每次运行 codex exec / codex exec resume 时，都设置 10 分钟上限，确保未来发生任何卡顿时会明确失败，而不是悄无声息地一直挂起。通过 Claude Code 的 Bash 工具调用时，在工具调用中传入 timeout: 600000（默认 2 分钟的工具超时对于实际评审来说太短，会在运行中途将其终止）。在普通 shell 中，为命令加上 timeout 600 前缀（Linux / Git Bash），或 gtimeout 600 前缀（通过 coreutils 在 macOS 上使用——macOS 原生系统没有 timeout）。如果触发超时上限，将其视为运行失败：停止操作并告知用户，不要盲目重试。

每轮 Codex 返回后

1. 读取 /tmp/codex-verdict.txt；将以下内容追加到 LOG_FILE：## Round <n> — Codex + 完整评审意见。
2. 检查最后一行中的结论：
   • VERDICT: APPROVED → 跳转到 Resolution（已达成一致）。
   • VERDICT: REVISE → 由 Claude 决定哪些意见确实值得采纳（Claude 是最终裁决者——Codex 提供建议，而非发号施令）。修订 PLAN_FILE。将 ### Claude's response 追加到 LOG_FILE：记录修改了什么、拒绝了什么以及原因。轮次加 1。
3. 如果轮次 > MAX_ROUNDS → 跳转到 Resolution（陷入僵局）。

Resolution（由你签字确认——最终关卡）

• APPROVED： 呈现最终版 PLAN_FILE、总结两幕改进内容的 3 条要点，以及轮次。询问：“经过 Codex 多轮审查并经受住了 N 轮考验。现在实施吗——由 Codex 实施（/codex-build）、由 Claude 实施，还是到此为止？” 只有用户同意后才能编写代码。两幕期间都不得编写代码。
• 达到 MAX_ROUNDS 但未获 APPROVED（陷入僵局）： 不要假装达成一致。列出每个尚未解决的问题及 Claude 的反方立场；交由用户打破僵局。明确标记分歧，胜过虚假的“已批准”。

ACT 3（可选）— BUILD（Codex ↔ Claude，角色互换）

如果用户选择 Codex：调用 codex-build skill，设置 SPEC_FILE=PLAN.md，并使用同一个 LOG_FILE——它会在日志中追加 ## Act 3 — Build，因此一个产物就能记录整个过程（审查 → 评议 → 构建 → 验证）。角色互换：Codex 在拥有完整权限的情况下编写代码，Claude 评审差异并运行验证。如果用户选择 Claude，则像往常一样直接实施。

---

硬性规则

• Act 1 必须始终先于 Act 2——在与用户一起通过审查实际解决决策树之前，不要编写 PLAN.md。
• Codex 每轮都必须只读——首次调用使用 -s read-only，每次恢复都使用 -c sandbox_mode="read-only"（恢复时没有 -s）。它绝不写入。
• 循环必须始终在 MAX_ROUNDS 处终止。
• 每次遇到 REVISE，Claude 都是最终裁决者——采纳有价值的评审意见，拒绝不合理的意见时必须记录理由。不要全盘接受（这会破坏跨模型检查的意义），也不要置之不理（这会让检查失去意义）。
• 只有在用户最终签字确认后才能编写代码。
• LOG_FILE 是交付物——保留完整讨论记录。

不要做的事

• 不要评审已经写好的代码——那是 /codex:review 的用途。
• 不要在使用 ChatGPT 账号认证时指定 -codex 模型变体——这会返回 400 错误。
• 不要让 Codex 编辑文件。始终保持只读。
• 不要跳过 Act 1——审查环节占了一半价值。