codex-review

name	codex-review
description	汎用の独立 Codex 第二レビュアー。marshal-review が発火しない領域（実装前の計画/設計レビュー、Skill 採用候補レビュー、working-tree 差分でない成果物）で発火する。同一タスクで marshal-review が発火する（実装変更がある）場合は、二重 Codex 実行を避けるため取り下げる。候補レビュー時は findings を CCPIT のレビューボックス契約に記録する。

codex-review — 独立 Codex 第二レビュアー（汎用）

0. このスキルの役割

成果物や判断に対し Codex の独立した第二意見を助言として得る。最終権限は持たない。最終ゲートは常に人間。本スキルは Skill 機構経由で発火するため、Codex companion を Bash 直接呼びする場合と違い、活動が発火統計／フィードバックループに乗る。

marshal-review を補完する、軽量な隙間埋めの層である。marshal-review は実装変更（rule/code/bundle）があるたびに git working tree に対する Codex adversarial-review を回す強制ゲート。本スキルはその強制ゲートが届かない領域を担う。

1. 発火条件 — と marshal-review との調停

独立した Codex 第二意見が価値を生み、かつ marshal-review が同一タスクをカバーしていない時に発火する。典型的な文脈:

• (a) 計画/設計レビュー — 実装着手前に plan / design 文書を pressure-test する（コード変更がまだ無いので marshal-review は発火しない）。
• (b) Skill 採用候補レビュー — 候補の提案 SKILL.md 内容（working-tree 差分でないテキスト成果物）をレビューし、結果を CCPIT のレビューボックスに記録する（§3-A）。
• (c) その他、独立レビューに値すると判断した、working-tree 差分でない成果物。

調停（二重実行をするな）: 現タスクで marshal-review が発火する／発火すると既に分かっている（= 実装変更がある: rule / code / 報告書 bundle）場合、取り下げる: 本スキルを回さない。その場合は marshal-review が既に独立 Codex レビューを提供しており、両方回すのは冗長な二重 Codex 実行になる。取り下げ判断は報告書／会話に明示せよ。沈黙スキップ禁止。marshal-review がカバーするか迷う時は、強制ゲートである marshal-review を優先し本スキルを退かせる。

候補レビューが衝突しない理由: 候補は提案段階（まだ skill ファイルを編集していない）なので marshal-review は発火しない。実際の skill 変更は後段の採用時（CCPIT の認証付き apply）で起き、そこで marshal-review が発火しうる — 経路が分離しているため二重実行にならない。

コスト二段（コスト関門）: 候補レビューでは、一次フィルタを通過した候補 — adoption_label: recommend かつ review_verdict: pending — のみ Codex を呼ぶ。レビュー済み・reject ラベルの候補に Codex を使うな。

2. Codex 呼び出し（参考 — 最良の呼び方は実行時に判断）

Codex companion スクリプトのパスはバージョンで変動するため動的に解決する（marshal-review と同イディオム）:

~/.claude/plugins/cache/**/codex-companion.mjs

• 1 件ヒット: それを採用。
• 複数ヒット: semver 最大を採用（例: 1.0.4 と 1.0.5 なら後者）。旧バージョン残置事故を防ぐ。
• 0 件ヒット: Codex プラグイン未配備とみなし、人間レビューへ縮退（§4）。

Bash で直接呼ぶ（disable-model-invocation 回避の既知手）。read-only（--write なし）:

node "<解決した codex-companion.mjs>" task "<レビュープロンプト>"

本スキルは 提供されたテキスト成果物（plan / design 文書、または候補の §1-§3 SKILL.md）をレビューするため task サブコマンドを使う。git working-tree 差分のケースは marshal-review の adversarial-review の役目。成果物テキストをプロンプトに埋め込み、verdict + findings を返すよう Codex に求める。

レビュー観点はドライに具体的に:

• 候補レビュー: 本質的な UX 向上か。類似する既存 skill と統一可能か。
• 計画/設計レビュー: 隠れた仮定は。検討されていない代替案は。要件カバレッジ／副作用は。

3. findings の記録

3-A. 候補レビュー → CCPIT レビューボックス

Codex stdout を verdict（例: approve / needs-attention）と findings に整理し、CCPIT のレビューストアに upsert する。提案 MD は書き換えない。CCPIT が list 時に request_id をキーに本ストアをレビューボックスへマージする。

ストア: ~/.ccpit/proposal-reviews.json

{
  "<request_id>": {
    "verdict": "needs-attention",
    "findings": "<簡潔な reviewer findings、単一ブロック>",
    "reviewerId": "codex",
    "ccRebuttal": "<findings への反論／応答があれば>",
    "reviewedAt": "<ISO 8601、記録の実時刻 — 推定／丸め禁止>"
  }
}

• まずファイルを読む（無い／空なら {} 扱い）→ 当該 request_id キーを 1 件セット → オブジェクト全体を pretty JSON で書き戻す。reader はフェイルセーフ（破損時は「レビュー無し」= MD の pending ボックスに縮退）だが、書く側は妥当な JSON を書け。
• findings と自分の反論（§4）の両方を記録する。採用／却下の最終判断は人間が CCPIT のパスワードゲートで行う。

3-B. 計画/設計レビュー → その場で提示・記録

findings をユーザーに提示し、当該 plan/報告書に記録する。候補レビューボックスは書かない（request_id が無いため）。

4. レビュアー抽象化・縮退・最終権限

• レビュアー抽象化: reviewerId は自由文字列で、レビュアーエンジンを差し替え可能（既定 codex。別のレビュアー AI やローカル LLM でもよい）。Codex を本体にハードコードするな。
• 縮退: Codex 不在／応答不能（§2 の 0 件、CLI 欠落、認証/ネットワーク失敗）の場合、ブロックしない。レビューは pending のまま（人間レビュー）にし、不在を記録 — 事由 + タイムスタンプ + 取った代替行動。本体は特定 AI 体制から独立を保つ。「if applicable」型の沈黙スキップ禁止。
• 最終権限は人間。 本スキルは助言者。自動採用するな、Codex を最終審にするな。誤った reviewer verdict が無検証で通ってはならない。

5. 配布制約

レビュープロンプト・findings・記録物のいずれにも入れない:

• ユーザーの個人的固有名詞（人名・社名・プロジェクトコードネーム・製品名）、
• AI セッション命名や内部開発コードネーム。

技術的内容のみに留めること。