Codex pr review

codex-pr-review — PR レビューのオーケストレーション規約

この skill は「安定させたい知識」（codex の呼び出し方・モデル選択・レビュー観点・トリアージ基準）を固定する。 何本並列にするか・どの順で回すかの采配は司令塔がその場で判断する（ここには書かない）。

体制（3層・標準）

司令塔（メインセッション: Fable / Opus）
  └─ PR ワーカー subagent（1 PR = 1 ワーカー、並列可）
       └─ codex exec（レビュアー、read-only）

• 司令塔: ワーカーの起動采配・トリアージの最終判断（却下/移送/修正指示）・横断統合（重複指摘のマージ、PR 間整合、マージ順）・PR コメントへの記録
• PR ワーカー: diff/worktree の準備 → codex exec 実行 → 指摘の実在性をコードを読んで検証 → トリアージ一次判断 → （修正指示があれば）修正 + 再レビュー → 構造化報告
• codex: レビューのみ。修正させない（sandbox でビルド検証できないため。修正はワーカーが行い、ワーカーが swift build 等で検証する）

省略形: PR が 1〜2 本で軽い場合、司令塔が直接 codex exec を叩いてよい（ワーカー層の間接コスト削減）。 docs のみ等の超軽量 PR は codex を省き司令塔が直接レビューしてよい。

ワーカーのモデル選択

PR の性質	ワーカー	備考
並行性・音声/リアルタイム処理・複雑な状態機械	opus	修正判断が難しい領域
定型実装・UI・テスト・docs の PR	sonnet	十分
修正まで任せる場合	可能なら元の実装エージェントに SendMessage で差し戻す	設計文脈を保持しており、指摘の意図を汲んだ修正になる（最重要）

codex exec レシピ（ワーカーが実行）

# 1) 入力の準備 — 2択:
#    (a) diff のみで足りるレビュー（変更が自己完結）:
gh pr diff <N> > /tmp/pr-<N>.diff
#    (b) リポジトリ文脈が要るレビュー（並行性・API 整合・設計判断）— 推奨:
git worktree add ../<repo>-review-<N> <PRのheadブランチ>   # 済んだら worktree remove

# 2) レビュー実行（バックグラウンド可・timeout 900s・失敗時1回リトライ）
cd <worktree> && codex exec -m gpt-5.6-sol -c model_reasoning_effort=medium \
  --sandbox read-only "<レビュープロンプト>"

• モデルは既定 gpt-5.6-sol / effort medium。設計が重い PR は effort high、adversarial な設計挑戦レビューには「実装の前提・設計選択・トレードオフ自体を疑え」という framing を加える
• codex sandbox の既知の制約: swift build 等のビルドは通らない（read-only では当然、workspace-write でも失敗する）。ビルド・テスト検証は必ずワーカー側で行う
• 成否判定は「最終行に総合判定があるか」で機械的に行う。無ければ 1 回リトライ、それでも欠落なら司令塔へ報告（rescue 的な曖昧待ちをしない）

レビュープロンプトの必須要素

1. 文脈: リポジトリ・言語/規約（例: Swift 6 StrictConcurrency complete）・PR の目的・diff の範囲（git diff <base>...HEAD）
2. 観点（PR に合わせて取捨。既定セット）:
   • 正しさ（境界条件・エラーパス・ロールバック/リソース解放）
   • 並行性（actor 境界・レース・continuation リーク・キャンセル安全性）
   • 契約整合（protocol/仕様文書との一致。「準拠」を掲げる実装は原典と突き合わせ）
   • 回帰（既存経路への影響）
   • テストの実効性（テストが実装の契約を本当に検証しているか）
3. 出力形式の強制（返答欠落・曖昧化対策）: [BLOCKER]/[MAJOR]/[MINOR]/[INFO] を重大度順、各項目に file:line + 根拠 + 修正案。指摘なしの観点も明記。最後に総合判定（APPROVE / REQUEST_CHANGES）を1行
4. 再レビュー時は網羅レビューを禁止し、各指摘に RESOLVED / NOT RESOLVED / PARTIALLY + 根拠のみ求める（+ 修正が新規問題を持ち込んだ場合のみ指摘）

トリアージ基準（最重要 — 指摘を鵜呑みにしない）

レビュー指摘への対応は修正の前に必ずこの5項目で判断する。約2割は「修正しない」が正しい判断になる。

1. 実在性: 具体的な失敗シナリオ（入力→誤動作）が再構成できるか。できなければワーカーがコードを読んで反証を試みる。レビュアーも間違える
2. 根本原因か対症か: 指摘箇所ではなく因果の上流を直せるか。上流が別 PR/タスクのスコープなら移送し、タスク管理（backlog 等）に記録
3. スコープ整合: この PR で直すべきか、フォローアップか。「ついで修正」で PR を太らせない
4. 将来整合: 修正が設計正本（spec・architecture docs）と整合するか。仕様の曖昧さが原因なら、コード変更ではなく仕様の明文化 + 回帰テストを選ぶ（例: 「参照実装準拠」の主張と実装の差異 → 派生仕様として文書化 + 差異固定テスト）
5. 戻し先: 修正は元の実装エージェント > 新規ワーカー。修正には必ず該当シナリオの回帰テストを添える

司令塔は却下・移送の判断理由を PR コメントに残す（後から判断を追跡できるように）。

修正ループ

1. ワーカー（または元実装エージェント）が修正 + ビルド/テスト検証 + push
2. codex に focused 再レビュー（上記の RESOLVED 形式）
3. 2周で収束しなければ司令塔がユーザーへエスカレーション（無限ループしない）

報告・記録

• ワーカー → 司令塔: PR 番号 / verdict / 指摘一覧（トリアージ一次判断付き: fix 済み・却下案・移送案）/ テスト結果
• 司令塔 → PR: レビュー結果と判断をコメントで記録（gh pr comment）。マージ可否の最終判定を1行明記
• 複数 PR の場合、司令塔は最後に横断統合（重複指摘・PR 間の整合・推奨マージ順）をまとめる