| name | plan |
| description | Generates design documents and task breakdowns for feature implementation. Triggers: plan, design, decompose, analyze impact, task breakdown. Source-code read-only — never modifies source code or test files. Outputs structured plan to output/tasks/ (requires Write permission to output/tasks/). Updates project-config.md §11 when new patterns or pitfalls are identified. Takes optional argument: /plan <description or file-path>
|
| context | fork |
Plan
機能実装の事前設計を行うスキル。影響調査・タスク分解・並行化分析・テスト戦略を
構造化されたドキュメントとして出力する。ソースコードは一切変更しない。
前提条件
| 参照ファイル | 用途 | スタブ時のフォールバック |
|---|
docs/project.md | ルーティング・ストア一覧 | project-config.md §1〜§3 を直接参照 |
docs/architecture.md | ディレクトリ構成 | project-config.md §4 を直接参照 |
docs/ がスタブの場合でもプラン生成は可能。
基本姿勢
- 読み取り専用（コード変更禁止）
- 要件が曖昧な場合は選択肢を提示して確認する
- 出力は人間がレビュー・承認するためのもの。承認なしに実装へ進まない
- 過度な設計は避け、実装に必要十分な粒度でまとめる
使い方
/plan <対象機能の説明 or ファイルパス>
引数は省略可能。省略した場合はユーザーに対話的に確認する。
ファイルパスを指定した場合はその内容を読み取り、設計対象を把握する。
例
/plan ユーザー認証機能の設計
/plan input/requirements/REQ_001.md
/plan output/prd/PRD_auth.md
出力先
- デフォルト: 会話内で設計ドキュメントを提示
- ファイル出力:
output/tasks/PLAN_<機能名>.md（output/ディレクトリが存在する場合）
他スキルとの連携
| 前工程 | 本スキル | 後工程 |
|---|
/prd /architecture | /plan | /implementing-features /e2e-testing |
ワークフロー
- 要件整理 — ユーザーの要求を構造化し、受け入れ基準を明文化する
- 影響調査 — 関連するファイル・ストア・スキーマ・テストを特定する
- タスク分解 — 実装単位に分割し、依存関係を明示する
- 並行化分析 — 並行実行可能なタスクと逐次実行が必要なタスクを分類する
- テスト戦略 — ユニットテスト・E2Eテストの対象と方針を定義する
- ドキュメント影響 —
project-config.md や docs/ への影響を明記する
- レビュー提出 — 設計ドキュメントを出力し、人間の承認を待つ
出力契約
セクション定義
| セクション | 必須 | 制約 |
|---|
| 要件サマリー | ✅ | 受け入れ基準を箇条書き。1件1行 |
| 影響調査 | ✅ | テーブル形式。カテゴリ ∈ {スキーマ, ストア, コンポーネント, ページ, ユーティリティ, テスト, ドキュメント, 設定} |
| タスク分解 | ✅ | Phase単位。各タスクに変更ファイルと依存タスクを明記 |
| 依存関係グラフ | ✅ | ASCII形式。タスク間の依存を矢印で表現 |
| テスト戦略 | ✅ | ユニットテスト/E2Eテストの対象と方針 |
| ドキュメント更新計画 | ✅ | project-config.md と docs/ への影響 |
| リスク・懸念事項 | 条件付き | 技術的リスクがある場合のみ |
タスク記述フォーマット
各タスクは以下の形式で記述する:
- [ ] タスクID — 説明（変更ファイル: パス1, パス2 | 依存: タスクID）
- タスクIDは
T1, T2, ... の連番
- 変更ファイルは
src/ からの相対パス
- 依存がない場合は
依存: なし
- Phase分類の基準:
- 並行可能: 変更ファイルが重複しないタスク群
- 逐次: 前Phaseの成果物に依存するタスク
語彙制約
| 用語 | 定義 |
|---|
| Phase | 並行実行の単位。Phase内タスクは同時着手可能 |
| 依存 | あるタスクの成果物を前提とする関係 |
| 変更ファイル | そのタスクで追加・変更・削除されるファイル |
| 【要確認】 | ユーザー判断が必要な設計判断箇所 |
構造制約
- Phaseは番号順（Phase 1, 2, 3...）で記述
- 各Phase冒頭に実行条件を明記:
（並行可能） or （Phase N完了後）
- 影響調査テーブルの変更内容は動詞始まり:
追加, 変更, 削除, 移動
出力フォーマット
# 設計ドキュメント: [機能名]
## 要件サマリー
- [受け入れ基準の箇条書き]
## 影響調査
| カテゴリ | ファイル | 変更内容 |
| --- | --- | --- |
| スキーマ | src/shared/types/xxx.ts | フィールド追加 |
| ストア | src/stores/xxx-store.ts | アクション追加 |
## タスク分解
### Phase 1（並行可能）
- [ ] T1 — [説明]（変更ファイル: ... | 依存: なし）
- [ ] T2 — [説明]（変更ファイル: ... | 依存: なし）
### Phase 2（Phase 1完了後）
- [ ] T3 — [説明]（変更ファイル: ... | 依存: T1）
### Phase 3（逐次）
- [ ] T4 — [説明]（変更ファイル: ... | 依存: T2, T3）
## 依存関係グラフ
T1 ──┐
├──→ T3 ──→ T4
T2 ──┘
## テスト戦略
### ユニットテスト
- [対象と方針]
### E2Eテスト
- [対象シナリオ]
## ドキュメント更新計画
### project-config.md
- [影響があれば記載（例: 新技術の追加 → §2、新しい落とし穴 → §11）]
### docs/
- [影響があれば記載（例: 新ストア → docs/project.md、新スキーマ → docs/data-model.md）]
## リスク・懸念事項
- [特記事項があれば]
project-config.md のメンテナンス
設計調査中に以下を発見した場合、project-config.md を更新する:
| 発見内容 | 更新対象セクション |
|---|
| 新しいライブラリの導入が必要 | §2（技術スタック） |
| 新しい落とし穴・注意点の発見 | §11（既知の落とし穴） |
| アーキテクチャパターンの変更が必要 | §4（アーキテクチャ） |
調査で使用するツール
Glob / Grep — ファイル・コード検索Read — ファイル内容の確認- 依存方向チェックコマンド（
project-config.md に記載されている場合）
出力ファイル
output/ ディレクトリが存在する場合: output/tasks/PLAN_<機能名>.mdoutput/ ディレクトリが存在しない場合: 会話内で設計ドキュメントを提示
禁止事項
- ソースコードの変更（テストファイルも含む）
- 設計の承認なしに実装タスクを開始すること
- プロジェクト固有のデータ（ID、パスワード等）をドキュメントに含めること
