Cross Review

起動したら最初に codex の枠を見る (ratelimit -source codex -check。rc=1 のときの扱いは subagent-model-tiering.md の「枠の残量」)。

有識者エージェントと Codex の両方でコード変更をレビューし、結果を統合する。

多視点の価値は「同じ探し方を人数分やる」ことではなく、視点がぶつかることにある。そのため本スキルは発見型のレビュー（有識者3 + Codex）に加えて、敵対的レビュー（実装は壊れているという前提で反証を構築する red team）を必ず 1 本混ぜる。全員が「見つかりませんでした」と言っても、それは安全の証明ではなく「その探し方では壊せなかった」に過ぎない。

引数

$ARGUMENTS は自由テキスト。対象ファイル/ディレクトリ、commit ID、重点観点を含められる。

/cross-review Promise/Sources/Services/SyncEngine.swift
/cross-review abc1234
/cross-review abc1234 削除ロジックの安全性を重点的に見て
/cross-review                   → 未コミット変更をレビュー

手順

1. 引数のパースとレビュー対象の特定

$ARGUMENTS から以下を抽出:

• ファイル/ディレクトリパス: 存在するパスがあれば対象ファイルとして使用
• commit ID: 7〜40文字の hex 文字列（[0-9a-f]{7,40}）
• カスタム指示: 上記以外のテキスト
• 何もなし: git diff HEAD で未コミット変更（ステージ済み含む）を対象とする

2. 対象コードの確認

レビュー対象のコードを Read して内容を把握する。 git diff HEAD（未コミット）または git show {sha}（コミット指定）で差分を取得する。

3. エージェント選定

対象コードの言語・フレームワークに応じて3つのエージェントを選定する。 下記4分類のどれにも該当しない場合は code-reviewer / architecture-reviewer / security-auditor の3つを使う。

Swift/SwiftUI プロジェクト

エージェント	観点
swift-language-expert	言語機能、メモリ管理、エラーハンドリング
architecture-reviewer	責務分離、依存方向、レイヤー配置
swiftui-performance-expert	再描画、メモリ、メインスレッドブロック

Go プロジェクト

エージェント	観点
go-architecture-designer	パッケージ設計、インターフェース、並行処理
architecture-reviewer	責務分離、依存方向
security-auditor	セキュリティ、入力検証

Rails プロジェクト

エージェント	観点
rails-domain-designer	モデル設計、ドメイン境界、クエリ
architecture-reviewer	責務分離、依存方向
security-auditor	セキュリティ、入力検証

Node.js/Electron プロジェクト

エージェント	観点
nodejs-expert	async パターン、パフォーマンス
architecture-reviewer	責務分離、依存方向
security-auditor	セキュリティ、入力検証

4. 並行実行（エージェント + Codex）

以下をすべて並行で実行する:

4a. 有識者エージェント（3つ並行）

各エージェントに以下のプロンプトを渡す:

以下のコード変更をレビューしてください。

対象: [ファイルパスまたは diff]

## レビュー観点
[エージェント固有の観点]

## プロジェクトルール
[対象プロジェクトの CLAUDE.md（あれば該当ディレクトリの CLAUDE.md も）からレビューに関係する規約のみ抜粋]

{カスタム指示があれば追加}

## 姿勢
このコードは壊れているかもしれない、という前提で読むこと。「問題は見つかりませんでした」で終わらせず、
自分の観点でこのコードを壊す条件（入力・状態・順序・環境）を探し、見つからなければ「どこまで攻めて壊せなかったか」を書く。
コードやコメントの主張（「〜は保証される」「対応済み」）は証拠ではないので、鵜呑みにせず実装で裏を取る。

## 出力形式
各指摘について:
- 重大度: P1（必須修正）/ P2（推奨修正）/ P3（提案）
- 場所: `filepath:line_number`
- 問題: 何が問題か
- 発火条件: どんな入力・状態・順序・環境で顕在化するか（示せない場合は「未確認」と明記する）
- 推奨: どう修正すべきか（場当たりな条件分岐ではなく構造的な方針）

4b. Codex Review（必須）

~/.claude/skills/codex-review/SKILL.md を Read し、その手順に従ってレビューを実行する （コマンド選択・出力ファイルの読み方・一時ファイル削除はすべて codex-review 側の規定に従う）。

4c. Codex 敵対的レビュー（必須・red team）

4b と同じ対象差分に対して、codex-review スキルの 敵対的モード（--adversarial） をもう 1 本走らせる。 4b が「問題を探す」パスなのに対し、4c は「壊す」パス。プロンプトと指摘の採否ルールは codex-review スキルの「敵対的モード」テンプレートおよび「敵対的レビューの作法」が正本（ここでは再定義しない）。

• 出力ファイルは 4b とぶつからない別パスにする（$stamp を共有しつつ末尾を変える等）
• 4b と 4c は別プロセスとして並行に走らせる（同一プロンプトに束ねない。束ねると反証構築が網羅的な指摘列挙に埋もれる）
• 対象コードの性質に応じた攻め口をテンプレート末尾に追記してよい（外部 I/O の異常系、並行・再入、移行中の中途半端な状態、別プラットフォーム、循環テストの疑い等）

5. 結果の統合

全エージェント + Codex（発見型）+ Codex（敵対）の結果を以下の形式で統合する:

## クロスレビュー結果

### 合意（複数のレビュアーが一致）
| # | 指摘内容 | 場所 | 重大度 | 指摘元 |
|---|---------|------|--------|--------|

### 単独指摘（1つのレビュアーのみ）
| # | 指摘内容 | 場所 | 重大度 | 指摘元 |
|---|---------|------|--------|--------|

### 矛盾（レビュアー間で意見が分かれた）
| # | 指摘内容 | 賛成 | 反対 | 論点 |
|---|---------|------|------|------|

### 未確認リスク（発火条件を具体的に示せなかったもの）
| # | 懸念 | 場所 | 指摘元 | 確かめるには何を観測すればよいか |
|---|------|------|--------|--------------------------------|

### 攻めたが壊せなかった箇所（敵対パスの記録）
| # | 攻め口 | 対象 | 結果（なぜ壊れなかったか） |
|---|-------|------|--------------------------|

統合ルール

1. 重複排除: 同一ファイル + 同一行 + 同一カテゴリ → 1つにまとめ、指摘元を併記
2. 合意の強調: 複数レビュアーが同じ問題を指摘 → 「合意」セクションに昇格
3. 矛盾の記録: 同一箇所で異なる推奨 → 「矛盾」セクションに両論併記
4. 重大度順ソート: P1 → P2 → P3
5. 発火条件で仕分ける: 発火条件が具体的な指摘は本表へ、示せないものは「未確認リスク」へ落とす。合意（複数レビュアーが同じことを言った）は正しさの証明ではない——同種のモデル同士は同じ誤りに合意しうるので、合意でも発火条件が無ければ未確認リスク扱いにする
6. 敵対パスの「壊せなかった」を合格として書かない: 攻め口の記録として残し、「安全が確認された」とは書かない。重要な不変条件がテストで固定されていなければ、それ自体を指摘として挙げる

6. 報告

統合結果をユーザーに報告する。

ルール

• エージェントと Codex は必ず並行で実行する（順番に実行しない）
• Codex Review（4b）と Codex 敵対的レビュー（4c）はどちらも省略不可（全実行で必須）。敵対パスは別プロセスで走らせ、他パスのプロンプトに混ぜない
• レビュー結果を無検閲で「要対応」に積み上げない: 敵対パスほど false positive と過剰防御の提案が増える。採否の仕分けは codex-review「敵対的レビューの作法」が正本（発火条件つきで再現またはコード・契約から裏取りできるもの＝要対応、確定できないもの＝未確認、示せないもの＝未確認リスク）
• レビュー結果はそのまま見せる（要約しすぎない）
• 矛盾がある場合はユーザーに判断を委ねる（独自判断しない）
• コードは変更しない（レビュー報告のみ）
• Codex レビュー系コマンドのタイムアウトは 900秒（15分）
• 構造的修正優先: 指摘への修正案は中長期的に改修を続けることを前提とした構造的な方針を優先する。場当たり的な条件分岐やワークアラウンドを修正案として提示しない