Codex CLI の初回タスク：リポジトリ読み取りから変更の検証まで

理想的な初回タスクは、1〜2モジュールのみを対象とし、明確な完了条件を持ち、実行可能なテスト、ビルド、静的チェックが存在するものです。文案修正はコーディングエージェントの能力を検証する良いサンプルではありませんし、リポジトリをまたぐ移行は変数が多すぎます。

欠けている境界テストの追加、安定して再現できるバグの修正、既存関数への入力バリデーションの追加などが選択肢になります。まず目標を振る舞いの変化として記述し、未検証の実装を指定しないでください。

Codex を起動する前に、現在のブランチとワークスペースの状態を確認する。未コミットの変更が必ずしもクリーンアップの必要はないが、どの変更がタスク開始前のものか把握しておき、後の誤判定を防ぐ。

テストコマンドはリポジトリ自身が決定する。以下の例は Git の状態確認と一般的なプロジェクト入口の発見のみを担当し、プロジェクトが特定のパッケージマネージャーを使用するとは仮定しない。

第1ラウンドでは Codex に読み取り専用サンドボックスでコードを特定し、データフローを説明して計画を提案させる。計画は具体的なファイル、リスク、検証方法を示すべきで、失敗原因をまだ説明できない場合は、直接変更に進むべきではない。

作業ディレクトリを -C で明示的に渡すことで、誤ったディレクトリからの起動に起因するコンテキストのズレを減らせる。

実装のプロンプトには問題、スコープ、制約、検証、停止条件を含める。Codex にリポジトリ既存のパターンを使用させ、要件に曖昧さがある場合はまず質問するよう求める。

workspace-write はワークスペースへの書き込みを許可されるが、システム外のパスと制限付きネットワークは引き続きサンドボックスが制御する。承認を一回省くために無サンドボックスモードを直接使用しないこと。

モデルの完了サマリーはリポジトリの証拠の代わりにはならない。実際の diff、未追跡ファイル、無関係なフォーマット変更が現れていないかを確認し、必要に応じて Codex に各挙動変化の説明を求める。

レビュー時は、テストがグリーンになったかどうかだけではなく、境界条件、エラーパス、互換性、シークレットの漏洩に重点を置く。

リポジトリの権威あるテストを自ら実行し、Codex が提示した結果が再現可能か確認する。同じコンテキストで続行する場合は resume を使用し、履歴を保持しつつ別の案を試す場合は fork を使用する。

初回タスク完了の基準は、挙動・テスト・差分がすべて期待通りであることであり、ターミナルに「完了」と表示されることではない。