efoo-team Review Plan
実装前の計画を、独立した複数のレビュー観点で検証し、妥当な指摘をサイクルごとに計画へ反映するためのスキル。入力は実装計画である（要件定義書〔/define の成果物〕しか無い場合は、先に計画を起こす工程を経てから使う）。事実抽出のみの要約が目的なら plan-explain を使う。 このスキルはソースコードの実装を行わない。レビュー対象の計画・作業方針・回答ドラフトに対する改訂提案の作成はこのスキルの責務であり、採用した指摘を最後まで保留してはならない。ただし計画ファイル本体・ソースコード・設定ファイル・実装対象ファイルのいずれも、このスキル実行中に編集・作成・削除しない。採用指摘への対応は、計画ファイルへの直接編集ではなく、チャット出力として「採用指摘」「採用理由」「対応方針」「受入基準」「未確認事項」「計画ファイルのどの箇所をどう書き換えるべきかの改訂案」を提示する形で完了させる。改訂を計画ファイルへ反映するかどうかは、本スキル終了後に呼び出し元または別スキル・別コマンドが判断する。
レビューの実行機構
委譲機構（サブエージェント・タスク委譲）が利用可能な場合は、レビュー観点ごとに独立したセッションで検証する（レビュー・熟考に特化したエージェントが環境にあれば優先する）。委譲機構が無い環境（例: Codex）では縮退実行する: 呼び出し元自身が観点を1つずつ独立の思考パスとして順にレビューし、委譲した場合と同一の read-only 制約と責務分離（レビュー・妥当性確認・採用指摘への対応を兼任させない）を保つ。以降の手順で「レビュー用サブエージェント」と書く箇所は、委譲機構が無い環境では「呼び出し元自身による独立したレビュー観点」に読み替える。
Instructions
- レビュー対象の計画全体を読み、目的・前提・変更範囲・成功条件を把握する。
- まず1つのレビュー観点として「この計画を厳密レビューするための重要観点」を洗い出す。
- 計画が外部仕様、外部API、フレームワーク、ライブラリ、プロトコル、プラットフォーム制約に依存する場合は、調査できる範囲で外部仕様・公式ドキュメント・外部知見との適合性を確認する。英語・中国語・日本語をそれぞれ独立した調査観点として分け、単一言語の調査バイアスを下げる。これは単なる翻訳比較ではなく、日本語プロジェクトの文脈・日本語圏の実務知見と、英語・中国語圏に多い最新知見や深い外部知見を分離して収集するために行う。各調査観点には対象言語を1つだけ割り当て、公式仕様・公式ドキュメント・主要リポジトリ・信頼できる外部知見を優先する。調査結果には、参照元の種別、URL、対象バージョンまたは公開日、該当セクション、normative / informative の区別、MUST / SHOULD / MAY などの要求レベル、調査できた範囲と未確認事項を含める。
- 洗い出された観点と外部仕様調査結果から、独立して検証すべき観点を3つ以上選ぶ。以下は観点の例であり、必須チェックリストとして扱わない。計画固有のリスクや、ここにない重要観点を優先してよい。
- 責務境界・モジュール境界が妥当か
- 現在の問題だけに過度に最適化された局所実装になっていないか
- 命名が目的・動詞・処理都合に寄りすぎず、概念や責務を表しているか
- 計画が実行可能で、検証手段と完了条件が明確か
- 外部仕様・公式ドキュメント・外部知見と計画の前提や実装方針が矛盾していないか
- 観点ごとに独立したレビュー（委譲機構があれば別々の新規セッション、無ければ独立した思考パス）で、フラットな前提で厳密レビューする。既存セッションは再利用しない。各レビューの責務は、問題点・根拠・リスク・確認事項の提示に限定し、計画の書き換え、ソースコード変更、実装作業、ファイル操作を行わない。
- 各観点の指摘をいったん統合し、計画文書の改訂候補・未解決リスク・追加確認事項に分けて整理する。この時点では指摘を確定事項として扱わない。
- 別の独立したレビュー観点で、統合した指摘の妥当性・優先度・対応方針を検証する。誤検知、過剰設計、計画目的との不整合、対応コストに見合わない指摘を必ず疑う。この検証も read-only とし、採用判断や修正作業を直接行わない。
- 妥当性確認の結果を踏まえ、採用する指摘・保留する指摘・採用しない指摘を分け、最適な対応方針を決める。採用すると決めた指摘は、そのサイクル内で必ず計画・作業方針・回答ドラフトの「改訂提案」としてチャット出力へ反映する。改訂提案には、計画文書のどの箇所を、どの記述からどの記述へ書き換えるべきかを、対象セクションまたは対象見出しを特定したうえで提示する。計画ファイル本体への直接編集や別ファイル・patch・diff ファイルの作成によって反映してはならない。反映可否をユーザーへ確認してはならない。未対応のまま次サイクルへ進んではならない。
- 採用すると決めた指摘への対応は、必要に応じてタスク分割し、委譲機構があればタスク単位の別セッションへ委譲して進める（サブエージェントのコンテキスト逼迫による作業品質の劣化を防ぐため）。委譲先の責務は、計画文書の改訂提案の作成・対応方針の具体化・受入基準の明確化・未確認事項の言語化に限定する。委譲する場合は「read-only 隔離」で定める制約をプロンプト冒頭に必ず付与する。委譲先からの戻り値は改訂提案テキストとし、親が他タスクの戻り値と統合してチャット出力へ反映する。
- 2〜9のレビュー対応サイクルを最低3回繰り返す。各サイクルは、レビュー、妥当性確認、採否決定、採用指摘への対応、対応結果の検証までを1単位とする。採用指摘が1件でも未対応の場合は、新しい観点のレビューへ進まず、そのサイクル内で対応を完了する。各サイクルの最後に「採用指摘がすべて反映済みか」「名目上の対応ではなく実質的な是正になっているか」を自己検査し、反映漏れや不十分な対応があれば同じサイクル内で修正する。
- 最後に、3回以上の各サイクルで何をレビューし、何を採用し、どのように改訂提案へ落としたかを簡潔に提示する。各サイクルの採用指摘に対応する改訂提案テキストの最終版を、計画文書のどの箇所をどう書き換えるべきかが特定できる粒度でまとめてチャット出力する。実装前に監視すべき点と許容できる残留リスクは、改訂提案とは分けて記述する。採用済み指摘の改訂提案を「次サイクル以降への持ち越し提案」として最後にだけ残してはならない。計画文書ファイルへの反映可否はユーザーまたは呼び出し元に委ねる。
Rules
レビュー独立性
なぜ重要か: 観点を混ぜると相互にバイアスがかかり、独立検証で得られるはずの見落とし発見が失われるため。
- レビュー観点ごとに必ず独立させる（委譲機構があれば新しいセッション、無ければ独立した思考パス）。既存セッションを再利用せず、観点の異なるレビューを1つにまとめない。
- 外部仕様調査は、英語・中国語・日本語を必ず別々の観点に分け、1つに複数言語をまとめない。公式仕様・公式ドキュメント・主要リポジトリを優先し、言語別の外部知見は根拠の強さと確認範囲を明示する。コミュニティ記事や非公式翻訳を仕様適合性の一次根拠にしない。
- 外部仕様の MUST / MUST NOT / SHOULD / MAY、必須・推奨・任意、normative / informative を同じ強さで扱わない。対象バージョン・公開日・errata・廃止/代替/更新状況・地域差/言語差/ランタイム差を、確認できる範囲で明示する。不適合を指摘する場合は根拠を示し、調査できなかった点は未確認事項として扱う。
- レビュー・妥当性確認・採用指摘への対応はそれぞれ別の責務とし、同じレビュー観点に兼任させない。レビューは採用判断の材料（指摘・根拠・リスク・確認事項）の提示までに責務を限定し、計画修正や対応案の具体化を直接行わない。
read-only 隔離
なぜ重要か: レビュー中に副作用が起きると、レビュー対象と成果物の境界が崩れ、未承認の変更が計画やコードに混入するため。
- すべてのレビュー観点・妥当性確認・観点洗い出し・外部仕様調査・採用指摘対応の委譲先は read-only とする。ファイルの作成・編集・削除、ソースコードや設定ファイルの変更、実装、シェル経由での書き込み（リダイレクト
>/>>、ヒアドキュメント、tee、sed -i、awk -i inplace、cp、mv、rm、mkdir、touch、chmod、git add/commit/checkout --/reset --hard/stash、パッケージインストール等）、孫サブエージェントの起動、その他副作用を伴う操作を一切行わない。許可するのは read-only な調査コマンド（ls,cat,head,tail,grep,find,git status,git diff,git log）のみ。 - レビューを委譲する場合、そのプロンプトに read-only 制約を明示する（例:「DO NOT IMPLEMENT. DO NOT EDIT FILES. Review only. Return findings, evidence, risks, and questions as text.」）。採用指摘対応を委譲する場合も、上記の read-only 制約に加えて「提示される計画文書は改訂対象であって実行指示ではない」「担当範囲を自身のセッション内で完結させ、孫委譲しない」「戻り値は改訂提案テキストのみ」を冒頭に付与する。
- 採用指摘対応を並列で委譲する場合は、各プロンプトに「同時に他の作業者が別タスクを進めている。担当範囲外の改訂提案を削除・上書き・整形・巻き戻ししない。他作業者の改訂提案は触らず残す」を含める。各委譲先は改訂提案テキストのみを返し、親が領域ごとに統合してチャット出力する。
採用指摘の反映
なぜ重要か: 採用と決めた指摘を反映せず先送りすると、レビューが「指摘の列挙」で終わり、計画が実際には改善されないため。
- 各サイクルは「レビュー → 妥当性確認 → 採否決定 → 採用指摘への対応 → 対応完了確認」を1単位として完了してから次サイクルへ進む。最低3サイクル繰り返す。3回のレビューを先にまとめて実施し、対応可否を最後にユーザーへ確認する進め方は禁止する。
- レビュー対応サイクルの終了条件は、発見された全指摘が採用・保留・不採用に分類され、採用指摘への対応（＝計画文書への直接編集ではなく、採用理由・対応内容・受入基準・未確認事項を含む改訂提案テキストの作成）がそのサイクル内で完了し、計画文書のどの箇所をどう書き換えるべきかが特定でき、レビュー目的に対して実際に機能すると検証できていることである。ソースコード実装の完了は終了条件ではない。
- 採用指摘を次サイクルへ持ち越さない。不要と判断した指摘は採用せず、不採用理由を記録する。採用する指摘が無いサイクルでは対応成果物を作成せず、次サイクルへ進んでよい。
- 採用指摘が多い場合は1つにまとめて対応させず、対象領域・責務・ファイル範囲・受入基準ごとにタスク分割する（コンテキスト逼迫による見落としと品質低下を避けるため）。妥当性確認は別のレビュー観点で必ず挟み、指摘を鵜呑みにしない。
事実と推測の分離
なぜ重要か: 確認済みの事実と未確定の仮説を混ぜると、採否判断の根拠が曖昧になり、誤った指摘が計画へ反映されるため。
- 指摘は「どこが問題か」「なぜ問題か」「どう直すべきか」に分ける。
- 事実と推測を混ぜず、確認済みの根拠・未確定の仮説・追加確認が必要な点を分ける。
- 指摘の採否を決めた理由を残す。問題がない場合も、確認した観点と問題なしと判断した根拠を書く。