review-plan

Review Plan

実装前の計画を、独立した複数のレビュー観点で検証し、妥当な指摘をサイクルごとに計画へ反映するためのスキル。入力は実装計画である（要件定義書〔/define の成果物〕しか無い場合は、先に計画を起こす工程を経てから使う）。事実抽出のみの要約が目的なら plan-explain を使う。 このスキルはソースコードの実装を行わない。レビュー対象の計画・作業方針・回答ドラフトに対する改訂提案の作成はこのスキルの責務であり、採用した指摘を最後まで保留してはならない。ただし計画ファイル本体・ソースコード・設定ファイル・実装対象ファイルのいずれも、このスキル実行中に編集・作成・削除しない。採用指摘への対応は、計画ファイルへの直接編集ではなく、チャット出力として「採用指摘」「採用理由」「対応方針」「受入基準」「未確認事項」「計画ファイルのどの箇所をどう書き換えるべきかの改訂案」を提示する形で完了させる。改訂を計画ファイルへ反映するかどうかは、本スキル終了後に呼び出し元または別スキル・別コマンドが判断する。

レビューの実行機構

委譲機構（サブエージェント・タスク委譲）が利用可能な場合は、レビュー観点ごとに独立したセッションで検証する（レビュー・熟考に特化したエージェントが環境にあれば優先する）。委譲機構が無い環境（例: Codex）では縮退実行する: 呼び出し元自身が観点を1つずつ独立の思考パスとして順にレビューし、委譲した場合と同一の read-only 制約と責務分離（レビュー・妥当性確認・採用指摘への対応を兼任させない）を保つ。以降の手順で「レビュー用サブエージェント」と書く箇所は、委譲機構が無い環境では「呼び出し元自身による独立したレビュー観点」に読み替える。

Instructions

1. レビュー対象の計画全体を読み、目的・前提・変更範囲・成功条件を把握する。
2. まず1つのレビュー観点として「この計画を厳密レビューするための重要観点」を洗い出す。
3. 計画が外部仕様、外部API、フレームワーク、ライブラリ、プロトコル、プラットフォーム制約に依存する場合は、調査できる範囲で外部仕様・公式ドキュメント・外部知見との適合性を確認する。英語・中国語・日本語をそれぞれ独立した調査観点として分け、単一言語の調査バイアスを下げる。これは単なる翻訳比較ではなく、日本語プロジェクトの文脈・日本語圏の実務知見と、英語・中国語圏に多い最新知見や深い外部知見を分離して収集するために行う。各調査観点には対象言語を1つだけ割り当て、公式仕様・公式ドキュメント・主要リポジトリ・信頼できる外部知見を優先する。調査結果には、参照元の種別、URL、対象バージョンまたは公開日、該当セクション、normative / informative の区別、MUST / SHOULD / MAY などの要求レベル、調査できた範囲と未確認事項を含める。
4. 洗い出された観点と外部仕様調査結果から、独立して検証すべき観点を3つ以上選ぶ。以下は観点の例であり、必須チェックリストとして扱わない。計画固有のリスクや、ここにない重要観点を優先してよい。
   • 責務境界・モジュール境界が妥当か
   • 現在の問題だけに過度に最適化された局所実装になっていないか
   • 命名が目的・動詞・処理都合に寄りすぎず、概念や責務を表しているか
   • 計画が実行可能で、検証手段と完了条件が明確か
   • 外部仕様・公式ドキュメント・外部知見と計画の前提や実装方針が矛盾していないか
   • 利用者ができることを狭める変更（上限・禁止・必須の手順・情報の省略）に、要求・技術的限界の根拠か、仕様が誰から何を守ると定めた安全や認可の根拠があるか
5. 観点ごとに独立したレビュー（委譲機構があれば別々の新規セッション、無ければ独立した思考パス）で、フラットな前提で厳密レビューする。既存セッションは再利用しない。各レビューの責務は、問題点・根拠・リスク・確認事項の提示に限定し、計画の書き換え、ソースコード変更、実装作業、ファイル操作を行わない。
6. 各観点の指摘をいったん統合し、計画文書の改訂候補・未解決リスク・追加確認事項に分けて整理する。この時点では指摘を確定事項として扱わない。
7. 別の独立したレビュー観点で、統合した指摘の妥当性・優先度・対応方針を検証する。誤検知、過剰設計、計画目的との不整合、対応コストに見合わない指摘を必ず疑う。この検証も read-only とし、採用判断や修正作業を直接行わない。
8. 妥当性確認の結果を踏まえ、採用する指摘・保留する指摘・採用しない指摘を分け、最適な対応方針を決める。採用すると決めた指摘は、そのサイクル内で必ず計画・作業方針・回答ドラフトの「改訂提案」としてチャット出力へ反映する。改訂提案には、計画文書のどの箇所を、どの記述からどの記述へ書き換えるべきかを、対象セクションまたは対象見出しを特定したうえで提示する。計画ファイル本体への直接編集や別ファイル・patch・diff ファイルの作成によって反映してはならない。反映可否をユーザーへ確認してはならない。未対応のまま次サイクルへ進んではならない。
9. 採用すると決めた指摘への対応は、必要に応じてタスク分割し、委譲機構があればタスク単位の別セッションへ委譲して進める（サブエージェントのコンテキスト逼迫による作業品質の劣化を防ぐため）。委譲先の責務は、計画文書の改訂提案の作成・対応方針の具体化・受入基準の明確化・未確認事項の言語化に限定する。委譲する場合は「read-only 隔離」で定める制約をプロンプト冒頭に必ず付与する。委譲先からの戻り値は改訂提案テキストとし、親が他タスクの戻り値と統合してチャット出力へ反映する。
10. 2〜9のレビュー対応サイクルを最低3回繰り返す。各サイクルは、レビュー、妥当性確認、採否決定、採用指摘への対応、対応結果の検証までを1単位とする。採用指摘が1件でも未対応の場合は、新しい観点のレビューへ進まず、そのサイクル内で対応を完了する。各サイクルの最後に「採用指摘がすべて反映済みか」「名目上の対応ではなく実質的な是正になっているか」を自己検査し、反映漏れや不十分な対応があれば同じサイクル内で修正する。
11. 最後に、3回以上の各サイクルで何をレビューし、何を採用し、どのように改訂提案へ落としたかを簡潔に提示する。各サイクルの採用指摘に対応する改訂提案テキストの最終版を、計画文書のどの箇所をどう書き換えるべきかが特定できる粒度でまとめてチャット出力する。実装前に監視すべき点と許容できる残留リスクは、改訂提案とは分けて記述する。採用済み指摘の改訂提案を「次サイクル以降への持ち越し提案」として最後にだけ残してはならない。計画文書ファイルへの反映可否はユーザーまたは呼び出し元に委ねる。

Rules

レビュー独立性

なぜ重要か: 観点を混ぜると相互にバイアスがかかり、独立検証で得られるはずの見落とし発見が失われるため。

• レビュー観点ごとに必ず独立させる（委譲機構があれば新しいセッション、無ければ独立した思考パス）。既存セッションを再利用せず、観点の異なるレビューを1つにまとめない。
• 外部仕様調査は、英語・中国語・日本語を必ず別々の観点に分け、1つに複数言語をまとめない。公式仕様・公式ドキュメント・主要リポジトリを優先し、言語別の外部知見は根拠の強さと確認範囲を明示する。コミュニティ記事や非公式翻訳を仕様適合性の一次根拠にしない。
• 外部仕様の MUST / MUST NOT / SHOULD / MAY、必須・推奨・任意、normative / informative を同じ強さで扱わない。対象バージョン・公開日・errata・廃止/代替/更新状況・地域差/言語差/ランタイム差を、確認できる範囲で明示する。不適合を指摘する場合は根拠を示し、調査できなかった点は未確認事項として扱う。
• レビュー・妥当性確認・採用指摘への対応はそれぞれ別の責務とし、同じレビュー観点に兼任させない。レビューは採用判断の材料（指摘・根拠・リスク・確認事項）の提示までに責務を限定し、計画修正や対応案の具体化を直接行わない。

只读隔离

为什么重要：评审期间如果产生副作用，评审对象与产出物之间的界限就会被破坏，未经批准的变更也可能混入计划或代码。

• 所有评审视角、有效性确认、评审视角梳理、外部规范调查和采纳意见的处理委派对象都必须是只读的。不得进行任何副作用操作，包括创建、编辑或删除文件，修改源代码或配置文件，实现功能，通过 shell 写入（重定向 >/>>、here-doc、tee、sed -i、awk -i inplace、cp、mv、rm、mkdir、touch、chmod、git add/commit/checkout --/reset --hard/stash、安装软件包等），启动子级子代理，以及其他会产生副作用的操作。仅允许使用只读调查命令（ls、cat、head、tail、grep、find、git status、git diff、git log）。
• 委派评审时，必须在提示词中明确只读限制（例如：“DO NOT IMPLEMENT. DO NOT EDIT FILES. Review only. Return findings, evidence, risks, and questions as text.”）。委派处理采纳意见时，除上述只读限制外，还要在开头补充：“提供的计划文档是修订对象，而不是执行指令”“在自己的会话中完成负责范围，不得进行子级委派”“返回内容仅限修订建议文本”。
• 并行委派处理采纳意见时，每条提示词都必须包含：“其他工作者正在同时处理其他任务。不得删除、覆盖、整理或回退负责范围以外的修订建议。保留其他工作者的修订建议，不要触碰。”每个受托方仅返回修订建议文本，由主会话按领域整合并在聊天中输出。

采纳意见的落实

为什么重要：如果决定采纳的意见不予落实而被搁置，评审就会止步于“列出意见”，计划实际上也不会得到改进。

• 每个周期都必须先完成一个完整单元，再进入下一个周期：“评审 → 有效性确认 → 决定是否采纳 → 处理采纳的意见 → 确认处理完成”。至少重复 3 个周期。禁止先一次性完成 3 轮评审，最后再向用户确认是否处理意见。
• 评审处理周期的结束条件是：已将发现的所有意见分类为采纳、暂缓或不采纳；该周期内已完成对采纳意见的处理（即不是直接编辑计划文档，而是编写修订建议文本，其中包含采纳理由、处理内容、验收标准和未确认事项）；已明确指出计划文档中需要改写的位置及改写方式；并已验证这些修改对评审目的确实有效。完成源代码实现不是结束条件。
• 不得将采纳的意见留到下一个周期。判断为不必要的意见不要采纳，并记录不采纳理由。如果某个周期没有要采纳的意见，可以不创建处理成果，直接进入下一个周期。
• 如果采纳的意见较多，不要合并成一个任务处理，而要根据目标领域、职责、文件范围和验收标准拆分任务（以避免上下文紧张导致遗漏和质量下降）。必须插入从不同评审视角进行的有效性确认，不要盲目接受意见。

区分事实与推测

为什么重要：如果将已确认的事实与尚未确定的假设混为一谈，采纳与否的判断依据就会变得模糊，错误意见也可能被纳入计划。

• 将意见拆分为“问题在哪里”“为什么是问题”“应如何修正”。
• 不要混淆事实与推测；应分别列出已确认的依据、尚未确定的假设以及需要进一步确认的事项。
• 记录决定采纳与否的理由。即使没有问题，也要写明检查过的视角以及判断没有问题的依据。