/da-review-all — 層をまたぐレビューのディスパッチャ

変更が触る層を割り出し、該当する層のレビューだけを走らせ、どの層の中からも見えない層またぎの不可逆リスクを拾う。

読み取り専用。コードも設定も変更しない。 Step 5 の概要ページはレビューの成果物で、ソースの変更ではない。

返すものは誰の変更かで変わる（Step 1）。

実行条件

上流: 実装完了、または PR が開いている。下流: /da-fix-plan が所見を順序付きの計画にし、次に /da-verify。

委譲先

読むファイルとタイミング

最初には何も読まない。 各ファイルは適用するステップで開く。

1 層だけなら、Step 4 の行は cross-layer.md だけ読み、層横断の影響なし と書いてそのまま通す。Step 1 / 4b / 5 / 6 は変わらない。1 層の PR でも概要ページと下書きを作る。

Step 1. スコープを決め、次に持ち主を決める

cwd が git 内かは問わない。 PR URL は共通手順の PR 経路で解決する。

$ARGUMENTS: PR URL ならその PR、空なら作業中の差分、ブランチならそれとの差分、パスならそのパスの監査、all ならリポジトリ全体。

base とファイル一覧は ../_shared/review-process.md の Step 1 と同じ方法で決め、決められなかった時はその旨を書く。

複数 PR の対応付けも共通手順の Step 1 で行う。

誰の変更か

gh pr view <PR_URL> --json author -q .author.login    # or: git log -1 --format=%ae
git config user.email

review-process.md の Step 1 のとおり、持ち主は何を仮定してよいかを決める。返すものも決める。

曖昧なら（共有ブランチ、ペアで書いた変更）聞く。 取り違えると成果物がまるごと違う形になる。

Step 2. 各ファイルを層に分類する

1 つのファイルが複数の層に属してよい。

モノレポや複数リポジトリでは、リポジトリ・ディレクトリごとに分類する。置き場の分からないファイルは中身で分類し、それでも不明なら unclassified として列挙する。黙って落とさない。

分類を表示し、確認を待たずに進む。 誤分類は層を 1 つ丸ごと失うので見える必要はあるが、承認は要らない。止まるのは unclassified のファイルがある時だけ（進めると推測になる）。

Step 3. 層のレビューを走らせる — inline か fan-out か

Step 1b で測った範囲（生成物を除く）の行数で段を決める。

Use the x-review-<layer> skill and follow it exactly. Scope: <the list>. Do not re-derive the full diff.

層の指示をここに書き直さない。 fan-out の役にも層のスキル名を渡す。層のスキルに disable-model-invocation を付けない（Skill 呼び出しが黙って空振りする。lint が検査）。

分ける理由は独立性ではなく量（決定 41）。役のモデルは固定しない。サブエージェントの無いホストでは inline に戻り、サンプルだと書く。

各層が Step 2b の適合スイープ（アーキテクチャ、依存の向き、不可逆な面、テナント、新しい入口）を、ファイル一覧全体に行ごとの判定付きで報告したか確かめる。差分の大きさは関係ない。アーキテクチャを形だけで済ませた層は差し戻す。

unclassified のファイル: 中身で最も近い層に入れる。どうしても置けないものは Step 4 で明示的にレビューし、「未レビュー / 要確認」と付ける。

Step 4. 層をまたぐ統合 — このスキルにしかできないこと

すべての層のレポートが揃うまで待ち、cross-layer.md を読んで 10 のチェックすべてを当てる（構造上の 4 つの形、層をまたぐ形の 5 パターン、境界にしか無い 6 つ目）。どれも原因と結果が別の層にあり、どの層のレビューも届かない。

すべての層の 🧭 と 👤 を先頭に集め、重複をまとめる。2 つの層に出た同じ根本原因は、両方を名指す 1 つの所見にして 1 回だけ数える。層ごとの件数を足し合わせない。

Step 4b. 決まっていないことの洗い出し — 他人の PR のみ

decisions-sweep.md を読む。差分全体のマーカー探索と、レビューで浮かんだマーカーの無い判断の 2 つを見る。

未決だと言うのではなく、答えによって何が変わるかを書く。

Step 5. 1 枚の概要ページ

overview-artifact.md を読み、6 つの節と入れ物を決める。Claude Code では Artifact、Cursor では Canvas、どちらも無い場合は HTML ファイルを書く。 節はどの入れ物でも同じ。

ページはレビューではなく変更についてのもの。 所見は下書きに置き、ページには 🔎 / 🔬 の正直さの行と未決事項を載せる。

自分の作業の場合は、頼まれずに作らず、1 行で申し出る。

Step 6. コメントの下書きとターミナルの索引 — 他人の PR のみ

pr-comments.md に最初から最後まで従う。規則で選び、Step 1 で読んだ口調で下書きし、すべてのアンカーを PR の head で確かめ、下書きを見せ、文字どおりの Go を待つ。

ターミナルに出すのはレポートではなく索引。 下書きごとに対象・重大度・1 行。続けてページへのリンク。ページや下書きの内容をここで繰り返さない。

完了条件

• 何かを作る前に持ち主が決まり、成果物がそれに合っている
• どのレビューより先に分類が表示され、すべてのファイルが層に入っている（unclassified があれば止まっている）
• すべての層が Step 2b のスイープを行ごとの判定付きで報告した（抜き取りで済ませていない）
• ファイルのある層がすべてスキル名で呼ばれた（中身無しに「扱った」と報告された層が無い）
• 🔎 に段（「inline, no subagents」か「fan-out: レビュー役 N、反証役 M」）を書き、届かなかったものと形だけのクラスタを名指し、問題なしの結果が承認ではないと述べている
• cross-layer.md の 10 のチェックをすべて当てた。 すべての 🔗 が両方の層を名指し、各側に 📍 がある。まとめた重複は 1 回だけ数える。1 層の変更では 層横断の影響なし と書く
• このホストの入れ物で概要ページが 1 枚あり、リンクされ、ページ上の所見をターミナルや下書きで繰り返していない
• 他人の PR: 口調プロファイルを読んだ後に下書きを書き、投稿前に全アンカーを PR の head で確かめ、Step 4b を実行した

ガードレール

• コードも設定も変更しない。読み取り専用。
• 投稿は Go か明示の投稿指示があった時だけ。APPROVE / REQUEST_CHANGES は、ユーザーがその返信でそう言った時だけ。
• 変更が触らない層のレビューは走らせない。
• 層をまたぐ所見にも、他と同じく追跡した経路が要る（finding-discipline.md）。実際に使われる経路、設定のロールアウト順、両側が一緒にリリースされるか。