ce:review

コードレビュー

選択されたレビュアーのペルソナを動的に用いて、コード変更をレビューします。並列でサブエージェントを起動し、構造化 JSON を返させた後、検出事項を統合して重複を除いた単一のレポートを作成します。

使用するタイミング

• PR を作成する前
• 反復的な実装中にタスクを完了した後
• コード変更に対するフィードバックが必要なとき
• 単独で呼び出す場合
• 大規模なワークフロー内で、読み取り専用または自動修正のレビューステップとして実行する場合

引数の解析

$ARGUMENTS を解析し、以下の任意トークンを確認します。認識したトークンはそれぞれ取り除いてから、残りを PR 番号、GitHub URL、またはブランチ名として解釈します。

トークン	例	効果
mode:autofix	mode:autofix	自動修正モードを選択します（下記の「モードの検出」を参照）
mode:report-only	mode:report-only	レポートのみのモードを選択します
mode:headless	mode:headless	プログラムから呼び出す場合のヘッドレスモードを選択します（下記の「モードの検出」を参照）
base:<sha-or-ref>	base:abc1234 または base:origin/main	スコープ検出をスキップし、これを差分のベースとして直接使用します
plan:<path>	plan:docs/plans/2026-03-25-001-feat-foo-plan.md	要件を確認するため、このプランを読み込みます

すべてのトークンは任意です。トークンが指定されている場合、その分だけ推測する必要がなくなります。指定されていない場合、その段階では既存の動作にフォールバックします。

モードフラグが競合する場合： 引数に複数のモードトークンがある場合は、処理を停止し、エージェントを呼び出さないでください。競合しているトークンに mode:headless が含まれる場合は、ヘッドレスエラーエンベロープを出力します：Review failed (headless mode). Reason: conflicting mode flags — <mode_a> and <mode_b> cannot be combined. それ以外の場合は、汎用形式を出力します：Review failed. Reason: conflicting mode flags — <mode_a> and <mode_b> cannot be combined.

モードの検出

モード	条件	動作
対話型（デフォルト）	モードトークンが指定されていない	レビューを行い、safe_auto の修正を自動で適用し、検出事項を提示します。ポリシー判断が必要なゲート付きまたは手動対応の検出事項については判断を求め、必要に応じて修正、プッシュ、PR 作成の次の手順へ進みます
自動修正	引数に mode:autofix がある	ユーザーとのやり取りは行いません。レビューを行い、ポリシーで許可された safe_auto の修正のみを適用し、回数を制限して再レビューし、実行アーティファクトを書き込み、必要に応じて後続作業を出力します
レポートのみ	引数に mode:report-only がある	厳密な読み取り専用です。レビュー結果を報告した後、編集、アーティファクト、TODO、コミット、プッシュ、PR 操作を一切行わずに終了します
ヘッドレス	引数に mode:headless がある	スキル間呼び出し用のプログラムモードです。safe_auto の修正を無言で（1 回のパスで）適用し、それ以外のすべての検出事項を構造化テキスト出力として返し、実行アーティファクトを書き込み、TODO の作成をスキップし、「Review complete」シグナルを返します。対話型のプロンプトは表示しません

自動修正モードのルール

• ユーザーへの質問はすべて省略します。 スコープの確定後は、承認や確認のために処理を中断しないでください。
• safe_auto -> review-fixer の検出事項のみを適用します。 gated_auto、manual、human、release の作業は未解決のまま残します。
• 実行アーティファクトを .context/compound-engineering/ce-review/<run-id>/ に書き込み、検出事項、適用した修正、未解決の対応可能な作業、および参考出力をまとめます。
• 最終担当者が downstream-resolver である、未解決の対応可能な検出事項に限って永続的な TODO ファイルを作成します。正式なディレクトリパスと命名規則については、todo-create スキルを読み込んでください。
• 自動修正モードでは、コミット、プッシュ、PR 作成を決して行わないでください。これらの判断は親ワークフローが担当します。

レポート専用モードのルール

• ユーザーからの質問はすべてスキップします。 差分のメタデータが乏しい場合は、意図を慎重に推測します。
• ファイルを編集したり、作業を外部化したりしてはいけません。 .context/compound-engineering/ce-review/<run-id>/ に書き込んだり、TODO ファイルを作成したり、コミット、プッシュ、PR の作成を行ったりしてはいけません。
• 並行する読み取り専用の検証に安全です。 同じチェックアウトでのブラウザーテストと並行して安全に実行できるのは、mode:report-only だけです。
• 共有チェックアウトを切り替えてはいけません。 呼び出し元が明示的な PR またはブランチの対象を指定した場合、mode:report-only は分離されたチェックアウト／ワークツリーで実行するか、gh pr checkout／git checkout を実行する代わりに停止しなければなりません。
• 同じチェックアウトで、変更を伴うレビューとブラウザーテストを重複して実行してはいけません。 将来のオーケストレーターが修正を行う場合は、ブラウザーテストの後に変更を伴うレビューを実行するか、分離されたチェックアウト／ワークツリーで実行します。

ヘッドレスモードのルール

• ユーザーからの質問はすべてスキップします。 プラットフォームの質問ツール（Claude Code の AskUserQuestion、Codex の request_user_input、Gemini の ask_user）や、その他の対話型プロンプトは決して使用しないでください。差分のメタデータが乏しい場合は、意図を慎重に推測します。
• 特定可能な差分の範囲が必須です。 ユーザーとのやり取りなしにブランチ、PR、または base: の参照先を特定できず、ヘッドレスモードで差分の範囲を判定できない場合は、Review failed (headless mode). Reason: no diff scope detected. Re-invoke with a branch name, PR number, or base:<ref>. を出力し、エージェントをディスパッチせずに停止します。
• 単一パスで safe_auto -> review-fixer の指摘のみを適用します。 回数を制限した再レビューは行いません。gated_auto、manual、human、release の作業は未解決のままにし、構造化出力で返します。
• 自動修正対象外の指摘はすべて、構造化されたテキスト出力で返します。 ヘッドレス出力エンベロープ形式（以下のステージ 6 を参照）を使用し、各指摘の severity、autofix_class、owner、requires_verification、confidence、pre_existing、suggested_fix を保持します。エージェントごとのアーティファクトファイルから、詳細ティアのフィールド（why_it_matters、evidence[]）を追加します（ステージ 6 の「詳細の補完」を参照）。
• 実行アーティファクトを書き込みます。 指摘、適用した修正、助言の出力をまとめたものを .context/compound-engineering/ce-review/<run-id>/ の下に書き込みます。アーティファクトのパスを構造化出力に含めます。
• TODO ファイルは作成しないでください。 呼び出し元が構造化された指摘を受け取り、後続の作業を自身で振り分けます。
• 共有チェックアウトを切り替えてはいけません。 呼び出し元が明示的な PR またはブランチの対象を指定した場合、mode:headless は分離されたチェックアウト／ワークツリーで実行するか、gh pr checkout／git checkout を実行する代わりに停止しなければなりません。停止するときは、Review failed (headless mode). Reason: cannot switch shared checkout. Re-invoke with base:<ref> to review the current checkout, or run from an isolated worktree. を出力します。
• 共有チェックアウトでの並行実行には安全ではありません。 mode:report-only とは異なり、ヘッドレスモードはファイルを変更し（safe_auto の修正を適用します）、同じチェックアウトで変更を伴う他の操作と並行して実行してはいけません。
• ヘッドレスモードからコミット、プッシュ、PR の作成を行ってはいけません。 これらの判断は呼び出し元が行います。
• 終了シグナルとして、最後に「Review complete」を出力します。 これにより、呼び出し元は完了を検出できます。すべてのレビュアーが失敗またはタイムアウトした場合は、Code review degraded (headless mode). Reason: 0 of N reviewers returned results. を出力してから、「Review complete」を出力します。

重大度の尺度

すべてのレビュアーは P0〜P3 を使用します。

レベル	意味	対応
P0	致命的な障害、悪用可能な脆弱性、データの損失／破損	マージ前に必ず修正
P1	通常の使用で発生する可能性が高い、影響の大きな不具合や契約違反	修正するべき
P2	重大な悪影響を伴う中程度の問題（エッジケース、パフォーマンスの低下、保守性を損なう落とし穴）	簡単に修正できる場合は修正
P3	影響が小さく、範囲が限定された軽微な改善	ユーザーの判断に委ねる

アクションの振り分け

重大度は緊急度を示します。振り分けは、次に誰が対応するか、およびこのスキルがチェックアウトを変更してよいかを示します。

autofix_class	デフォルトの担当者	意味
safe_auto	review-fixer	ローカルで決定的な修正です。現在のモードで変更が許可されている場合、スキル内の修正機能に適しています
gated_auto	downstream-resolver または human	具体的な修正方法はありますが、動作、契約、権限、またはその他の機微な境界を変更するため、デフォルトでは自動適用すべきではありません
manual	downstream-resolver または human	対応が必要な作業です。スキル内で修正するのではなく、引き継ぐべきです
advisory	human または release	学び、展開に関するメモ、残存リスクなどの報告のみの出力です

振り分けルール：

• 最終的な振り分けは統合処理が決定します。 ペルソナが提供する振り分けメタデータは入力であり、最終決定ではありません。
• 意見が一致しない場合は、より保守的な振り分けを選択します。 統合された指摘は safe_auto から gated_auto または manual に変更できますが、より強い根拠がない限り、逆方向には変更しません。
• safe_auto -> review-fixer のみが、スキル内の修正キューに自動的に入ります。
• requires_verification: true は、対象を絞ったテスト、焦点を絞った再レビュー、または運用上の検証を行わなければ修正が完了しないことを意味します。

レビュアー

条件に応じて選択される17のレビュアーペルソナに加え、CE固有のエージェントがあります。全カタログについては、以下に掲載されているペルソナカタログを参照してください。

常時実行（すべてのレビュー）：

エージェント	着眼点
compound-engineering:review:correctness-reviewer	ロジックエラー、エッジケース、状態に関するバグ、エラーの伝播
compound-engineering:review:testing-reviewer	カバレッジの不足、弱いアサーション、壊れやすいテスト
compound-engineering:review:maintainability-reviewer	結合度、複雑さ、命名、デッドコード、抽象化の負債
compound-engineering:review:project-standards-reviewer	CLAUDE.md と AGENTS.md への準拠 -- フロントマター、参照、命名、移植性
compound-engineering:review:agent-native-reviewer	新機能がエージェントから利用できることを確認
compound-engineering:research:learnings-researcher	docs/solutions/ を検索し、この PR に関連する過去の問題を確認

横断的な条件付きレビュー（差分に応じて選択）：

エージェント	次の内容に触れる差分がある場合に選択
compound-engineering:review:security-reviewer	認証、公開エンドポイント、ユーザー入力、権限
compound-engineering:review:performance-reviewer	DB クエリ、データ変換、キャッシュ、非同期処理
compound-engineering:review:api-contract-reviewer	ルート、シリアライザー、型シグネチャ、バージョニング
compound-engineering:review:data-migrations-reviewer	マイグレーション、スキーマの変更、バックフィル
compound-engineering:review:reliability-reviewer	エラー処理、リトライ、タイムアウト、バックグラウンドジョブ
compound-engineering:review:adversarial-reviewer	テスト・生成ファイル・ロックファイル以外の変更行が差分に50行以上ある場合、または認証、支払い、データ変更、外部 API に触れる場合
compound-engineering:review:cli-readiness-reviewer	CLI コマンド定義、引数解析、CLI フレームワークの使用、コマンドハンドラーの実装
compound-engineering:review:previous-comments-reviewer	既存のレビューコメントまたはスレッドがある PR をレビューする場合

スタック固有の条件付きレビュー（差分に応じて選択）：

エージェント	次の内容に触れる差分がある場合に選択
compound-engineering:review:dhh-rails-reviewer	Rails アーキテクチャ、サービスオブジェクト、セッション／認証の選択、または Hotwire と SPA の境界
compound-engineering:review:kieran-rails-reviewer	規約、命名、保守性が関わる Rails アプリケーションコード
compound-engineering:review:kieran-python-reviewer	Python モジュール、エンドポイント、スクリプト、またはサービス
compound-engineering:review:kieran-typescript-reviewer	TypeScript のコンポーネント、サービス、フック、ユーティリティ、または共有型
compound-engineering:review:julik-frontend-races-reviewer	Stimulus／Turbo コントローラー、DOM イベント、タイマー、アニメーション、または非同期 UI フロー

CE の条件付きレビュー（マイグレーション固有）：

エージェント	差分にマイグレーションファイルが含まれる場合に選択
compound-engineering:review:schema-drift-detector	schema.rb と含まれるマイグレーションを相互に照合
compound-engineering:review:deployment-verification-agent	SQL 検証クエリを含むデプロイチェックリストを作成

レビュー範囲

すべてのレビューでは、常時実行される4つのペルソナとCEの常時実行エージェント2つを起動し、さらに差分に適合する横断的およびスタック固有の条件付きレビュアーを追加します。モデルは状況に合わせて自然に人数を調整します。小規模な設定変更では条件付きレビューが0件となり、レビュアーは6人です。Rails の認証機能では、security、reliability、kieran-rails、dhh-rails が起動し、レビュアーは10人になる場合があります。

保護対象のアーティファクト

以下のパスは compound-engineering パイプラインのアーティファクトであり、レビュー担当者は削除、除去、または gitignore の対象として決して指摘してはなりません。

• docs/brainstorms/* -- ce:brainstorm で作成された要件ドキュメント
• docs/plans/*.md -- ce:plan で作成された計画ファイル（進捗チェックボックス付きの継続的に更新されるドキュメント）
• docs/solutions/*.md -- パイプライン中に作成されたソリューションドキュメント

レビュー担当者がこれらのディレクトリ内のファイルを整理または削除の対象として指摘した場合、統合時にその指摘を破棄してください。

実行方法

ステージ 1：対象範囲を決定する

差分の範囲、ファイル一覧、差分を計算します。権限確認のプロンプトを最小限にするため、できるだけ少ないコマンドにまとめてください。

base: 引数が指定されている場合（高速パス）：

呼び出し元は差分のベースをすでに把握しています。ベースブランチの検出、リモートの解決、マージベースの計算はすべて省略してください。指定された値をそのまま使用します。

BASE_ARG="{base_arg}"
BASE=$(git merge-base HEAD "$BASE_ARG" 2>/dev/null) || BASE="$BASE_ARG"

その後、他のパスと同じ出力を生成します。

echo "BASE:$BASE" && echo "FILES:" && git diff --name-only $BASE && echo "DIFF:" && git diff -U10 $BASE && echo "UNTRACKED:" && git ls-files --others --exclude-standard

このパスでは、SHA、origin/main、ブランチ名など、あらゆる ref を使用できます。自動呼び出し元（ce:work、lfg、slfg）は、検出処理のオーバーヘッドを避けるため、この方法を優先してください。**base: を PR 番号またはブランチのターゲットと組み合わせないでください。**両方が指定されている場合は、次のエラーを出して停止します。「base: を PR 番号またはブランチのターゲットと併用することはできません。base: は、現在のチェックアウトがすでに正しいブランチであることを前提とします。base: だけを渡すか、ターゲットだけを渡して、対象範囲の検出でベースを解決してください。」これにより、差分のベースとコードおよびメタデータの取得元が異なることによる、対象範囲と意図の不一致を防げます。

PR 番号または GitHub URL が引数として指定されている場合：

mode:report-only または mode:headless が有効な場合、共有チェックアウトで gh pr checkout <number-or-url> を実行しないでください。mode:report-only の場合は、呼び出し元に次のように伝えてください。「mode:report-only では、PR ターゲットをレビューするために共有チェックアウトを切り替えることはできません。その PR 専用の分離された worktree／チェックアウトから実行するか、すでにチェックアウトされているブランチでターゲット引数を指定せずに report-only を実行してください。」mode:headless の場合は、Review failed (headless mode). Reason: cannot switch shared checkout. Re-invoke with base:<ref> to review the current checkout, or run from an isolated worktree. を出力します。レビューがすでに分離されたチェックアウトで実行されている場合を除き、ここで停止してください。

まず、ブランチを切り替える前に worktree がクリーンであることを確認します。

git status --porcelain

出力が空でない場合は、ユーザーに次のように伝えてください。「現在のブランチに未コミットの変更があります。PR をレビューする前に stash するかコミットしてください。または、スタンドアロンモード（引数なし）を使って、現在のブランチをそのままレビューしてください。」worktree がクリーンになるまで、checkout に進まないでください。

次に、ペルソナエージェントが実際のコードを読めるように、現在のチェックアウトではなく PR ブランチをチェックアウトします。

gh pr checkout <number-or-url>

その後、PR のメタデータを取得します。ブランチ名だけでなく、ベースブランチ名と PR のベースリポジトリの識別情報も取得してください。

gh pr view <number-or-url> --json title,body,baseRefName,headRefName,url

返された PR URL のリポジトリ部分を <base-repo> として使用します（たとえば、https://github.com/EveryInc/compound-engineering-plugin/pull/348 から EveryInc/compound-engineering-plugin を使用します）。

その後、PR のベースブランチに対するローカル差分を計算します。これにより、再レビューにもローカルの修正コミットと未コミットの編集が含まれます。メタデータから取得した PR のベースブランチ（ここでは <base> と表記）と、PR URL から特定した PR のベースリポジトリの識別情報（ここでは <base-repo> と表記）を指定します。origin がそのリポジトリを指していると仮定せず、PR の実際のベースリポジトリからベース ref を解決してください。

PR_BASE_REMOTE=$(git remote -v | awk 'index($2, "github.com:<base-repo>") || index($2, "github.com/<base-repo>") {print $1; exit}')
if [ -n "$PR_BASE_REMOTE" ]; then PR_BASE_REMOTE_REF="$PR_BASE_REMOTE/<base>"; else PR_BASE_REMOTE_REF=""; fi
PR_BASE_REF=$(git rev-parse --verify "$PR_BASE_REMOTE_REF" 2>/dev/null || git rev-parse --verify <base> 2>/dev/null || true)
if [ -z "$PR_BASE_REF" ]; then
  if [ -n "$PR_BASE_REMOTE_REF" ]; then
    git fetch --no-tags "$PR_BASE_REMOTE" <base>:refs/remotes/"$PR_BASE_REMOTE"/<base> 2>/dev/null || git fetch --no-tags "$PR_BASE_REMOTE" <base> 2>/dev/null || true
    PR_BASE_REF=$(git rev-parse --verify "$PR_BASE_REMOTE_REF" 2>/dev/null || git rev-parse --verify <base> 2>/dev/null || true)
  else
    if git fetch --no-tags https://github.com/<base-repo>.git <base> 2>/dev/null; then
      PR_BASE_REF=$(git rev-parse --verify FETCH_HEAD 2>/dev/null || true)
    fi
    if [ -z "$PR_BASE_REF" ]; then PR_BASE_REF=$(git rev-parse --verify <base> 2>/dev/null || true); fi
  fi
fi
if [ -n "$PR_BASE_REF" ]; then BASE=$(git merge-base HEAD "$PR_BASE_REF" 2>/dev/null) || BASE=""; else BASE=""; fi

if [ -n "$BASE" ]; then echo "BASE:$BASE" && echo "FILES:" && git diff --name-only $BASE && echo "DIFF:" && git diff -U10 $BASE && echo "UNTRACKED:" && git ls-files --others --exclude-standard; else echo "ERROR: Unable to resolve PR base branch <base> locally. Fetch the base branch and rerun so the review scope stays aligned with the PR."; fi

gh pr view から PR のタイトル／本文、ベースブランチ、PR URL を抽出し、ローカルコマンドからベースマーカー、ファイル一覧、差分内容、UNTRACKED: リストを抽出してください。checkout 後のレビュー対象範囲として gh pr diff を使用しないでください。これはリモートの PR 状態のみを反映し、プッシュされるまでローカルの修正コミットが含まれません。fetch を試みた後も、PR の実際のベースリポジトリからベース ref を解決できない場合は、git diff HEAD にフォールバックせず停止してください。PR のベースブランチなしでは、PR レビューは不完全です。 引数としてブランチ名が指定されている場合：

指定されたブランチをチェックアウトし、ベースブランチとの差分を確認します。ここでは <branch> と表示されている、指定されたブランチ名に置き換えてください。

mode:report-only または mode:headless が有効な場合は、共有チェックアウトで git checkout <branch> を実行しないでください。mode:report-only の場合は、呼び出し元に次のように伝えてください："mode:report-only cannot switch the shared checkout to review another branch. Run it from an isolated worktree/checkout for <branch>, or run report-only on the current checkout with no target argument." mode:headless の場合は、Review failed (headless mode). Reason: cannot switch shared checkout. Re-invoke with base:<ref> to review the current checkout, or run from an isolated worktree. と出力してください。レビューがすでに隔離されたチェックアウトで実行されている場合を除き、ここで停止してください。

まず、ブランチを切り替える前に、ワークツリーがクリーンであることを確認します。

git status --porcelain

出力が空でない場合は、ユーザーに次のように伝えてください："You have uncommitted changes on the current branch. Stash or commit them before reviewing another branch, or provide a PR number instead." ワークツリーがクリーンになるまで、チェックアウトに進まないでください。

git checkout <branch>

次に、レビューのベースブランチを検出し、マージベースを計算します。フォークに対応したリモート解決と複数のフォールバック検出（PR メタデータ -> origin/HEAD -> gh repo view -> 一般的なブランチ名）を処理する references/resolve-base.sh スクリプトを実行します。

RESOLVE_OUT=$(bash references/resolve-base.sh) || { echo "ERROR: resolve-base.sh failed"; exit 1; }
if [ -z "$RESOLVE_OUT" ] || echo "$RESOLVE_OUT" | grep -q '^ERROR:'; then echo "${RESOLVE_OUT:-ERROR: resolve-base.sh produced no output}"; exit 1; fi
BASE=$(echo "$RESOLVE_OUT" | sed 's/^BASE://')

スクリプトがエラーを出力した場合は、git diff HEAD にフォールバックせず、停止してください。ベースブランチなしでブランチをレビューすると、未コミットの変更しか表示されず、コミット済みの変更がすべて見落とされるためです。

成功した場合は、差分を生成します。

echo "BASE:$BASE" && echo "FILES:" && git diff --name-only $BASE && echo "DIFF:" && git diff -U10 $BASE && echo "UNTRACKED:" && git ls-files --others --exclude-standard

タイトル、本文、関連するイシューのために gh pr view で追加の PR メタデータを取得してもかまいませんが、PR が存在しない場合でも失敗してはいけません。

引数がない場合（現在のブランチを単独でレビュー）：

ブランチモードと同じ references/resolve-base.sh スクリプトを使って、レビューのベースブランチを検出し、マージベースを計算します。

RESOLVE_OUT=$(bash references/resolve-base.sh) || { echo "ERROR: resolve-base.sh failed"; exit 1; }
if [ -z "$RESOLVE_OUT" ] || echo "$RESOLVE_OUT" | grep -q '^ERROR:'; then echo "${RESOLVE_OUT:-ERROR: resolve-base.sh produced no output}"; exit 1; fi
BASE=$(echo "$RESOLVE_OUT" | sed 's/^BASE://')

スクリプトがエラーを出力した場合は、git diff HEAD にフォールバックせず、停止してください。ベースブランチなしで単独レビューを行うと、未コミットの変更しか表示されず、ブランチ上のコミット済み変更がすべて見落とされるためです。

成功した場合は、差分を生成します。

echo "BASE:$BASE" && echo "FILES:" && git diff --name-only $BASE && echo "DIFF:" && git diff -U10 $BASE && echo "UNTRACKED:" && git ls-files --others --exclude-standard

git diff $BASE（..HEAD を付けない）を使うと、マージベースとワーキングツリーとの差分が表示されます。これには、コミット済み、ステージ済み、未ステージの変更がすべてまとめて含まれます。

未追跡ファイルの扱い： FILES:／DIFF: が空でない場合でも、必ず UNTRACKED: の一覧を確認してください。未追跡ファイルは、ステージングされるまでレビュー対象外です。一覧が空でない場合は、除外されるファイルをユーザーに伝えてください。その中にレビュー対象にすべきファイルがある場合は、停止し、まず git add を実行してから再実行するようユーザーに伝えてください。ユーザーが追跡対象の変更のみをレビューする意図である場合に限り、続行してください。mode:headless または mode:autofix の場合は、確認のために停止せず、追跡対象の変更のみで続行し、出力の Coverage セクションに除外された未追跡ファイルを記載してください。

ステージ 2：意図の把握

変更の目的を把握します。意図の情報源は、ステージ 1 で選択した経路によって異なります。

PR/URL モード： gh pr view のメタデータから、PR のタイトル、本文、リンクされた Issue を使用します。本文の情報が少ない場合は、PR のコミットメッセージで補足します。

ブランチモード： ステージ 1 で解決したマージベースを使って、git log --oneline ${BASE}..<branch> を実行します。

単独（現在のブランチ）： 次を実行します。

echo "BRANCH:" && git rev-parse --abbrev-ref HEAD && echo "COMMITS:" && git log --oneline ${BASE}..HEAD

会話のコンテキスト（計画セクションの要約、PR の説明）と組み合わせて、意図の要約を 2～3 行で作成します。

Intent: Simplify tax calculation by replacing the multi-tier rate lookup
with a flat-rate computation. Must not regress edge cases in tax-exempt handling.

これを、各レビュー担当者の起動プロンプトに含めます。意図は、各レビュー担当者がどの程度注意深く確認するかに影響しますが、選択するレビュー担当者には影響しません。

意図が曖昧な場合：

• 対話モード： プラットフォームの対話型質問ツール（Claude Code の AskUserQuestion、Codex の request_user_input）を使って、次の質問を 1 つ尋ねます。「これらの変更の主な目的は何ですか？」意図が明確になるまで、レビュー担当者を起動しないでください。
• 自動修正／レポートのみ／ヘッドレスモード： ブランチ名、差分、PR メタデータ、呼び出し元のコンテキストから、慎重に意図を推測します。処理を中断する代わりに、Coverage または Verdict の理由に不確実性を記載します。

ステージ 2b：計画の検出（要件の検証）

ステージ 6 で要件の網羅性を検証できるよう、計画ドキュメントを特定します。次の情報源を優先順に確認し、最初に見つかったものを使用します。

1. plan: 引数。 呼び出し元から計画のパスが渡された場合は、それを直接使用します。ファイルを読み込み、存在することを確認します。
2. PR 本文。 ステージ 1 で PR メタデータを取得した場合、本文から docs/plans/*.md に一致するパスを探します。一致が 1 件だけ見つかり、ファイルが存在する場合は、plan_source: explicit として使用します。計画のパスが複数見つかった場合は曖昧とみなし、ディスク上に存在する最も新しいものを plan_source: inferred に格下げするか、存在しない場合、または PR のタイトル／意図と明確に関連しない場合はスキップします。選択したファイルは、使用前に必ず存在を確認してください。PR の説明に古い計画リンクやコピーされたリンクが含まれていることはよくあります。
3. 自動検出。 ブランチ名からキーワードを 2～3 個抽出します（例：feat/onboarding-skill -> onboarding、skill）。docs/plans/* を glob で検索し、ファイル名にこれらのキーワードを含むものに絞り込みます。一致が 1 件だけなら、それを使用します。一致が複数ある場合、または一致が曖昧に見える場合（例：review、fix、update のように、多数の計画に一致する可能性がある一般的なキーワード）は、自動検出をスキップします。誤った計画を選ぶより、計画なしのほうが適切です。一致が 0 件の場合もスキップします。

信頼度の記録： 計画の見つけ方を記録します。

• plan: 引数 -> plan_source: explicit（高い信頼度）
• PR 本文で曖昧さのない一致が 1 件 -> plan_source: explicit（高い信頼度）
• PR 本文で複数または曖昧な一致 -> plan_source: inferred（低い信頼度）
• 自動検出で曖昧さのない一致が 1 件 -> plan_source: inferred（低い信頼度）

計画が見つかった場合は、その Requirements Trace（R1、R2 など）と Implementation Units（チェックボックス項目）を読み込みます。抽出した要件の一覧と plan_source をステージ 6 用に保存します。計画が見つからなくてもレビューを中断しないでください。要件の検証は追加的なものであり、必須ではありません。

ステージ 3：レビュアーを選択する

ステージ 1 の差分とファイル一覧を確認します。常時有効な 4 つのペルソナと、CE の常時有効な 2 つのエージェントは自動的に選択されます。以下に含まれるペルソナカタログから、横断的なペルソナとスタック固有の条件付きペルソナをそれぞれ確認し、差分に応じて選択する必要があるか判断します。これはエージェントによる判断であり、キーワード照合ではありません。

条件付き選択におけるファイル形式の考慮： 指示文のファイル（Markdown のスキル定義、JSON スキーマ、設定ファイル）はプロダクトコードですが、ランタイムに焦点を当てたレビュアーには適していません。敵対的レビュー担当者の手法（競合状態、連鎖障害、不正利用のケース）は、実行可能コードの動作を対象とします。指示文のファイルのみを変更する差分では、認証、支払い、データ変更の動作について説明している場合を除き、敵対的レビュー担当者を選択しません。行数のしきい値に数えるのは、実行可能コードの行のみです。

previous-comments は PR 専用です。 ステージ 1 で PR メタデータが収集された場合（PR 番号または URL が引数として指定された、または gh pr view が現在のブランチのメタデータを返した場合）に限り、このペルソナを選択します。関連付けられた PR がない単独のブランチレビューでは、以前のコメントを確認する必要がないため、完全にスキップします。

スタック固有のペルソナは追加で選択します。Rails の UI 変更では kieran-rails と julik-frontend-races の両方が必要になる場合があります。TypeScript の API 差分では kieran-typescript に加えて、api-contract と reliability が必要になる場合があります。

CE の条件付きエージェントについては、差分に db/migrate/*.rb、db/schema.rb、またはデータのバックフィルスクリプトに一致するファイルが含まれるか確認します。

エージェントを起動する前に、チームをアナウンスします。

Review team:
- correctness (always)
- testing (always)
- maintainability (always)
- project-standards (always)
- agent-native-reviewer (always)
- learnings-researcher (always)
- security -- new endpoint in routes.rb accepts user-provided redirect URL
- kieran-rails -- controller and Turbo flow changed in app/controllers and app/views
- dhh-rails -- diff adds service objects around ordinary Rails CRUD
- data-migrations -- adds migration 20260303_add_index_to_orders
- schema-drift-detector -- migration files present

これは進捗報告であり、作業を止めて確認を求めるものではありません。

ステージ 3b：プロジェクト標準のパスを特定する

サブエージェントを起動する前に、project-standards ペルソナに関連する標準ファイルのパス（内容ではありません）をすべて見つけます。ネイティブのファイル検索／glob ツールを使って、次を特定します。

1. ネイティブのファイル検索ツール（Claude Code の Glob など）を使って、リポジトリ内のすべての **/CLAUDE.md と **/AGENTS.md を検索します。
2. ディレクトリが少なくとも 1 つの変更ファイルの祖先にあたるファイルに絞り込みます。標準ファイルは、その配下にあるすべてのファイルに適用されます（例：plugins/compound-engineering/AGENTS.md は plugins/compound-engineering/ 配下のすべてのファイルに適用されます）。

結果のパス一覧を、レビューコンテキスト内の <standards-paths> ブロックに入れて project-standards ペルソナに渡します（ステージ 4 を参照）。ペルソナ自身がファイルを読み、変更されたファイルの種類に関連するセクションのみを対象にします。これにより、オーケストレーターの作業をパスの特定だけに抑え、レビュアーに不要な可能性がある内容でサブエージェントのプロンプトが膨らむのを防ぎます。

ステージ 4：サブエージェントを起動する

モデルの使い分け

ペルソナのサブエージェントは、範囲を絞った作業に取り組むため、レビューの品質を損なわずにコストと遅延を抑えられる高速な中位モデルを使用します。オーケストレーター自体はデフォルトの（最も高性能な）モデルを使います。

すべてのペルソナおよび CE サブエージェントには、プラットフォームの中位モデルを使用します。Claude Code では、Agent ツールの呼び出しで model: "sonnet" を指定します。ほかのプラットフォームでは、同等の中位モデル（Codex の gpt-4o など）を使用します。プラットフォームにモデルの上書き機能がない場合や、利用可能なモデル名が不明な場合は、モデルパラメーターを省略してエージェントにデフォルトを継承させます。認識されないモデル名による起動エラーより、親モデルでレビューが正常に実行される方が望ましいためです。

CE の常時有効なエージェント（agent-native-reviewer、learnings-researcher）と CE の条件付きエージェント（schema-drift-detector、deployment-verification-agent）にも、範囲を絞った集中的な作業を行うため、中位モデルを使用します。

このスキルのオーケストレーターは、意図の把握、レビュアーの選択、指摘事項の統合と重複排除、総合的なまとめを担当します。これらの作業には、より強力な推論能力が役立つため、デフォルトのモデルを使います。

実行 ID

エージェントをディスパッチする前に、一意の実行 ID を生成します。この ID によって、すべてのエージェント成果物ファイルとレビュー後の実行成果物が同じディレクトリにまとめられます。

RUN_ID=$(date +%Y%m%d-%H%M%S)-$(head -c4 /dev/urandom | od -An -tx1 | tr -d ' ')
mkdir -p ".context/compound-engineering/ce-review/$RUN_ID"

すべてのペルソナサブエージェントに {run_id} を渡し、.context/compound-engineering/ce-review/{run_id}/{reviewer_name}.json に分析全文を保存できるようにします。

レポートのみモード： 実行 ID の生成とディレクトリの作成を省略します。エージェントに {run_id} を渡さないでください。レポートのみモードの書き込み禁止の契約に従い、エージェントはファイルへの書き込みを行わず、コンパクトな JSON のみを返します。

エージェントの起動

サブエージェントをディスパッチする際は mode パラメーターを省略し、ユーザーが設定した権限設定を適用します。mode: "auto" は渡さないでください。

選択した各ペルソナレビュー担当者を、以下に含まれるサブエージェントテンプレートを使って並列サブエージェントとして起動します。各ペルソナサブエージェントには、次の内容を渡します。

1. ペルソナファイルの内容（アイデンティティ、失敗モード、調整、抑制条件）
2. 以下に含まれる差分スコープのリファレンスに記載された共通の差分スコープルール
3. 以下に含まれる検出事項スキーマに記載された JSON 出力の契約
4. PR のメタデータ：PR をレビューする場合はタイトル、本文、URL。それ以外の場合は空文字列。レビュー担当者がコードを提示された意図と照合できるよう、<pr-context> ブロックに入れて渡します
5. レビューコンテキスト：意図の概要、ファイル一覧、差分
6. 成果物ファイルのパスに使用する実行 ID とレビュー担当者名
7. project-standards の場合のみ： ステージ 3b の標準ファイルパス一覧。レビューコンテキストに追加し、<standards-paths> ブロックで囲みます

ペルソナサブエージェントは、プロジェクトに対して読み取り専用です。レビューを行い、構造化された JSON を返します。プロジェクトファイルを編集したり、リファクタリングを提案したりしません。許可される書き込みは、出力の契約で指定された .context/ の成果物パスに分析全文を保存することだけです。

ここでいう読み取り専用とは、シェルアクセスがないという意味ではなく、変更を加えないという意味です。レビュー担当サブエージェントは、必要に応じて証拠を集めたりスコープを確認したりするために、git diff、git show、git blame、git log、gh pr view など、読み取りを目的とした git / gh の使用を含む、変更を加えない調査コマンドを実行できます。プロジェクトファイルの編集、ブランチの変更、コミット、プッシュ、PR の作成、その他チェックアウトやリポジトリの状態を変更する操作は禁止されています。

各ペルソナサブエージェントは、すべてのスキーマフィールドを含む JSON 全文を .context/compound-engineering/ce-review/{run_id}/{reviewer_name}.json に保存し、マージに必要なフィールドのみを含むコンパクトな JSON を返します。

{
  "reviewer": "security",
  "findings": [
    {
      "title": "User-supplied ID in account lookup without ownership check",
      "severity": "P0",
      "file": "orders_controller.rb",
      "line": 42,
      "confidence": 0.92,
      "autofix_class": "gated_auto",
      "owner": "downstream-resolver",
      "requires_verification": true,
      "pre_existing": false,
      "suggested_fix": "Add current_user.owns?(account) guard before lookup"
    }
  ],
  "residual_risks": [...],
  "testing_gaps": [...]
}

詳細レベルのフィールド（why_it_matters、evidence）は成果物ファイルにのみ含めます。suggested_fix はどちらのレベルでも任意です。含まれている場合は、オーケストレーターが自動適用の判断に必要な修正のコンテキストを得られるよう、コンパクトな戻り値にも含めます。ファイルへの書き込みに失敗しても、コンパクトな戻り値からマージに必要なすべての情報を得られます。

常時実行する CE エージェント（agent-native-reviewer、learnings-researcher）は、ペルソナエージェントと並行して標準の Agent 呼び出しとしてディスパッチします。ペルソナに渡すものと同じレビューコンテキスト一式を渡します。これには、エントリーモード、ステージ 1 で取得した PR メタデータ、意図の概要、判明している場合はレビュー対象のベースブランチ名、BASE: マーカー、ファイル一覧、差分、UNTRACKED: スコープの注記が含まれます。「これをレビューしてください」のような一般的なプロンプトで呼び出さないでください。出力は非構造化形式で、ステージ 6 で別途統合します。

条件付き CE エージェント（schema-drift-detector、deployment-verification-agent）も、該当する場合は標準の Agent 呼び出しとしてディスパッチします。同じレビューコンテキスト一式に加え、適用理由（たとえば、エージェントの起動条件となったマイグレーションファイル）を渡します。schema-drift-detector には、解決済みのレビュー対象ベースブランチを明示的に渡し、main を仮定しないようにします。出力は非構造化形式であり、常時実行する CE エージェントと同様に、ステージ 6 の統合用として保持します。

ステージ 5：指摘事項を統合する

複数のレビュー担当者から返されたコンパクトな JSON を、重複を除去し、信頼度ゲートを適用した 1 つの指摘事項セットにまとめます。コンパクトな戻り値には、統合用フィールド（title、severity、file、line、confidence、autofix_class、owner、requires_verification、pre_existing）と、任意の suggested_fix が含まれます。詳細用フィールド（why_it_matters、evidence）はエージェントごとの成果物ファイルにディスク上で保存されており、この段階では読み込みません。

1. 検証する。 各コンパクトな戻り値について、必須のトップレベルフィールドと指摘事項ごとのフィールド、および値の制約を確認します。不正な戻り値または指摘事項は破棄します。破棄件数を記録します。
   • トップレベルの必須フィールド： reviewer（文字列）、findings（配列）、residual_risks（配列）、testing_gaps（配列）。欠落しているフィールドがある、または型が異なる場合は、戻り値全体を破棄します。
   • 指摘事項ごとの必須フィールド： title、severity、file、line、confidence、autofix_class、owner、requires_verification、pre_existing
   • 値の制約：
     • severity：P0 | P1 | P2 | P3
     • autofix_class：safe_auto | gated_auto | manual | advisory
     • owner：review-fixer | downstream-resolver | human | release
     • confidence：数値、0.0～1.0
     • line：正の整数
     • pre_existing、requires_verification：ブール値
   • ここでは完全なスキーマに対する検証は行いません。why_it_matters と evidence を含む完全なスキーマが適用されるのは、ディスク上の成果物ファイルであり、コンパクトな戻り値ではありません。
2. 信頼度ゲート。 confidence が 0.60 未満の指摘事項は除外します。ただし、confidence が 0.50 以上の P0 指摘事項はゲートを通過します。重大だが不確かな問題を黙って破棄してはなりません。除外件数を記録します。これはペルソナの指示およびスキーマの信頼度しきい値に準拠しています。
3. 重複を除去する。 フィンガープリントを計算します：normalize(file) + line_bucket(line, +/-3) + normalize(title)。フィンガープリントが一致した場合は統合し、最も高い severity と最も高い confidence を残し、どのレビュー担当者が指摘したかを記録します。
4. レビュー担当者間の合意。 独立したレビュー担当者が 2 人以上、同じ問題（同じフィンガープリント）を指摘した場合は、統合後の confidence を 0.10 引き上げます（上限は 1.0）。レビュー担当者間の合意は強いシグナルです。同じ問題に独立したレビュー担当者が収束することは、単一のレビュー担当者の信頼度よりも信頼性が高くなります。出力の Reviewer 列に合意内容を記録します（例：「security, correctness」）。
5. 既存の指摘を分ける。 pre_existing: true の指摘事項を別のリストに分けます。
6. 意見の相違を解決する。 レビュー担当者が同じコード領域を指摘していて、severity、autofix_class、または owner について意見が異なる場合は、Reviewer 列に相違を注記します（例：「security (P0), correctness (P1) -- kept P0」）。この透明性により、指摘事項がそのように振り分けられた理由をユーザーが理解しやすくなります。
7. ルーティングを正規化する。 統合した各指摘事項について、最終的な autofix_class、owner、requires_verification を設定します。レビュー担当者間で意見が異なる場合は、最も保守的なルートを選びます。統合時に safe_auto から gated_auto または manual へ指摘事項を絞り込むことはできますが、新たな根拠なしに適用範囲を広げてはなりません。
8. 作業を振り分ける。 次の 3 つのセットを作成します。
   • スキル内の修正キュー：safe_auto -> review-fixer のみ
   • 残りの対応可能なキュー：未解決の gated_auto または manual の指摘事項のうち、owner が downstream-resolver のもの
   • レポートのみのキュー：advisory の指摘事項、および owner が human または release のもの
9. 並べ替える。 severity（P0 が先）-> confidence（降順）-> file path -> line number の順に並べます。
10. カバレッジデータを収集する。 各レビュー担当者の residual_risks と testing_gaps の和集合を作成します。
11. CE エージェントの成果物を保持する。 learnings、agent-native、schema-drift、deployment-verification の出力を、統合した指摘事項セットとともに保持します。ペルソナの JSON スキーマに一致しないという理由だけで、構造化されていないエージェント出力を破棄してはなりません。

ステージ 6：統合して提示する

以下に含まれるレビュー出力テンプレートを使用して、最終レポートを組み立てます。所見にはパイプ区切りの Markdown テーブルを使用してください。インタラクティブモードでは、所見の行をテーブル形式にする必要があります。所見を自由形式のテキストブロックや、水平線で区切った文章として記載しないでください。その他のレポートセクション（適用した修正、学び、カバレッジなど）では、テンプレートに示すように箇条書きと、判定の前に --- 区切りを使用します。

1. ヘッダー。 スコープ、意図、モード、条件ごとの根拠を含むレビューチーム。
2. 所見。 重大度ごとにグループ化したパイプ区切りのテーブルとして表示します（### P0 -- Critical、### P1 -- High、### P2 -- Moderate、### P3 -- Low）。各所見の行には、#、ファイル、問題、レビュアー、確信度、統合した対応方針を記載します。該当する所見がない重大度レベルは省略します。所見を自由形式のテキストブロックや番号付きリストとして表示しないでください。
3. 要件の網羅性。 ステージ 2b で計画が見つかった場合にのみ記載します。計画に含まれる各要件（R1、R2 など）と実装単位について、対応する作業が差分に含まれているかを報告します。簡潔なチェックリストを使用し、完了／未対応／一部対応を示します。振り分けは plan_source によって異なります。
   • explicit（呼び出し元が提供したもの、または PR 本文）：未対応の要件は、autofix_class: manual、owner: downstream-resolver の P1 所見としてフラグ付けします。これらは残作業の対応可能キューに入り、TODO になることがあります。
   • inferred（自動検出されたもの）：未対応の要件は、autofix_class: advisory、owner: human の P3 所見としてフラグ付けします。これらはレポートにのみ記載し、TODO にはせず、自律的なフォローアップも行いません。推定された計画との一致はヒントであり、契約ではありません。 計画が見つからなかった場合は、このセクション全体を省略します。計画がなかったことにも言及しないでください。
4. 適用した修正。 今回の呼び出しで修正フェーズが実行された場合にのみ記載します。
5. 残作業。 未解決の対応可能な所見が引き継がれた、または引き継ぐべき場合に記載します。
6. 既存の問題。 独立したセクションとして記載し、判定には含めません。
7. 学びと過去の解決策。 learning-researcher の結果を提示します。関連する過去の解決策がある場合は、docs/solutions/ 内のファイルへのリンクを付けて「既知のパターン」としてフラグ付けします。
8. エージェントネイティブな不足点。 agent-native-reviewer の結果を提示します。不足点が見つからなかった場合は、このセクションを省略します。
9. スキーマドリフトの確認。 schema-drift-detector が実行された場合、ドリフトが見つかったかどうかを要約します。ドリフトがある場合は、無関係なスキーマオブジェクトと必要なクリーンアップコマンドを列挙します。問題がなければ、その旨を簡潔に記載します。
10. デプロイに関する注意事項。 deployment-verification-agent が実行された場合、Go／No-Go の重要項目を提示します。デプロイ前に必要なブロッキングチェック、最も重要な検証クエリ、ロールバック時の注意事項、監視の重点領域を含めます。カバレッジにそのまま押し込むのではなく、実行可能なチェックリストにしてください。
11. カバレッジ。 抑制された件数、残存リスク、テストの不足、失敗またはタイムアウトしたレビュアー、インタラクティブでないモードにおける意図の不確実性を記載します。
12. 判定。 マージ可能／修正後に対応可能／対応不可。該当する場合は修正順序も記載します。explicit な計画に未対応の要件がある場合は、それを判定に反映しなければなりません。コードに問題がなくても、計画された要件が欠けている PR は、意図的な省略でない限り「対応不可」です。inferred な計画に未対応の要件がある場合は、判定理由に記載しますが、それだけを理由に対応をブロックしないでください。

所要時間の見積もりは記載しないでください。

形式の検証： レポートを提出する前に、所見セクションが自由形式の文章ではなく、パイプ区切りのテーブル行（| # | ファイル | 問題 | ... |）になっていることを確認します。水平線で区切った文章や箇条書きで所見を書いていることに気付いた場合は、いったん止めてテーブル形式に直してください。

ヘッドレス出力形式

mode:headless では、対話型のパイプ区切りテーブルレポートを、構造化されたテキストエンベロープに置き換えます。エンベロープは、document-review のヘッドレス出力と同じ構造パターン（完了ヘッダー、メタデータブロック、autofix_class でグループ化された指摘、末尾のセクション）に従いつつ、ce:review 独自のセクション見出しと指摘ごとのフィールドを使用します。

Code review complete (headless mode).

Scope: <scope-line>
Intent: <intent-summary>
Reviewers: <reviewer-list with conditional justifications>
Verdict: <Ready to merge | Ready with fixes | Not ready>
Artifact: .context/compound-engineering/ce-review/<run-id>/

Applied N safe_auto fixes.

Gated-auto findings (concrete fix, changes behavior/contracts):

[P1][gated_auto -> downstream-resolver][needs-verification] File: <file:line> -- <title> (<reviewer>, confidence <N>)
  Why: <why_it_matters>
  Suggested fix: <suggested_fix or "none">
  Evidence: <evidence[0]>
  Evidence: <evidence[1]>

Manual findings (actionable, needs handoff):

[P1][manual -> downstream-resolver] File: <file:line> -- <title> (<reviewer>, confidence <N>)
  Why: <why_it_matters>
  Evidence: <evidence[0]>

Advisory findings (report-only):

[P2][advisory -> human] File: <file:line> -- <title> (<reviewer>, confidence <N>)
  Why: <why_it_matters>

Pre-existing issues:
[P2][gated_auto -> downstream-resolver] File: <file:line> -- <title> (<reviewer>, confidence <N>)
  Why: <why_it_matters>

Residual risks:
- <risk>

Learnings & Past Solutions:
- <learning>

Agent-Native Gaps:
- <gap description>

Schema Drift Check:
- <drift status>

Deployment Notes:
- <deployment note>

Testing gaps:
- <gap>

Coverage:
- Suppressed: <N> findings below 0.60 confidence (P0 at 0.50+ retained)
- Untracked files excluded: <file1>, <file2>
- Failed reviewers: <reviewer>

Review complete

詳細のエンリッチメント（ヘッドレスのみ）: ヘッドレスエンベロープには Why:、Evidence:、Suggested fix: の行が含まれます。マージ後（ステージ 5）、重複排除と信頼度ゲートを通過した指摘のみについて、.context/compound-engineering/ce-review/{run_id}/ からエージェントごとの成果物ファイルを読み取ります。

• フィールドの階層: Why: と Evidence: は詳細階層です -- エージェントごとの成果物ファイルから読み込みます。Suggested fix: はマージ階層です -- 成果物の参照なしで、コンパクトな戻り値から直接使用します。
• 成果物のマッチング: 生き残った各指摘について、寄与したレビュアーの成果物ファイル内でその詳細階層フィールドを検索します。各寄与レビュアーの成果物内で file + line_bucket(line, +/-3)（ステージ 5 の重複排除で使用したものと同じ許容範囲）でマッチングします。複数の成果物エントリがラインブラケット内に入る場合は、タイブレーカーとして、マージされた指摘のタイトルと各候補エントリのタイトルの両方に normalize(title) を適用します。
• レビュアーの順序: マージされた指摘のレビュアーリストに現れる順序で寄与レビュアーを試し、最初にマッチしたものを使用します。
• マッチなしのフォールバック: どの成果物ファイルにもマッチが含まれていない場合（すべての書き込みが失敗した、またはマージ中に指摘が合成された）、その指摘について Why: と Evidence: の行を省略し、Coverage にそのギャップを記録します。Suggested fix: の行はマージ階層であるため、コンパクトな戻り値から引き続き入力できます。

フォーマット規則:

• [needs-verification] マーカーは、requires_verification: true である指摘にのみ表示されます。
• Artifact: 行は、完全な指摘スキーマへの機械可読なアクセスのために、呼び出し元に完全な実行成果物へのパスを提供します。テキストエンベロープが主要な受け渡し手段であり、成果物はデバッグと完全な忠実度でのアクセスのためのものです。
• owner: release の指摘は Advisory セクションに表示されます（これらはコード修正ではなく、運用/ロールアウトの項目です）。
• pre_existing: true の指摘は、autofix_class に関係なく Pre-existing セクションに表示されます。
• Verdict はメタデータヘッダーに表示されます（対話型形式では下部に表示されるのに対し、意図的に並べ替えられています）。これにより、プログラムによる呼び出し元が最初に判定を取得できます。
• 項目がゼロのセクションは省略します。
• すべてのレビュアーが失敗またはタイムアウトした場合は、Code review degraded (headless mode). Reason: 0 of N reviewers returned results. に続けて "Review complete" を出力します。
• 呼び出し元が完了を検出できるよう、終端シグナルとして "Review complete" で終了します。

品質ゲート

レビューを提出する前に、以下を検証します。

1. すべての指摘が実行可能であること。 各指摘を読み直します。「検討する」「〜したほうがよいかもしれない」「改善できる」と具体的な修正なしに述べている場合は、具体的なアクションとともに書き直します。曖昧な指摘はエンジニアリングの時間を無駄にします。
2. 流し読みによる誤検出がないこと。 各指摘について、周囲のコードが実際に読まれたことを検証します。その「バグ」が同じ関数内の別の場所で処理されていないか、「未使用のインポート」が型アノテーションで使用されていないか、「欠落した null チェック」が呼び出し元でガードされていないかを確認します。
3. 重大度が適切に調整されていること。 スタイルの些末な指摘が P0 になることは決してありません。SQL インジェクションが P3 になることは決してありません。すべての重大度の割り当てを再確認します。
4. 行番号が正確であること。 引用された各行番号をファイルの内容と照合して検証します。誤った行を指す指摘は、指摘がないよりも有害です。
5. 保護された成果物が尊重されていること。 docs/brainstorms/、docs/plans/、docs/solutions/ 内のファイルを削除または gitignore することを推奨する指摘は破棄します。
6. 指摘がリンターの出力と重複しないこと。 プロジェクトのリンター/フォーマッターが検出するもの（セミコロンの欠落、誤ったインデント）を指摘しません。セマンティックな問題に焦点を当てます。

言語に応じた条件分岐

差分から明らかに必要と判断できる場合、このスキルではスタック固有のレビュアーエージェントを使用します。それらのエージェントには明確な見解を持たせてください。汎用的な言語チェッカーではなく、常時有効なペルソナや分野横断的なペルソナに、独自のレビュー視点を加えるものです。

ファイル拡張子だけを根拠に機械的に起動しないでください。起動の判断基準は、そのスタックにおける動作、アーキテクチャ、または UI の状態に、意味のある変更があることです。

レビュー後

モードに応じたレビュー後のフロー

所見と判定を提示した後（ステージ 6）、モードに応じて次の手順に進みます。レビューと統合はすべてのモードで同じですが、変更と引き継ぎの動作のみ異なります。

ステップ 1：アクションセットを作成する

• クリーンなレビューとは、抑制と既存項目の切り分け後に所見がゼロであることを指します。レビューがクリーンな場合、修正／引き継ぎフェーズを省略します。
• 修正キュー： 最終所見のうち、safe_auto -> review-fixer に割り当てられたもの。
• 残存する対応可能なキュー： 未解決の gated_auto または manual の所見のうち、最終的な所有者が downstream-resolver であるもの。
• レポートのみのキュー： advisory の所見、および human または release が所有する出力。
• 助言のみの出力を修正作業や TODO に変換してはいけません。 デプロイに関する注記、残存するリスク、リリース担当者が所有する項目はレポートに残します。

ステップ 2：モードに応じて方針を選択する

インタラクティブモード

• safe_auto -> review-fixer の所見は定義上安全なため、確認を求めずに自動で適用します。

• 安全な修正後も gated_auto または manual の所見が残る場合に限り、プラットフォームのブロッキング質問ツール（Claude Code では AskUserQuestion、Codex では request_user_input、Gemini では ask_user）を使って方針を質問します。自由形式の会話的な質問で代用しないでください。実際に残っている所見に合わせて選択肢を調整します。

  gated_auto の所見がある場合（manual の所見の有無は問いません）：

  Safe fixes have been applied. What should I do with the remaining findings?
  1. Review and approve specific gated fixes (Recommended)
  2. Leave as residual work
  3. Report only -- no further action
  

  manual の所見のみが残る場合（gated_auto の所見がない場合）：

  Safe fixes have been applied. The remaining findings need manual resolution. What should I do?
  1. Leave as residual work (Recommended)
  2. Report only -- no further action
  

  ブロッキング質問ツールが利用できない場合は、該当する番号付きの選択肢をテキストで提示し、ユーザーが選択するまで先に進まないでください。

• 安全な修正後に gated_auto または manual の所見が残らない場合、方針に関する質問は完全に省略し、修正内容を報告して次の手順に進みます。

• ユーザーが特定の項目を明示的に承認した場合に限り、その gated_auto の所見を修正キューに追加します。重要度のみを理由にキューの範囲を広げないでください。

自動修正モード

• 質問はしません。
• safe_auto -> review-fixer のキューのみを適用します。
• gated_auto、manual、human、release の項目は未解決のままにします。
• 最終的な所有者が downstream-resolver である、未解決の対応可能な所見に限り、残作業を準備します。

レポートのみのモード

• 質問はしません。
• 修正キューを作成しません。
• 残作業の TODO や .context アーティファクトを作成しません。
• ステージ 6 の後で終了します。すべての内容はレポートに残します。

ヘッドレスモード

• 質問はしません。
• 1 回の処理で safe_auto -> review-fixer のキューのみを適用します。制限付きの再レビューのループ（ステップ 3）には入りません。修正用サブエージェントを 1 つ起動して修正を適用した後、ステップ 4 に直接進みます。
• gated_auto、manual、human、release の項目は未解決のままにし、構造化テキスト出力に表示します。
• インタラクティブレポートの代わりに、ヘッドレス出力エンベロープ（ステージ 6 を参照）を出力します。
• 実行アーティファクトを作成します（ステップ 4）が、TODO ファイルは作成しません。
• 構造化テキスト出力と「Review complete」のシグナルの後で終了します。コミット／プッシュ／PR は行いません。

Step 3: 1 つの修正担当と上限付きのラウンドで修正を適用する

• 現在のチェックアウトで、現在の修正担当キューに対して修正担当サブエージェントを正確に 1 つ起動します。その修正担当は、整合性の取れたツリーに対して、承認済みの変更をすべて適用し、関連する対象テストを 1 回の処理で実行します。
• 同じチェックアウトに対して複数の修正担当を並行して起動しないでください。修正担当を並行して起動するには、作業ツリー／ブランチを分離し、意図的にマージバックする必要があります。
• 修正が適用されたら、変更された範囲のみを再レビューします。
• max_rounds: 2 でループに上限を設けます。2 回目のラウンドの後も問題が残る場合は、そこで停止し、残作業として引き継ぐか、未解決として報告します。
• 適用された指摘のいずれかに requires_verification: true が設定されている場合、対象の検証を実行するまで、そのラウンドは完了していません。
• 同じチェックアウトで、変更を加えるレビューラウンドをブラウザーテストと並行して開始しないでください。両方を並行して実行する今後のオーケストレーターは、並行フェーズ中に mode:report-only を実行するか、変更を加えるレビューを独自のチェックアウト／作業ツリーに分離する必要があります。

Step 4: 成果物を出力し、後続処理へ引き継ぐ

• インタラクティブ、自動修正、ヘッドレスの各モードでは、実行ごとの成果物を .context/compound-engineering/ce-review/<run-id>/ 以下に書き込みます。成果物には次の内容を含めます。
  • 統合された指摘（Stage 5 の統合出力）
  • 適用された修正
  • 対応可能な残作業
  • アドバイザリーのみの出力 エージェントごとの詳細な JSON ファイル（{reviewer_name}.json）は、Stage 4 のディスパッチ時にこのディレクトリへすでに出力されています。
• また、後続のスキル（例：ce:polish-beta）が成果物と現在のブランチおよび HEAD の一致を検証できるよう、指摘と同じ場所に metadata.json を書き込みます。必須フィールド：

  {
    "run_id": "<run-id>",
    "branch": "<git branch --show-current at dispatch time>",
    "head_sha": "<git rev-parse HEAD at dispatch time>",
    "verdict": "<Ready to merge | Ready with fixes | Not ready>",
    "completed_at": "<ISO 8601 UTC timestamp>"
  }
  

  branch と head_sha はディスパッチ時（自動修正が適用される前）に記録し、判定が確定した後にファイルを書き込みます。このファイルは追加情報です。このフィールドが追加される前の既存成果物も引き続き有効であり、フィールドがない場合、後続のスキルはファイルの更新日時を使用します。
• 自動修正モードでは、最終的な担当が downstream-resolver である、未解決の対応可能な指摘についてのみ、永続的な TODO ファイルを作成します。標準のディレクトリパス、命名規則、YAML フロントマターの構造、テンプレートについては、todo-create スキルを読み込みます。各 TODO では、指摘の重大度を TODO の優先度（P0／P1 -> p1、P2 -> p2、P3 -> p3）に対応させ、これらの指摘は統合時にすでにトリアージ済みのため、status: ready を設定します。
• advisory の指摘、owner: human、owner: release、保護対象成果物のクリーンアップに関する提案については、TODO を作成しないでください。
• アドバイザリーのみの出力が残っている場合、TODO は作成しません。
• インタラクティブモードでは、修正後に残った対応可能な作業を外部化する提案をしてもかまいませんが、レビューを完了するための必須事項ではありません。

Step 5: 最終的な次のステップ

インタラクティブモードのみ： 修正とレビューのサイクルが完了した後（問題なしと判定された場合、またはユーザーが停止を選択した場合）、開始モードに応じて次のステップを提示します。Stage 1 で解決済みのレビュー対象ベースブランチ／デフォルトブランチが分かっている場合はそれを使用し、main／master のみに決め打ちしないでください。

• PR モード（PR 番号／URL から開始）：
  • 修正をプッシュ -- コミットを既存の PR ブランチにプッシュ
  • 終了 -- 今回は終了
• ブランチモード（PR のない機能ブランチで、解決済みのレビュー対象ベースブランチ／デフォルトブランチではない場合）：
  • PR を作成（推奨） -- プッシュしてプルリクエストを開く
  • PR を作成せずに続行 -- ブランチにとどまる
  • 終了 -- 今回は終了
• 解決済みのレビュー対象ベースブランチ／デフォルトブランチの場合：
  • 続行 -- 次のステップに進む
  • 終了 -- 今回は終了

「PR を作成」を選択した場合、まず git push --set-upstream origin HEAD でブランチを公開し、その後、ブランチの変更内容から作成したタイトルと概要を指定して gh pr create を使用します。 「修正をプッシュ」を選択した場合、既存の PR を更新するため、git push でブランチをプッシュします。

自動修正、レポートのみ、ヘッドレスの各モード： レポート、成果物の出力、残作業の引き継ぎが完了した時点で停止します。コミット、プッシュ、PR の作成は行わないでください。

フォールバック

プラットフォームが並列サブエージェントをサポートしていない場合は、レビュー担当者を順番に実行してください。それ以外のすべて（ステージ、出力形式、マージパイプライン）は変わりません。

---

付属の参照資料

ペルソナカタログ

@./references/persona-catalog.md

サブエージェントテンプレート

@./references/subagent-template.md

差分範囲のルール

@./references/diff-scope.md

指摘事項のスキーマ

@./references/findings-schema.json

レビュー出力テンプレート

@./references/review-output-template.md