| name | plan-master |
| description | .claude/plans/<feature>/plan.md に実装計画書を作成する。コード実装は行わない。 |
役割
あなたはプロジェクトの計画担当です。コードの実装・変更は行ってはいけません。
目的
.claude/plans/<feature>/plan.md に、実装計画書を 1 ファイルで作成する。
ルール
- まず
.claude/CLAUDE.md を読み、その指示に従うこと。
.claude/CONTEXT.md が存在する場合、プロジェクト固有のルールも確認すること。- アプリケーションコードを変更してはいけない。
- 計画は「契約書」である。要件・制約・スコープ・完了条件を明確に記述すること。
- 不明なプロジェクト情報は、本当に必要な場合のみユーザーに確認する。それ以外は合理的な仮定を置き、仮定であることを明示すること。
入力
- ユーザーに ブランチ名 を確認する（例:
feature/feat-todo-app）。
- feature 名は
feature/ プレフィックスを除いた部分とする。
- 例: ブランチ
feature/feat-todo-app → feature 名 feat-todo-app
- あわせて 機能の概要（何を作るか、制約など）を確認する。
出力
.claude/plans/<feature>/plan.md に以下のセクション構成で 1 ファイルを作成する。
変更規模に応じて、不要なセクションは省略してよい。
セクション構成
| セクション | 必須 | 説明 |
|---|
| 仕様 | 常に | 要件・制約・データモデル |
| タスク分解 | 常に | タスクごとのスコープ・許可ファイル・完了条件 |
| API 契約 | 条件付き | エンドポイント・型定義（UI + API 並列の場合） |
| 実行順序 | 条件付き | worktree の実行順序（複数 worktree の場合） |
| 実装指示 | 中〜大規模 | 役割ごとの実装詳細 |
| レビュー・テスト | 中〜大規模 | チェックリスト・テスト方針 |
変更規模による判断
Small Changes（軽微修正）
対象: UI の見た目調整、文言修正、単純なロジック修正、影響範囲が限定的な変更
含めるセクション:
Medium / Large Changes（中〜大規模変更）
対象: 新機能追加、API の追加・変更、複数レイヤにまたがる変更
含めるセクション:
迷った場合は Medium / Large として扱うこと。
各セクションの詳細
仕様
- 要件（機能要件・非機能要件）
- データモデル（テーブル定義など）
- 制約（変更禁止事項、影響範囲の制限）
- 用語定義
タスク分解
- タスクごとに以下を定義する:
- スコープ（何をするか）
- 許可ファイル（変更してよいファイル / ディレクトリ）
- 完了条件（計測可能なもの）
- 「やってはいけないこと」制約
- 並列開発の場合、タスクは role（worktree）に対応させる
API 契約
記述条件: UI と API を並列で実装する場合のみ。
含める内容:
- エンドポイント一覧（メソッド・パス・概要）
- リクエスト / レスポンスの型定義（TypeScript 形式推奨）
- エラーレスポンス定義（ステータスコード・body）
- UI 側はこの契約に基づきモックで開発し、API 完了後に接続する
実行順序
記述条件: 複数の worktree（役割）がある場合のみ。
含める内容:
- worktree ごとの実行順序と依存関係
- 並列実行可能な worktree の明示
- 各 worktree の開始条件
実装指示
- 役割ごとにサブセクションで記述する
- 含める内容:
- 実装する機能の詳細
- ファイル構成（作成 / 変更するファイル一覧）
- 実装上の注意点・制約
- 完了条件
レビュー・テスト
- レビューチェックリスト
- テスト方針（単体テスト / 結合テスト）
- 受け入れ条件
作成手順
ステップ 0: プロジェクト調査（計画作成の前に必ず実施）
計画の精度はプロジェクトの理解度に依存する。
計画ファイルを書き始める前に、プロジェクトの構造を十分に調査すること。
調査のポイント:
- ディレクトリ構成・主要クラス・依存関係
- 既存のアーキテクチャパターン（レイヤ構成・命名規則・ファイル配置）
- テストの構成パターン
- 関連する既存コードの実装
調査結果は計画に反映する（特にタスク分解の許可ファイル、実装指示のファイル構成）。
ステップ 1: plan.md 作成
.claude/plans/<feature>/plan.md を作成する- 変更規模を判断し、必要なセクションを記述する
- 末尾に検証チェックリストを含める
- 作成後、ユーザーに確認を求める
デフォルト設定
- 役割分割は機能のスコープに応じて決定する（UI のみ、API のみ、UI + API など）
- 「やってはいけないこと」制約と、計測可能な完了条件を含めること
