Codex CLI を使ったコードレビューとテスト検証

レビュー前に現在のブランチ、作業ツリー、目標ベースラインを記録してください。未追跡ファイル、生成ファイル、既存のユーザー変更はレビュー範囲を変える可能性があるため、コミットタイトルだけに頼ってはいけません。

大規模な変更では、まず要件とインターフェース契約を読み、その後モジュールやリスクごとに分けてレビューします。リポジトリ全体を一度にモデルに渡すと、通常は具体性が低下します。

--uncommitted はステージ済み、未ステージ、未追跡の変更をレビューします。--base は現在のブランチと指定ベースラインを比較します。--commit は1つのコミットに集中します。一度に課題と一致する範囲のみを選択してください。

ベースラインブランチ名はリポジトリによって異なります。デフォルトで必ず main とは限りません。まずリモートのデフォルトブランチとタスクのコンテキストを確認してください。

カスタムレビューの指示は、リスク領域と出力基準を明示すべきです。各発見事項にはファイル位置、トリガー条件、実際の影響、修正の方向性を含め、動作への影響のない好みの指摘は省いてください。

セキュリティ、並行性、互換性、エラー処理はコードパスと合わせて判断してください。パターンマッチングだけで高重大度を付けないでください。

不具合対応では、まず最小範囲の再現を実行し、テストが旧動作で失敗することを確認してから修正を実装してください。修正後に追加した、すぐに通るテストだけでは、元の問題をカバーした証明にはなりません。

テストにはユーザーが観察可能な振る舞いを記述させ、プライベートな実装への密結合を避けてください。エラーパス、境界値、並行性、ロールバックは通常 happy path よりも補強する価値があります。

高速で局所的なチェックから始め、モジュールやリポジトリレベルのゲートへと拡張します。git diff --check は空のエラーしか発見できず、テストの代わりにはなりません。ビルド成功も動作が正しいことの証明にはなりません。

実際のコマンドは AGENTS.md、README、または CI から取得してください。以下のプレースホルダーは必ず置換し、そのまま自動化に流用してはいけません。

各発見事項について再現またはコールチェーンの追跡を試み、実際の不具合、成立しない条件、設計上のトレードオフを区別してください。修正後は同じレビュー範囲を再実行し、新たな差分問題が持ち込まれていないことを確認します。

最終報告には実際に実行したチェック、実行しなかったチェックとその理由、残余リスク、人の判断が必要な事項を記載してください。アクセスできない環境のテストを合格と扱わないでください。