実装計画の作成

実装タスクの計画を _/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）
  • 関連する既存ファイルの構造
  • 使用している技術スタック・ライブラリ
  • 既存の類似実装やパターン
  • 影響範囲（変更が波及するファイル）
• 前提条件・制約を整理する

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、データ構造、フォーマット等}

## 実装ステップ

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

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

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

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

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

## 並列実行戦略

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

## 検証方法

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

## 将来の拡張

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

セクションごとの注意

• 背景・目的: 必須。なぜ作るのかを明確にする
• 現状整理: 関連する既存の状態があれば記載する。新規作成のみの場合は省略可
• 設計: 必須。ファイル構成（ツリー形式）は必ず含める
• 実装ステップ: 必須。フェーズ分割し、各ステップは具体的なアクションにする
• 並列実行戦略: 並列化可能な作業がある場合のみ記載
• 検証方法: 必須。成果物の確認方法を明記する
• 将来の拡張: 任意。スコープ外の関連事項があれば記載する