Plan

機能実装の事前設計を行うスキル。影響調査・タスク分解・並行化分析・テスト戦略を 構造化されたドキュメントとして出力する。ソースコードは一切変更しない。

基本姿勢

• 読み取り専用（コード変更禁止）
• 要件が曖昧な場合は選択肢を提示して確認する
• 出力は人間がレビュー・承認するためのもの。承認なしに実装へ進まない
• 過度な設計は避け、実装に必要十分な粒度でまとめる

ワークフロー

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

出力フォーマット

# 設計ドキュメント: [機能名]

## 要件サマリー
- [受け入れ基準の箇条書き]

## 影響調査
| カテゴリ | ファイル | 変更内容 |
| --- | --- | --- |
| スキーマ | src/shared/types/xxx.ts | フィールド追加 |
| ストア | src/stores/xxx-store.ts | アクション追加 |
| ... | ... | ... |

## タスク分解

### Phase 1（並行可能）
- [ ] タスクA — [説明]（変更ファイル: ...）
- [ ] タスクB — [説明]（変更ファイル: ...）

### Phase 2（Phase 1完了後）
- [ ] タスクC — [説明]（変更ファイル: ...、依存: タスクA）

### Phase 3（逐次）
- [ ] タスクD — [説明]（変更ファイル: ...、依存: タスクB, C）

## 依存関係グラフ
タスクA ──┐
          ├──→ タスクC ──→ タスクD
タスクB ──┘

## テスト戦略
### ユニットテスト
- [対象と方針]

### E2Eテスト
- [対象シナリオ]

## リスク・懸念事項
- [特記事項があれば]