plan-review

name	plan-review
description	workspace/plan.md の完成後、実装着手前に使用。計画の影響範囲・不変条件・スコープの漏れを検証する。
allowed-tools	["Read","Glob","Agent","Bash(gh issue view *)","Bash(rm -rf workspace/plan-review)","Bash(mkdir -p workspace)","Bash(mkdir workspace/plan-review)"]

workspace/plan.md を読み、内容に基づいてサブエージェントを並列起動して検証する。

Step 1 — plan.md の読み込み

workspace/plan.md を読み、以下を把握する:

• 変更対象ファイルと変更内容
• 実装フェーズ構成
• 不変条件の記述
• テスト方針

Step 2 — 並列サブエージェントで検証

変更対象のレイヤー（Rust crate・設定ファイル・ガバナンス文書・scripts/ など）ごとにサブエージェントを分割して並列起動する。

起動前に台帳を確定する: 「レイヤー名 → 出力パス → 分割根拠（plan.md の変更ファイル）」を会話へ表として出力してから起動する。結果を見たあとにディスクから起こしたものは台帳ではない——それは写しであり、落ちたスカウトは写しにも現れない。台帳には /plan-review「Step 2b — 独立導出 + 差分（常に実施・盲点クラスの漏れ検出）」の 1 体も含める（配送経路を 1 本に束ねる）。

• 台帳が plan.md を覆っているかを先に検算する: plan.md の変更ファイルがどれか 1 つのレイヤーに必ず属することを確認する。どのレイヤーにも属さないファイルは、行が立たない以上ファイルも不着も不成立も生まない——照合をいくら厳密にしても false green が 1 段上へ移るだけである（.claude/rules/safety-nets.md「検査の入力集合を、具体対象で検算する」）
• 出力先は workspace/plan-review/<slug>.md。<slug> は [a-z0-9-]+ で台帳内で一意であること（衝突すると後勝ちで 1 体分が消え、N 件中 N 件実在のまま照合を通る）。スカウトへは絶対パスで渡す——委譲はコンテキストを継承せず worktree 隔離も使えるため、相対パスは別ツリーへ落ちて回収不能になる
• 起動の前に、Bash ツール（Git Bash・cwd はリポジトリルート・実測）で次の 3 コマンドを順に実行する: rm -rf workspace/plan-review → mkdir -p workspace → mkdir workspace/plan-review（-p を付けない）。PowerShell では rm -rf は失敗する（Remove-Item の別名で -rf を解釈できない・実測）。rm は対象が無くても exit 0 で削除できた証跡が残らず、mkdir -p は既存ディレクトリでも exit 0 なので観測点にならない（実測）——葉だけを非冪等にすることで、削除が silent fail していれば mkdir が失敗して止まる（-p 無しは既存ディレクトリに対して exit 1・実測）
• 消す理由: 残すと、同じスラグのスカウトが落ちたときに前サイクルのファイルを「今回の成果物」と読んでしまう——不着が沈黙する経路である。新鮮性を保証するのはこの削除だけである（/start-issue の上書き列挙は「上書き」であって、書き手が落ちた回には何も起きない。単独実行かどうかを問わない）。コミット済みの前回分も消えるが git から復元できる
• 「揃ったか」を判定する母集団はこの台帳とディスクであって、返ってきた報告ではない（照合は /plan-review「Step 3 — 結果の統合と報告」）

各サブエージェントへの指示に含めるもの:

1. 担当レイヤーと対象ファイル: plan.md に記載の変更ファイルを起点にする

2. 検証観点（担当レイヤーに関係するものを全て確認）:

   影響範囲

   • 変更する関数・型・共有状態・イベント定数（src-tauri/src/events.rs）の呼び出し元を grep し、plan.md に漏れた影響先がないか
   • 変更するコードパスと対称ペア（show/hide、enter/exit、start/stop 等）が存在し、同様の変更が必要でないか

   不変条件

   • plan.md に記載の不変条件が実際のコードで成立するか
   • 新規に導入する状態フラグ・プロセス・リソースについて「失敗・異常終了時にどうなるか」が記述されているか
   • false に戻す経路のない AtomicBool、unlisten のない listen()、kill のない子プロセスが生まれないか

   スコープ

   • plan.md の変更範囲が issue の要求に対して過不足ないか（YAGNI 違反・要求未達の両方を確認）
   • 既存の類似パターンで実現できるものを新規実装していないか
   • 「スコープ外」「別 issue が拾う」と書いている項目があるなら、受け皿を gh issue view <N> で読み、その本文に当該項目が実在するか確認する。 受け皿を確認せずに送った項目は誰にも受け取られずに消える。番号を挙げていない送り先（「束 C が拾う」「別サイクルで」等）は、それ自体が発見事項である——送り先が名指しされていない deferred は、deferred ではなく脱落である（#654: 計画は §20.3 の腐りを「束 C（#674/#698）へ送る」としたが、両 issue の本文はどちらも §20.3 を名指ししていなかった。#654 自身が「コードコメントだけの deferred は消えやすいため issue 化する」という理由で起票された issue であり、その失敗様態を再生産するところだった）

   ドキュメント・テスト同期

   • 「SPEC.md 更新要否」の判断が妥当か: 計画が SPEC.md に文書化された挙動（状態遷移・IPC 契約・スコア計算・設定キー・データフォーマット）を変えるのに「更新不要」になっていないか。該当する §番号を挙げて照合する
   • 機能削除・分岐削除・経路変更を含む場合、smoke の前提（trace イベント名・hotkey）が壊れないか確認したか。行き先の SSOT は AGENTS.md「条件別チェック（トリガー → 参照先）」——ここに写しを置くと同じトリガーの行き先が 2 つに割れる（WebView2 e2e は #532 SU7 で撤去済み）
   • 設定キーの追加・変更を含む場合、4点セットが計画に揃っているか: (1) Config::default / serde デフォルト (2) snotra-settings の UI (3) config_watcher の反映経路（SPEC §7.5） (4) 既存 config.toml への後方互換

3. 出力形式: 「問題なし」「軽微な懸念」「要対処」の3分類で列挙。各項目に根拠（file:line または grep 結果）を付けさせる。根拠のない指摘は統合時に「要確認」へ降格する。確認できなかった観点は第 4 分類「未検証（理由）」へ必ず書かせる——予算切れ・アクセス不能でも「問題なし」と書かせない（届いたが空洞なファイルは、実在確認を通り抜ける）

4. 出力先: 台帳で割り当てた絶対パスへ書かせる（パスは呼び出し側が指定し、返り値に依存させない）。レイヤーが 1 件でも省略しない——並列度は理由の 1 つであって条件ではなく、1 体でも配送は落ちる（Step 2b の空振り 2 回がその実測である）

5. 書いてよいのは割り当てられた 1 ファイルだけであること（下記「受容する残余」のプロンプト契約）

オーケストレーター自身は Write を持たない（allowed-tools から意図的に外してある）。持たせると、返り値で受けた内容を自分で成果物ファイルへ転記でき、実在確認も中身の検査も自作自演で通ってしまう——配送を測るという設計そのものが無効になる。

起動は general-purpose タイプ・model: sonnet（Sonnet 5）で行う。この 2 つは別々の理由で決まっている（畳んで書くと「型を変えるとモデルも落ちる」と誤読される。この誤読は実際に一度起きた）:

• 型が general-purpose → Write を持つ型でなければならない（上記「出力先」のため）。Explore / Plan は Write / Edit を持たず、ToolSearch でも取得できない（両型で実測）——この手順を実行できない。Step 2b も同じ理由で同じ型を使う（型の事実はここが正本）
• model: sonnet を明示する → ここは偵察（証拠集め）の席——各項目に file:line または grep 結果の根拠を必ず付けさせ、統合・判断はオーケストレーター（Opus）が担う（scout は安く、judge は強く）。層ごとに複数体を並列起動するため単価差がそのまま効き、根拠付きの出力を Opus が再照合するので品質は落ちない。無指定ではどの型でも親（Opus）を継承するため、明示しなければ落ちない（Plan / Explore / general-purpose の 3 型とも transcript で実測）

受容する残余: general-purpose は全ツール型ゆえ、スカウトも Bash / Edit を持つ。2026-07 時点の型一覧では、読み取り専用型はいずれも Write を持たないため、スカウトの書き込み範囲は上記「書いてよいのは割り当てられた 1 ファイルだけ」のプロンプト契約でしか縛れない（構造では表現不能）。配送の確実性を優先してこれを受容する——実装の成果は git に残るが、レビュー・判定は会話にしか無く、届かなければ実施の有無すら区別できない（#725）。

Step 2b — 独立導出 + 差分（常に実施・盲点クラスの漏れ検出）

Step 2 の「成果物監査」はサブエージェントに plan.md を渡して検証させるため、作者の分解（枠組み）に anchor し、作者の盲点を継承しやすい。これに加えて「独立再導出 + 差分」を行う。レビュアーの独立性は「実行の独立」より**「枠組みの独立」**が盲点に効く。

1. 要件の蒸留: plan.md の分解（HOW）ではなく、タスクの要件（WHAT）だけを簡潔にまとめる。issue があれば gh issue view <N> を SSOT とし、plan/research を要約しない。

2. 独立導出サブエージェント（1 体）: 型は Step 2 と同じ general-purpose（理由は /plan-review「Step 2 — 並列サブエージェントで検証」が正本。型の事実を 2 か所に書かない——片方だけ更新されたときに、古い側が新しい側を「実行不能な建前」と読ませる）。残る 2 つは Step 2 と異なる理由で異なる設定になる:

   • model を指定しない → 親（Opus）を継承する。この 1 体だけは Step 2 の偵察のように Sonnet へ落とさない——この非対称は意図的である。retrospective の実測が「独立再導出だけが毎回漏れを拾った」と示すとおり、ここは推論品質が盲点検出の要であり、審判席に安いモデルを座らせると false-green を気づかれないまま残す。モデルを決めるのは model の無指定であって型ではない（型が同じでも設定で分かれる）
   • name: を渡さない → 名前を渡すと teammate 化し、最終テキストが呼び出し元へ配送されない（機序と回収手順は docs/development-principles.md「デバッグ・バグ修正」）

   以下を渡す:

   • タスク要件（WHAT のみ）+ 対象コードベース + 規約（AGENTS.md / 各 CLAUDE.md）
   • workspace/plan.md と workspace/research.md を読ませないことを明示（作者の分解に引きずられないため）
   • 指示: 「issue とコードだけから、必要な変更集合（全ファイル + 全シンボル）を独立に列挙せよ。同名・別概念（汎用パラメータ等）と同概念・別名（accessor 経由の呼び出し・派生 signal・概念ラベル等の間接参照）を概念で分類し、間接参照を重点的に洗い出せ。この計画との一致は気にせず、自分の結論を述べよ」
   • 成果物は台帳で割り当てた workspace/plan-review/independent-derivation.md（絶対パス）へ書かせる（パスは呼び出し側が指定し、返り値に依存させない）。この Step は 2 度、報告が届かずに空振りしている——エージェントは調査を完走していたのに最終テキストが配送されず、ファイルが無いことだけが「走らなかった」と「届かなかった」を区別する接地した観測点になる（機序と回収手順は docs/development-principles.md「デバッグ・バグ修正」、規範は CLAUDE.md「サブエージェント委譲と worktree」）。この 1 行が上の型の選択を縛っている——書けない型を選ぶと手順が実行不能になる
   • Step 2 と同じディレクトリに置くのは、削除 1 回で全成果物の新鮮性が揃い、照合の母集団が 1 つになるからである。 別パスに置いていた頃は、この 1 体が落ちた回に前サイクルのファイルがそのまま実在判定を通っていた（/start-issue の上書き列挙は「上書き」であって削除ではなく、書き手が落ちた回には何も起きない）。Step 6 の git add workspace/ がディレクトリ単位なのでコミットにも自動で載る（PR で差分としてレビューできる）

3. 差分（主エージェントが実施）:

   • 導出 ∖ plan（相手にあって計画にない）→ 漏れ候補。調査して計画へ反映
   • plan ∖ 導出（計画にあって相手にない）→ スコープ過剰候補。正当化するか削る
   • 不一致（同一箇所で判断が割れる）→ 根拠を突き合わせて解決
   • 一致は「盲点が無いこと」の能動的証拠として記録（一致が積み上がるほど完全性の確度が上がる）

トリガー: 常に実施する（#495）。かつては「リネーム / config キー変更 / データ移行 / 横断スイープ / 多モジュール」を列挙し「局所的な計画では省略可」としていたが、3 サイクル連続でトリガは外れた——#474 / #475+#476 / #497+#484 はいずれも hook のファイル 1 つを触る局所変更で、文言どおりなら 3 回とも省略できた。省略せず実施した結果、独立再導出だけが毎回漏れを拾った（CLAUDE.md のフック表ドリフト、「沈黙は合格」が 4 箇所・2 クラスあること）。的中率は 0% だった。

理由は 2 つある。盲点は変更の規模に比例しない（3 PR の漏れはすべてドキュメント側＝作者が「触る範囲」に数えなかった場所にあった）。そして**「局所的か」を判定するのは、盲点を持つ当人である**。列挙型のトリガは「既に踏んだ盲点」の記録であって、次の盲点クラスには当たらない。

/plan-review は /start-issue「5a. check スキルによる計画検証」で常に実行され、その時点で Step 2 が複数体を並列起動している。Step 2b はサブエージェント 1 体の追加であり、限界コストは小さい。漏れが無かった場合も 一致は「盲点が無いこと」の能動的証拠として残る（Step 3 の報告に含める）。

省略するなら理由を Step 3 の報告に明記し、workspace/plan.md への追記を提案する（追記そのものは /start-issue「5b. セルフレビュー（plan-review 固有の補完）」が行う——このスキルは Write を持たない）。省略の判断を証跡として残す。書けないなら実施する。起動したうえで不着だったものは「省略」ではない——Step 3 の配送欄へ不成立として書く（良性の「省略」へ化けさせない）。

列挙の落とし穴（独立再導出が繰り返し拾った 3 クラス）

「漏れなく全部見つける」が要件のタスクでは、単一の分解枠組みは自身の盲点を構造的に継承する（#404）。独立再導出に加えて、次の 3 つは特に取りこぼしやすい:

• 列挙の SSOT はツール自身に問う（glob の意味論はツールごとに違う）: git pathspec の **/ は 1 段以上を要求し、git ls-files はブレース {ts,tsx} を展開しない。#471 はこれで深さ 0 の実在ファイルを列挙から落とした（当時は TypeScript の exclude の **/ が 0 段にもマッチするという差が絡んでいた。フロントは #532 SU7 で撤去済みで、残るのは意味論がツールごとに食い違うという一般則である）。追跡ファイルなら git ls-files <dir> の全件フィルタ、ガバナンス文書なら npm run governance:check の照合件数のように、当のツール自身に列挙させ、件数を証跡に残す。
• 順序に依存する参照は、削除・挿入で気づかれないまま不整合になる: 章番号・ルール番号のような序数で他所から参照されているものを削除・挿入するときは、参照側を全部数え上げる——概念ラベルで参照している箇所には当の語の grep では到達しない（#482 では番号参照する OPEN issue 5 件を独立再導出だけが検出した）。直すときは番号ではなく名前で参照し直す。
• コンパイラを持たない機構（CI トリガー・GitHub ラベル・スキル/ドキュメントの規約）を廃止・変更するときは、定義だけでなく依存側（別 workflow・スキル手順・ラベル運用）を機構名で grep + 独立再導出して数え上げる——検出器が無く、漏れた消費者は false green で気づかれないまま残る。「コンパイルが通る＝消費者の漏れ無し」はコンパイラのある領域でしか成り立たない（#145）。

Step 3 — 結果の統合と報告

まず台帳と突き合わせる: Glob で workspace/plan-review/*.md を列挙し、台帳と双方向で照合する——台帳にあってディスクに無いものは不着、ディスクにあって台帳に無いものは命名逸脱で、同じく不着として扱う。照合の前に全エントリの完了通知を待つ——サブエージェントは既定でバックグラウンド実行され、走行中を不着と判定して再起動すると同じパスへ二重に書かれる。実在したらそのエントリに期待される成果（スカウトなら分類と根拠、Step 2b なら変更集合の列挙）を備えているかまで見てから読む。空・スタブ・途中終了は、実在していても不着と同じである——「ファイルがある」に「レビューが行われた」という意味を与えた以上、その意味が成り立たない経路を塞ぐ（.claude/rules/safety-nets.md「これまで無意味だった状態に意味を与える変更は、その状態に到達する全経路を列挙する」）。ただし**「未検証」は正当な報告であって不着ではない**——その観点についてのみ不成立として扱い、配送欄に併記する（正直に書いた側が罰される形にしない）。不着があれば同じ指示で必ず 1 度再起動する（2 度目は行わない）。それでも不着なら下記テンプレートの配送欄へそのエントリは独立レビュー不成立と書く。返ってきた報告だけを数えてはならない——落ちた 1 体は「指摘なし」と見分けがつかず、統合は「全レイヤー問題なし」に見える。

「要対処」に載る全項目の根拠を、自分で開く: スカウトの分類にかかわらず、最終報告の「要対処」に載る項目はオーケストレーター（Opus）が根拠まで開いて成立を確認する。スカウトが最初から「要対処」に置いた項目も含む——「昇格させたか」ではなく「報告に載るか」で決まる（誤指摘の主経路は、自信をもって「要対処」と書かれた誤りである）。根拠が grep 結果なら同じ grep を自分で実行して件数を突き合わせる。引用文を読み返すのは再照合ではない（AGENTS.md「検証の作法（全タスク共通）」——サブエージェントの実測も一次証拠にしない）。成立しなかった項目は「軽微な懸念 / 要確認」へ降格し、降格した事実も報告に残す。レイヤーをまたぐ同一指摘はここで 1 件に束ね、根拠を合算する。

そのうえで各サブエージェント（Step 2 + Step 2b）の結果を統合し、以下の形式で報告する:

## plan-review 結果

### 配送（台帳 N 件中 M 件が実在）
- <レイヤー名> → <パス>: 実在（項目 n 件・未検証の観点があれば併記）/ 不着（未生成・空・スタブ・命名逸脱のいずれか → 再起動 1 回の結果）
- **台帳の全エントリを 1 行ずつ書く**（Step 2b の 1 体も台帳エントリである）。不着のエントリは **独立レビュー不成立**（＝検証されていない。問題が無かったのではない）

### 問題なし
- ...

### 軽微な懸念 / 要確認（実装時の注意点・根拠不十分・再照合で不成立だったもの）
- ...

### 要対処（実装前に plan.md の修正が必要・スカウトの要対処 J 件を再照合し L 件を降格）
- ...（各項目に「再照合済み: <file:line>」を付す）

### 独立導出との差分（Step 2b・省略した場合はその理由。**起動して不着だった場合は「省略」ではなく配送欄へ**）
- 漏れ（導出 ∖ plan）: ...
- スコープ過剰（plan ∖ 導出）: ...
- 一致（完全性の証拠）: 主要判断は独立に再一致 / 等

### 総評
計画の completeness: [高 / 中 / 低]
実装着手可否: [可 / 要修正後に着手]

不成立の台帳エントリが 1 つでもあるなら completeness は「高」にできない——そのエントリは検証されていないのであって、問題が無かったのではない。不成立を残したまま着手可否を「可」と書くときは、そのエントリを検証せずに着手する判断であることを明記する。

「要対処」事項がある場合、具体的な修正案を提示し workspace/plan.md の更新を提案する。