grill-me-codex

Grill-Me-Codex — 厳しく問いただされ、その後レビューを受ける

2幕構成で、それぞれ異なる役割を担います。

• 第1幕では、最大の失敗要因である「間違ったものを作ること」を解消します。 Claude が意図が固まるまであなたに質問を重ね、曖昧さについて推測することはありません。（この幕では、Matt Pocock の grill-me を MIT ライセンスの下で使用します。詳しくは THIRD-PARTY-NOTICES.md を参照してください。）
• 第2幕では、次に多い失敗要因である「正しそうに見えても破綻する計画」を解消します。 別のモデル（Codex）が、確定した計画を敵対的な視点から批判します。モデルをまたぐことで、エコーチェンバーを避けます。

あなたが参加するのは、質問に答えるときと、収束した計画を承認するときの2回だけです。Codex は全工程を通じて読み取り専用で、ファイルには一切触れません。

---

第1幕 — GRILL（あなた ↔ Claude）

この計画のあらゆる側面について、共通認識に至るまで徹底的に質問してください。設計ツリーの各分岐を順にたどり、決定間の依存関係を1つずつ解消してください。各質問について、推奨する回答も提示してください。

質問は一度に1つずつ行い、次に進む前に私の回答を待ってください。

コードベースを調べれば答えられる質問については、質問する代わりにコードベースを調べてください。

決定ツリーのすべてを解決し、認識が一致したら、この構成で合意した計画を 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幕 — REVIEW（Claude ↔ Codex）

次に、確定した計画を Codex に渡し、敵対的なレビューを依頼します。同じエンジンを使用し、仕組みが最初から最後まで検証済みです（2026-06-04）。

前提条件（一度だけ、手早く確認）

• codex --version が 0.130 以上であること（古い CLI ではデフォルトの gpt-5.5 モデルでエラーになります）。
• Codex が認証済みであること（事前に codex login を実行してください。ChatGPT アカウントでも問題ありません）。認証またはモデルのエラーが発生した場合は、そのままユーザーに伝えてください。黙って再試行してはいけません。
• -m は指定しないでください。設定のデフォルトを使用します。gpt-5.x-codex バリアントを指定すると、ChatGPT アカウントでの認証時に 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 の計画と、必要なリポジトリ内のファイルを読み取ってください（読み取り専用です）。具体的な欠陥を特定してください。セキュリティホール、競合状態、抜けているエッジケース、スキーマの競合、誤った前提、可観測性の不足、より単純な代替案などが対象です。それぞれについて、1行で修正案を示してください。ファイルは一切変更しないでください。返信の最後に、次のどちらかを示す行を正確に1行だけ記載してください。計画が十分に妥当で実装可能な場合は 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 にあります。判定ファイルと thread.started の行があることを確認し、実行成功を検証してください。どちらも見つからない場合は、実行は失敗です（認証またはモデルのエラー）。停止してユーザーに伝えてください。2>/dev/null は、見た目上の MCP／認証に関する標準エラー出力を抑制します。< /dev/null は必須です。 codex exec はプロンプト引数に加えて標準入力も読み取るため、非対話型のドライバー（Claude Code の Bash ツール、CI、TTY ではないパイプラインなど）では、標準入力の EOF を待って永久にブロックします。これは CPU 使用率が約 0％のまま、気づかれにくいハングです。このリダイレクトにより、すぐに EOF が渡されます。

Rounds 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 へのリダイレクトが必要です。Round 1 と同様、非対話型の標準入力によって処理が停止するのを防ぎます。

タイムアウトのガード（両方のラウンド）： 将来の停止が無言でハングするのではなく、確実に失敗するよう、すべての codex exec / codex exec resume を上限10分で実行します。Claude Code の Bash ツールでは、ツール呼び出しに timeout: 600000 を指定してください（デフォルトの2分では実際のレビューには短すぎて、実行中に終了してしまいます）。通常のシェルでは、コマンドの前に timeout 600（Linux / Git Bash）または gtimeout 600（coreutils を使う macOS。標準の macOS には timeout がありません）を付けてください。上限に達した場合は実行失敗として扱い、やみくもに再試行せず、停止してユーザーに伝えてください。

各ラウンド、Codex の応答後

1. /tmp/codex-verdict.txt を読み、完全な批評とともに ## Round <n> — Codex を LOG_FILE に追記します。
2. 最終行を検索して判定を確認します。
   • VERDICT: APPROVED → Resolution に進みます（合意成立）。
   • VERDICT: REVISE → Claude が実際に対応する価値のある内容を判断します（最終判断者は Claude です。Codex は助言しますが、指示はしません）。PLAN_FILE を修正します。変更した内容、却下した内容とその理由を ### Claude's response として LOG_FILE に追記します。ラウンド数を増やします。
3. ラウンド数が MAX_ROUNDS を超えた場合 → Resolution に進みます（意見の対立）。

Resolution（最終ゲートとして承認します）

• APPROVED： 最終版の PLAN_FILE、2つのアクトで改善された点の3項目の要約、ラウンド数を提示します。次のように尋ねます：「Codex との厳しいレビューを N ラウンド乗り越えました。今すぐ実装しますか？Codex が実装する（/codex-build）、Claude が実装する、またはここで終了する、のどれにしますか？」 ユーザーが「はい」と答えた場合のみコードを作成します。どちらのアクトでもコードは作成しません。
• APPROVED にならずに MAX_ROUNDS に到達（意見の対立）： 合意したように装ってはいけません。未解決の論点と、それぞれに対する Claude の反対意見を列挙し、ユーザーに判断を委ねます。誤った「承認」より、意見の相違を明示してください。

ACT 3（任意）— BUILD（Codex ↔ Claude、役割を交代）

ユーザーが Codex を選んだ場合は、SPEC_FILE=PLAN.md と同じ LOG_FILE を指定して codex-build スキルを呼び出します。ログには ## Act 3 — Build が追記されるため、1つの成果物で全過程（厳しい検討 → レビュー → 実装 → 検証）を記録できます。役割を交代し、Codex がフルアクセスでコードを書き、Claude が差分をレビューして検証を実行します。ユーザーが Claude を選んだ場合は、通常どおり直接実装します。

---

厳守事項

• Act 1 は必ず Act 2 に先行します。ユーザーとともに検討を行い、意思決定の分岐を解決するまでは PLAN.md を作成しないでください。
• Codex はすべてのラウンドで読み取り専用です。最初の呼び出しには -s read-only を指定し、再開時には毎回 -c sandbox_mode="read-only" を指定してください（再開時には -s は使えません）。Codex がファイルを書き込むことはありません。
• ループは必ず MAX_ROUNDS で終了します。
• REVISE のたびに Claude が最終判断を行います。有益な批評は取り入れ、妥当でない批評は理由を記録して却下してください。すべてに従うのは避け（モデル横断チェックの意味がなくなります）、無視するのも避けてください（目的が損なわれます）。
• コードを作成するのは、ユーザーが最終承認した後だけです。
• 成果物は LOG_FILE です。議論の全容を記録してください。

やってはいけないこと

• すでに書かれたコードをレビューしないでください。それには /codex:review を使います。
• ChatGPT アカウント認証では -codex モデルのバリアントを指定しないでください。400 エラーになります。
• Codex にファイルを編集させないでください。常に読み取り専用にします。
• Act 1 を省略しないでください。厳しい検討は価値の半分を占めます。