codex-plan-review

Codex CLIを使ったplanファイルレビュー

planファイルの実現可能性、技術的妥当性、抜け漏れやリスクについて、Codex CLIを使って客観的にレビューします。

実行手順

• レビューループ（最大5回）によりコンテキストが大きくなる場合があります。コンテキスト使用量に注意してください。

1. 開発日誌の取得（コンテキストにある場合）

会話のコンテキスト内にesa URLの開発日誌が言及されている場合、以下の手順で取得してください：

1.1 post番号の抽出

esa URLからpost番号を抽出（例：https://yasuhisa.esa.io/posts/1234 → 1234）

1.2 YAMLの直接取得

esa-llm-scoped-guard fetch コマンドでYAMLを直接取得：

esa-llm-scoped-guard fetch -post <post_number> | tee .claude_work/dev_diary.yaml

成功の場合: YAMLが .claude_work/dev_diary.yaml に保存されるので、次のステップへ進む

失敗の場合: エラーメッセージをユーザーに報告し、このステップをスキップ

開発日誌がコンテキストにない場合は、このステップ全体をスキップしてください。

2. planファイルの特定と最新化

2.1 planファイルの取得

.claude_work/plans/配下からplanファイルを取得してください：

ls .claude_work/plans/*.md

git worktree運用のため、単一のplanファイルが存在する前提です。

このファイルパスを以下のように定義します：

<取得したplanファイルのパス>

2.2 planファイルの最新化チェック

重要: Codexはplanファイルに基づいてレビューするため、planファイルが最新でないと意味がない

1. planファイルを読み取る

2. 会話コンテキスト（開発日誌が取得されている場合はその内容も含む）と比較し、以下の観点で確認：

   • 前提条件: ユーザーとの会話や開発日誌で決まった技術選択・制約がplanに含まれているか
   • 仕様変更: 当初の要件から変更された点がplanに反映されているか
   • 新規決定事項: 会話中や開発日誌に記載された実装方針・アプローチがplanに含まれているか
   • 削除された要件: もはや不要になった要件がplanから削除されているか

3. 差分がある場合:

   • 差分内容（追加・修正・削除すべき箇所）を具体的にユーザーに提示
   • 修正可否を確認し、ユーザー承認後にplanファイルを修正（Editツール使用）

4. 差分がない場合: 次のステップへ進む

2.3 ユーザー発言ログとの整合性確認

.claude_work/user_prompts.txt が存在する場合、planファイルのユーザー発言ログセクションに書き漏れがないか確認する：

1. .claude_work/user_prompts.txt を読み取る
2. planファイルの「ユーザー発言」セクション（生ログ・要約）と突き合わせる
3. 以下の観点で確認：
   • ユーザーが明示的に要件・制約として述べた内容がplanに反映されているか
   • ユーザーの意図や方針決定が漏れていないか
4. 書き漏れがある場合: 漏れている内容を具体的にユーザーに提示し、planへの反映要否を確認

3. Codex CLIでのレビュー実行

Bash経由でcopilot --model gpt-5.3-codexを使ってレビューを実行してください。

重要:

• コマンドはリポジトリルートで実行すること（相対パスが前提）
• プロンプトは必ず Editツールで .claude_work/review_prompt.md に書き出してから cat でパイプすること

開発日誌がない場合の例：

1. Editツールで .claude_work/review_prompt.md を作成：

以下のplanファイルを日本語でレビューしてください。

## レビュー対象
- planファイル: <plan-fileタグで定義されたパス>
- ユーザー発言ログ: .claude_work/user_prompts.txt（存在する場合）

## レビュー方針
- **時間をかけてコードベースを徹底的に読むこと**
- planファイルで言及されているファイルや関連ファイルはすべて確認すること
- 網羅的にレビューし、指摘漏れがないようにすること
- 各観点について具体的なコード箇所を参照しながらレビューすること
- **レビュー結果が網羅的で一度に多くなっても構わない**（指摘は詳細かつ具体的に）

## レビューの観点

### 1. 実現可能性・技術的妥当性
- planで述べられている実装方針は技術的に実現可能か
- 使用予定のライブラリ、API、アーキテクチャは適切か
- 既存のコードベース構造と整合性があるか

### 2. 要件との整合性
- planが解決しようとしている課題は明確か
- 提案されている解決策は要件を満たしているか
- 過不足なく要件をカバーしているか

### 3. 抜け漏れ・リスクの指摘
- 考慮されていないエッジケースはないか
- 潜在的なリスク（パフォーマンス、セキュリティ、保守性）はないか
- 依存関係や影響範囲で見落としはないか

### 4. 実装順序・優先度
- 提案されている実装順序は妥当か
- 依存関係を考慮した適切な順序になっているか

### 5. ユーザー意図との整合性
- .claude_work/user_prompts.txt に記録されたユーザーの発言・指示がplanに適切に反映されているか
- ユーザーが明示的に述べた要件や制約が漏れていないか

出力は日本語で、具体的な指摘と改善提案を含めてください。

2. Bashで実行：

cat .claude_work/review_prompt.md | copilot --model gpt-5.3-codex

開発日誌がある場合の例：

1. Editツールで .claude_work/review_prompt.md を作成：

以下のplanファイルを日本語でレビューしてください。

## レビュー対象
- planファイル: <plan-fileタグで定義されたパス>
- 開発日誌: .claude_work/dev_diary.yaml
- ユーザー発言ログ: .claude_work/user_prompts.txt（存在する場合）

## レビュー方針
- **時間をかけてコードベースを徹底的に読むこと**
- planファイルで言及されているファイルや関連ファイルはすべて確認すること
- 網羅的にレビューし、指摘漏れがないようにすること
- 各観点について具体的なコード箇所を参照しながらレビューすること
- **レビュー結果が網羅的で一度に多くなっても構わない**（指摘は詳細かつ具体的に）

## レビューの観点

### 1. 実現可能性・技術的妥当性
- planで述べられている実装方針は技術的に実現可能か
- 使用予定のライブラリ、API、アーキテクチャは適切か
- 既存のコードベース構造と整合性があるか

### 2. 要件との整合性
- planが解決しようとしている課題は明確か
- 提案されている解決策は要件を満たしているか
- 過不足なく要件をカバーしているか

### 3. 抜け漏れ・リスクの指摘
- 考慮されていないエッジケースはないか
- 潜在的なリスク（パフォーマンス、セキュリティ、保守性）はないか
- 依存関係や影響範囲で見落としはないか

### 4. 実装順序・優先度
- 提案されている実装順序は妥当か
- 依存関係を考慮した適切な順序になっているか

### 5. 開発日誌との整合性
- 開発日誌に記載された開発方針・過去の決定事項と矛盾していないか
- 開発日誌で言及されている懸念事項がplanで対処されているか

### 6. ユーザー意図との整合性
- .claude_work/user_prompts.txt に記録されたユーザーの発言・指示がplanに適切に反映されているか
- ユーザーが明示的に述べた要件や制約が漏れていないか

出力は日本語で、具体的な指摘と改善提案を含めてください。

2. Bashで実行：

cat .claude_work/review_prompt.md | copilot --model gpt-5.3-codex

copilot CLIが失敗した場合のフォールバック：

copilot --model gpt-5.3-codex の終了コードが0以外（weekly limitやその他のエラー）の場合、同じプロンプトをCodex CLIで実行してください：

cat .claude_work/review_prompt.md | codex review -

• ファイルの内容ではなく、ファイルパスを渡すことで、Codexが直接ファイルを読み取ります
• プロンプトは必ず Editツールで .claude_work/review_prompt.md にファイルとして書き出すこと
• 毎回新規セッションでレビューすること（resumeは使用禁止）
• Codexは過去のレビュー結果や前回の指摘には一切言及しないこと
• Codexはプロンプトに記載された観点のみでレビューすること（「前回の指摘は直りましたか？」などの余計な質問をしない）

4. レビュー結果の処理

4.1 レビュー結果の確認

Codexの出力（Bashツールの実行結果）から、指摘内容を把握する。

4.2 指摘の分類とタスクリスト化

指摘を以下のように分類し、タスクリストに追加する（Claude CodeではTaskCreate/TaskUpdateツール、他のエージェントでは同等のタスク管理機能を使用）：

分類	対応
計画上の指摘・改善提案	タスクリストに追加
仕様に関する質問	タスクリストの最後に追加（ユーザーに確認）

• すべての指摘はタスクリストに入れること（忘れ防止）
• 同じ指摘が既にタスクリストにある場合は、新規作成せずタスクを更新する（重複防止）
• 仕様に関する質問は、他のタスクを処理した後でユーザーに確認する

4.3 タスクの実行

1. タスクリストの順番に従って対応
2. 仕様に関する質問はタスクの最後でユーザーに確認

4.4 収束確認とループ

再レビューが必要な場合（前回のCodexレビューで指摘が1件以上あった場合、ただし強制停止条件に該当する場合を除く）：

• 最大レビュー回数（5回）に達していない場合のみ「Codexレビューを再実行する」タスクをリストに追加
• 手順3に戻ってCodexレビューを再実行

収束条件（以下を満たした場合のみ収束と判定する）:

• Codexレビューを実行した結果、指摘が0件だった（初回レビュー・再レビューを問わない）

強制停止条件（収束ではなく停止として扱う）:

• 最大レビュー回数（5回）に達した
• 同一の指摘が繰り返された

• 修正しただけでは収束ではない: 指摘に対して修正を行った場合、必ずCodexレビューを再実行し、指摘が0件であることを確認すること。修正完了をもって収束と判定してはならない
• 指摘が0件になるまで基本的にループを続けること（最大5回まで）
• レビュー回数の管理: タスク名に回数を含める（例：「Codexレビューを再実行する（2回目）」）
• 最大レビュー回数に達した場合は、それ以上レビュー再実行タスクを追加せず停止する
• 同一の指摘が繰り返される場合は停止し、「以下の指摘が繰り返されたため停止しました」とユーザーに報告（繰り返された指摘内容を明記）
• 収束確認のためのレビュー再実行もタスクリストに入れること