# Codex Pr Review

> GitHub PR（単一または複数）を codex exec で系統的にレビューし、批判的トリアージを経て 修正まで回すためのオーケストレーション規約。「PR を codex でレビューして」「この PR 一覧を codex-pr-review でやって」「#69 をレビューして修正まで」などで発動。 司令塔（メインセッション: Fable/Opus）が PR ワーカー subagent（opus/sonnet）を起動し、 ワーカーが codex exec を呼ぶ3層構成が標準。レビュー指摘は鵜呑みにせず本 skill の トリアージ基準で判断する。※対話中の自ブランチの軽いレビューは plugin の /codex:review、 working diff の品質レビューは /code-review が担当。本 skill は PR 単位の レビュー〜修正ループ専用。

- Skill: `yosukeiida/codex-pr-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add yosukeiida/codex-pr-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yosukeiida/codex-pr-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: YosukeIida (https://skillmd.com/u/yosukeiida)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yosukeiida/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 レシピ（ワーカーが実行）

```bash
# 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 間の整合・推奨マージ順）をまとめる