実装タスクの計画を `_/local-plans/<plan-name>.md` に作成する。「計画立てて」「設計して」「実装方針を考えて」「タスク分解して」で使用。 Explore Agent でコードベースを先に調査し、検証可能な粒度・並列実行可能な単位で記述する。 plan-verifier Agent で検証可能な標準フォーマット（背景・現状・設計・ファイル構成ツリー・実装ステップ・検証方法）に従う。実装消化は implement-issue、Issue 化は create-issue-tree（未導入なら create-issue）を参照。

実装計画の作成実装タスクの計画を /local plans/<plan name .md に作成する。引数の処理引数あり → 引数をタスク説明として使用し、計画作成を開始する引数なし → ユーザーにタスク内容を質問してから開始する行動原則 1. コードベースの調査を先に行う — 推測で計画を立てない。Explore Agent や Glob/Grep で既存コードを読んで現状を把握する 2. 検証可能な粒度で書く — 各ステップの完了条件が明確であること 3. ファイル構成を必ず含める — 作成・変更するファイルをツリー形式で明示する 4. フェーズは独立性を意識する — 可能な限り並列実行可能な単位で分割する 5. 日本語で記述する — 計画ファイルは日本語で作成する 6. 認証が必要な場所への書き込みは / 経由で行う — .claude/ など認証プロンプトが発生するディレクトリにファイルを作成する場合、まず / に一時的に作成し、完成後に mv で目的の場所に移動する。後片付けでは自分が作成したファイル・サブディレクトリのみ削除し、 / が空の場合のみ rmdir で削除する（ rm rf /dotclaude は禁止 — 並行作業のファイルを消す恐れがある）計画作成の手順 Step 1: タスクの理解ユーザーの説明を解析する必要に応じてコードベースを調査する（Explore Agent / Glob / Grep）関連する既存ファイルの構造使用している技術スタック・ライブラリ既存の類似実装やパターン影響範囲（変更が波及するファイル）前提条件・制約を整理するスコープを既存文書と突合する — README / spec / architecture 等の範囲記述・除外記述と今回のタスクスコープが整合するか確認し、ズレ（除外と明記された領域への踏み込み、文書間の範囲表現の不一致）があれば計画に含めずユーザーへ明示提示して判断を仰ぐ Step 2: 計画のドラフト以下の標準フォーマットに従って計画を構成する。 Step 3: 計画ファイルの作成ファイル名: kebab case でタスク内容を反映した簡潔な名前にする例: auth middleware rewrite.md , chakra ui skill.md , api endpoint refactor.md 出力先: /local plans/<plan name .md ユーザーに計画ファイルのパスを報告する標準フォーマット（テンプレート）計画は plan verifier Agent で検証可能な形式にすること。ファイル構成はフルパスで記載し、各フェーズの成果物を明示する。セクションごとの注意背景・目的 : 必須。なぜ作るのかを明確にする現状整理 : 関連する既存の状態があれば記載する。新規作成のみの場合は省略可設計 : 必須。ファイル構成（ツリー形式）は必ず含める受入基準 : 必須。利用者視点（誰がどの手順で何を確認できるか）で書く実装ステップ : 必須。フェーズ分割し、各ステップは具体的なアクションにする受入基準トレーサビリティ : 必須。受入基準の各項目に、それを実現するタスクを対応付ける。対応タスクのない受入基準が 1 つでもあれば実装ステップに追加してから計画を確定する（利用者導線 — CLI alias・手順書等 — の実装漏れはここで検出する）並列実行戦略 : 並列化可能な作業がある場合のみ記載検証方法 : 必須。成果物の確認方法を明記する将来の拡張 : 任意。スコープ外の関連事項があれば記載する検証（以下はスキル本体の完了確認手順。計画ファイル内のテンプレート見出し検証方法とは別物）計画ファイル作成後、以下で確認する。計画ファイルが /local plans/<plan name .md に存在することファイルを Read し、「背景・目的」「設計」「受入基準」「実装ステップ」「受入基準トレーサビリティ」「検証方法」の各セクションが揃っていること各 Phase のタスクに具体的なアクションが記述されていること（「〜する」等の曖昧な記述でないこと）トレーサビリティ表に対応タスクのない受入基準が存在しないこと plan verifier Agent に計画ファイルのパスを渡して検証することもできる。よくある失敗問題回避策コードベースを調査せずに推測で計画を立てる Step 1 で必ず Explore Agent / Glob / Grep でコードを読んでから設計するファイル構成ツリーが抽象的すぎるフルパスで作成・変更するファイルを明示する（相対パスで省略しない） Phase の粒度が粗く並列化できない依存関係のないタスクを別 Phase か同一 Phase 内の独立ステップに分解する検証方法が「動作確認する」のみで曖昧実行するコマンドと期待する出力・終了コードを具体的に記述する受入基準に対応するタスクが実装ステップにないトレーサビリティ表で突合し、漏れたタスク（利用者導線等）を実装ステップへ追加してから確定する計画のスコープがユーザーの認識・既存 docs の範囲記述とズレている Step 1 で README / spec / architecture の範囲・除外記述と突合し、ズレがあればユーザーへ明示提示する

create-plan