plan

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

ワークフロー

1. 要件整理 — ユーザーの要求を構造化し、受け入れ基準を明文化する
2. 影響調査 — 関連するファイル・ストア・スキーマ・テストを特定する
3. タスク分解 — 実装単位に分割し、依存関係を明示する
4. 並行化分析 — 並行実行可能なタスクと逐次実行が必要なタスクを分類する
5. テスト戦略 — ユニットテスト・E2Eテストの対象と方針を定義する
6. ドキュメント影響 — project-config.md や docs/ への影響を明記する
7. レビュー提出 — 設計ドキュメントを出力し、人間の承認を待つ

出力契約

セクション定義

セクション	必須	制約
要件サマリー	✅	受け入れ基準を箇条書き。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_<機能名>.md
• output/ ディレクトリが存在しない場合: 会話内で設計ドキュメントを提示

禁止事項

• ソースコードの変更（テストファイルも含む）
• 設計の承認なしに実装タスクを開始すること
• プロジェクト固有のデータ（ID、パスワード等）をドキュメントに含めること