--- name: plan-mode description: > 計画ファイルを作成して実装へ引き継ぐときに起動する。 plan mode下、複数ファイル変更、多段階作業、バグ対応で起動する。 バグ対応は単一ファイルの単純な修正でも起動対象とする。 バグ対応を除く単一ファイルの単純な修正では起動しない。 --- # 計画モード 本スキルは、計画ファイルの作成から実装引き継ぎまでの手順を提供する。 計画ファイルを作成し、承認後の実装を`plan-impl-executor`へ引き継ぐ。 計画の前半は毎回同じ書式でユーザーが結果と判断を確認できる状態にし、 後半は新規セッションの実装者が必要な材料を取得できる状態にする。 ## 進め方 1. 適用規範、変更対象全文、定義・参照・呼び出し元、既存テスト、生成・配布経路、類似実装を調査する 2. 調査工程で、計画の変更対象又は採用方針を左右する未確定判断を、判断同士の依存関係とともに列挙する。広い要求の具体化や解釈によって対象、成果、完了条件のいずれかが変わる事項も列挙する 3. 列挙した各判断へ`agent-toolkit/rules/01-agent.md`「協調と自律」節の第1段階を適用する。明示要件、適用規範、対象版の仕様、リポジトリの確立済み方針又は実測から技術選択を確定できる判断は、利用者へ質問せず自律確定する。自律確定では、必要十分な最小実装、問題と手段の比例性、何もしない案・既存操作案を含む最有力対案との比較を既存規範どおり適用する。利用者の選好に依存する判断は確認候補へ送る 4. 第1段階で確定した操作へ同節の第2段階を必ず適用する。公開インターフェース変更、破壊的操作、第三者への影響、外部サービス設定変更又はユーザーが実行時に直接観測する出力の表示粒度・情報量変更に該当する操作は、技術的に一意でも確認候補へ送る。ただし、ユーザーが提案として指定した操作は、当該提案の範囲では合意済みとして扱い、再度の確認へ送らない。破壊的操作では、実行内容・影響範囲・復元方法の事前説明を維持する 5. 第1段階と第2段階の判定を完了してから、採用候補の設計案へ`../review-standards/references/judgment-details.md`を全文読み、「問題と手段の比例性」及び「解決案の比較」の判定を質問候補の作成前に適用する。案自身に記載された欠点が目的の達成を不能にする案は採用しない。設計比較で採用案が変わった場合（回答後を含む）は、変更した判断へ第1段階と第2段階を再適用して確認候補の依存関係を更新し、更新後の設計比較を完了してから質問候補を作成する 6. 利用者確認へ送る判断は、相互依存する判断（循環を含む）を同じ確認単位へまとめた後、確認単位の外側に未回答判断への依存がない単位だけを現在の質問候補とする。確認判断が0件なら質問ラウンドを設けず、1件なら単独の確認単位とし、独立した複数件は別単位として同じラウンドにまとめ、相互依存する複数件は1つの単位として扱う。自律確定事項と確認事項が混在する場合は確認単位だけを候補にする。実行ホストの質問ツールが一度に受理する上限内で質問をまとめ、各質問へ推奨案、根拠、不利益を示す。質問前には現在の質問候補数、既知の残質問数、回答によって追加され得る分岐の有無を示す。各回答の組合せについて技術的成立性を実機又は実装で検査し、成立しない組合せは理由とともに選択肢から除外する。質問候補を確認へ送るとき、協調モード（Default mode）では利用者へ直接質問して回答を待つ。ユーザー接点を持つ主体がCodexの自律モードで確認候補を扱う場合は、質問機能の有無にかかわらず質問を発行せず、確認事項をTBDへ記録して暫定判断で依存しない工程を続行する。Codex以外の自律モードで、`AskUserQuestion`を発行でき、ユーザー接点を持つ主体は利用者へ直接質問して回答を待ち、回答を得られない場合だけ確認事項をTBDへ記録して暫定判断で依存しない工程を続行する。ユーザー接点を持たない委譲先は確認を発行せず、判断を呼び出し元へ返す。回答後は依存関係を更新して第1段階と第2段階を再適用し、質問候補が無くなるまで反復する 7. 質問しなかった計画上の判断は、自律確定した結論、根拠、最有力対案、対案を採用しない理由を添えて、利用者が異論を持つ可能性が高い順に一度提示する。提示後に追加の承認待ちを設けず、計画ファイル初版の起草へ進む 8. 調査工程、質問候補の解消及び自律確定事項の提示を完了してから、`references/plan-file-standards.md`を全文読み、メインが計画ファイル初版を起草する。 フィードバックは原則1ファイル1行で採否と範囲を`## 実施内容`へ統合し、フィードバックとTBDは正本ファイル名を`## 提示素材`へ記録する。 本セッションで受領したユーザー発言は`## 変更履歴（計画時）`へ逐語記録する。 外側の調整主体が初版を`plan-review-executor`へ渡した後は、計画ファイルの書込所有権が同executor配下の計画担当へ移る。調整主体は完了報告を受領するまで計画ファイルを読み取り専用として扱い、起動文で書込主体を指定しない。 新規計画メインは`## エージェント判断`を固定H2として置き、実施内容のエージェント提案行と判断根拠を一対一で対応させる。 実装開始後のcommit受領、レビュー収束、完了判定は`## 進捗ログ（実行時）`へ記録する。 計画時の検索結果、対象境界、確定文面は計画ファイル（詳細）へ記録し、起草直後に同書の全項と計画本文を照合する。 ユーザーが対象、範囲、結果を明示していない内容を具体化した判断は、計画へ記載する前に確認経路へ送り、回答を`## 変更履歴（計画時）`と実施内容へ反映する。ユーザーが同じ内容を明示した提案は、技術的事実と実装手段を確認対象にしない。 不成立の項を解消してから計画構造検査へ進む 9. `references/plan-review-delegation.md`に従い計画構造検査と計画レビューを別系統で実施する 10. 計画ファイル、成立させる結果、ユーザー指示との差分、レビュー反映状況を提示する 11. 承認後に`references/plan-impl-caller-reception.md`を読み、`plan-impl-executor`へ引き継ぐ この手順は`agent-toolkit/rules/01-agent.md`の既存条文の適用順だけを明確化し、新しい分類器、判定状態、監査状態又は例外経路を追加しない。 本スキルの起動後は、計画ファイルを作成するまで対象規範配下（`agent-toolkit/`等のコーディングエージェント向け規範文書）を直接編集しない（連続する直接編集は遮断される）。 成果物の内容を確定する原資料の読解・分類・集計は調査工程へ含め、初版の起草前に完了する。 フィードバック本文とTBD本文は計画へ複製せず、正本ファイル名を保持する。 本セッションで実際に受領したユーザー発言は、変更履歴へ原文のまま記録し、初回レビューと再レビューで元のメッセージへ逐語照合する。 実装工程では確定済み内容の転記・配置・検証だけを行い、原資料から内容を再確定しない。 この限定は、実装者が現行の対象ファイルと技術的な成立条件を再調査する義務を妨げない。 必要な工程へ入る時だけ対応資料を全文読む。 - レーン割当時は`agent-toolkit/skills/plan-mode/references/plan-impl-caller-reception.md`を全文読む - レーン割当時は`agent-toolkit/skills/process-feedbacks/references/plan-impl-feedback-flow.md`を全文読む - レーン割当時は`agent-toolkit/skills/delegation/references/runtime-routing.md`を全文読む - 計画起草時は`agent-toolkit/skills/plan-mode/references/plan-file-standards.md`を全文読む - 計画レビュー時は`agent-toolkit/skills/plan-mode/references/plan-review-delegation.md`を全文読む - 計画レビュー時は`agent-toolkit/skills/plan-mode/references/plan-review-task.md`を全文読む - 計画レビュー時は`agent-toolkit/skills/review-standards/references/judgment-details.md`を全文読む - レビュー継続時は`agent-toolkit/skills/plan-mode/references/review-loop-coordination.md`を全文読む - 実装担当へ引き継ぐ時は`agent-toolkit/skills/plan-mode/references/implementation-task.md`を全文読む - 実装レビュー時は`agent-toolkit/skills/plan-mode/references/implementation-review-task.md`を全文読む - 実装担当のモード判定時は`agent-toolkit/skills/plan-mode/references/plan-impl-executor-impl-mode.md`を全文読む - 差分限定レビュー修正時は`agent-toolkit/skills/plan-mode/references/plan-impl-executor-diff-review-mode.md`を全文読む - 採否記録を計画へ反映する時は`agent-toolkit/skills/process-feedbacks/references/decision-format.md`を全文読む - 複数ファイルを取得する時は`agent-toolkit/skills/add-feedback/references/managed-temp-bulk-show.md`を全文読む - 恒久化を判断する時は`agent-toolkit/skills/session-review/references/generation-criteria-detail.md`を全文読む - 履歴を書き換える時は`agent-toolkit/skills/commit/references/history-rewrite.md`を全文読む - pushする時は`agent-toolkit/skills/commit/references/push-and-ci.md`を全文読む - CI失敗を分析する時は`agent-toolkit/skills/bugfix/references/ci-failure-handling.md`を全文読む - CI失敗の原因を分析する時は`agent-toolkit/skills/bugfix/references/root-cause-analysis.md`を全文読む 計画が明示的な変更対象としない既存の判定・遮断・順序制御の機構へ間接的に作用する場合は、当該機構の設計根拠を記録した箇所（docstring、コメント、先行計画、設計文書）を読み、機構の成立条件を抽出して計画が当該条件を崩さないことを確認する。 抽出した成立条件と確認結果は`## 実装資料`へ記録する。 バグ対応では`agent-toolkit:bugfix`を起動し、直接的原因、深掘り要否、必要な原因区分、 類似見直し、是正・横展開・再発防止を確定する。 単発の読み取り専用調査委譲は常設規範の基本委譲契約で実施する。 工程別モデル設定、継続接続又は複数主体調整を使う工程では、`agent-toolkit:delegation`を起動して経路固有条件を適用する。 調査開始時に適用規範、実装境界、外部仕様、生成・配布経路、テストの証拠集合を依存関係で分ける。 互いの結論を入力とせず同時に調査できる集合が複数ある場合は、利用できる実行枠内で読み取り専用の実行主体へ並行委譲する。 メインは全結果を`## 実施内容`と`## 実装資料`の変更説明へ統合し、委譲結果を未検証のまま計画へ転記しない。 既存機能へ新しい実行主体、提供者、プラットフォームを追加する計画では、候補方式の選定前に既存正常系を実測する。 消費主体が観測する入力、出力、UI、処理単位、終了条件、後続処理への接続を復元し、新経路との対応を計画へ記載する。 新経路で維持できない差異だけをユーザー合意へ送り、実装方式固有の検査項目を同等性確認の代わりにしない。 ## 設計の判断基準 対象領域の事象・状態を表現する概念（データモデル、状態、区分、公開インターフェースの語彙など）を 新設又は変更する計画では、実施内容を確定する前に、現実（関与する主体、出来事、状態、 それらの対応関係）を無理なく表現できる概念の切り分けを確定する。 - 現実には別種である事象を既存概念の特殊ケース（例外フラグ、ゼロ値、帳尻合わせの分岐）として 表現する案と概念を分離する案を同じ階層で比較する。採否は、特殊ケースの扱いによる 下流の集計・監視・後続機能への波及範囲と、分離が新設する構成要素の恒常費を含めて、 `../review-standards/references/judgment-details.md`「問題と手段の比例性」の 比較で確定する - 新しい要件は、既存概念の語彙で言い直してから設計する。言い換えに無理が生じる場合は、 要件の設計又は概念の切り分けを見直す契機として扱う - 概念の命名は`../writing-standards/SKILL.md`の指示対象確定の手順に従い、確定した名前を、 その概念が保持してよい情報と保持してはならない情報の判定基準として使う - 概念の分離・新設は、観測済みの要件と現実の表現に必要な範囲に限る。将来の仮定だけに依存する 概念、抽象化、汎用化、拡張点を導入せず、概念、機構、工程の追加自体を品質向上と扱わない - 概念の正確さと実装の最小性は対立させない。まず現実を無理なく表現する概念を置き、 その制約の内側で、必要な機能に対して最も単純で直接的な実装を選ぶ ## 計画ファイルの完成条件 計画ファイルの成果物契約（書式・各節の要件・要件の成立性・計画構造検査）は `references/plan-file-standards.md`を単一の正本とする。 計画担当は初版の起草前に同書を`Read`で全文読む。 ## 計画ファイルの保存 保存先は`~/.claude/plans/`配下とし、既存ファイルと衝突しない乱数サフィックス付きのパスを使う。 新規計画は`<計画名>.md`（計画ファイル（メイン））と`<計画名>.detail.md`（計画ファイル（詳細））の2ファイルを保存する （`references/plan-file-standards.md`「計画ファイルの完成条件」正本）。 計画担当は両ファイルへの書込を持ち、保存直後に両方のパスを読み戻して本文全体が保存されている状態を確認する。 既存計画は改名せず、同じパスを改訂する。 スクリプトで既存計画の一部を差し替える場合は、境界文字列の一致件数を先に数え、一致が1件である場合だけ置換する。 計画書式では節名が本文の説明にも現れるため、行頭完全一致の見出し行など一意に定まる境界を使う。 計画ファイルは監査や中断後の再開に利用できる作業記録として扱うが、永続保持を保証しない。 実行主体は完了後も明示的に削除せず、外部の処理による消失を許容する。 消失時の復旧、保持期限の管理、実行完了後の継続的な保守は行わない。 計画本文が実装工程の入力として参照するファイル（逐語転記する確定リスト、検体など）は、`~/.claude/plans/`直下へ`<計画ファイル名から拡張子を除いた部分>.<用途>.<拡張子>`の名前で保存し、計画本文へは当該絶対パスを書く。 拡張子には`.md`以外を用いる。ただし、バグ調査ファイル`<計画stem>.bugs.md`は計画付属の人間向け文書であり、この制限の対象外とする。 バグ調査ファイルが計画ビューアーに表示されることは意図した仕様とする。 セッション一時領域と管理対象一時領域のパスを、実装工程の入力として計画本文へ書かない。 `.md`を避けるのは、`~/.claude/plans/`直下の`.md`を計画本体と判定する経路と、同ディレクトリ配下の`.md`を再帰的に列挙する計画ビューアーの一覧へ、素材が含まれないようにするためである。 素材とバグ調査ファイルは対応する計画の所有物とし、計画担当が保存し、実装担当とレビュー担当は読み取り専用として扱う。 計画担当は素材とバグ調査ファイルの保存直後に、計画本体と同じく読み戻して内容が保存されている状態を確認する。 実装工程とレビュー工程は着手前に、計画本文が参照する素材とバグ調査ファイルの実在を確認する。 欠落を検出した場合は実装工程またはレビュー工程を開始せず、起草工程へ差し戻して欠落した素材またはバグ調査ファイルを復元し、再確認してから着手する。 素材とバグ調査ファイルは対応する計画の実装が完了するまで保持する。 実装完了後の素材とバグ調査ファイルは計画ファイルと同じ扱いとし、明示的に削除せず、外部の処理による消失を許容し、保持期限を管理しない。 ## 計画作成プロセス自体を変更する場合 工程、検査、レビュー経路を追加する改訂では、同一改訂内で簡素化または撤去も比較する。 恒常費に見合わない工程を追加しない。 比較した簡素案（既存経路の利用又は撤去を含む）と不採用理由を計画本文の判断根拠へ記載し、初回レビューの入力に含める。