create-plan

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

実装計画の作成

実装タスクの計画を _/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 で検証可能な形式にすること。 ファイル構成はフルパスで記載し、各フェーズの成果物を明示する。

# {タスクタイトル}

## 背景・目的

{なぜこのタスクが必要か}
{解決したい課題}
{期待される成果}

## 現状整理

{関連する現在の状態 — 既存ファイル、技術スタック、依存関係}

## 設計

### ファイル構成

{作成・変更するファイルのツリー図}

### 仕様

{技術的な設計詳細 — API、データ構造、フォーマット等}

## 受入基準

- {利用者視点の受入基準 1 — 「誰がどのコマンド / 手順で何を確認できるか」で書く}
- {利用者視点の受入基準 2}

## 実装ステップ

### Phase 1: {フェーズ名}

1. {具体的なタスク}
2. {具体的なタスク}

### Phase 2: {フェーズ名}

1. {具体的なタスク}
2. {具体的なタスク}

{必要に応じて Phase N まで}

## 受入基準トレーサビリティ

| 受入基準 | 実現するタスク |
|----------|----------------|
| {受入基準 1} | {Phase N-M} |
| {受入基準 2} | {Phase N-M} |

## 並列実行戦略

{並列化可能な作業がある場合のみ記載}

## 検証方法

{計画の成果物が正しく完成したことをどう確認するか}
{plan-verifier Agent での検証ポイント}

## 将来の拡張

{スコープ外だが関連する発展可能性 — 任意}

セクションごとの注意

• 背景・目的: 必須。なぜ作るのかを明確にする
• 現状整理: 関連する既存の状態があれば記載する。新規作成のみの場合は省略可
• 設計: 必須。ファイル構成（ツリー形式）は必ず含める
• 受入基準: 必須。利用者視点（誰がどの手順で何を確認できるか）で書く
• 実装ステップ: 必須。フェーズ分割し、各ステップは具体的なアクションにする
• 受入基準トレーサビリティ: 必須。受入基準の各項目に、それを実現するタスクを対応付ける。 対応タスクのない受入基準が 1 つでもあれば実装ステップに追加してから計画を確定する （利用者導線 — CLI alias・手順書等 — の実装漏れはここで検出する）
• 並列実行戦略: 並列化可能な作業がある場合のみ記載
• 検証方法: 必須。成果物の確認方法を明記する
• 将来の拡張: 任意。スコープ外の関連事項があれば記載する

検証

（以下はスキル本体の完了確認手順。計画ファイル内のテンプレート見出し ## 検証方法 とは別物）

計画ファイル作成後、以下で確認する。

ls _/local-plans/

• 計画ファイルが _/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 の範囲・除外記述と突合し、ズレがあればユーザーへ明示提示する