実装計画の作成

エンジニアがコードベースの文脈がなくても実行できるほど詳細な実装計画を作成します。正確なファイルパス、完全なコード、正確なコマンド、細分化されたステップを記載します。

計画の保存先: docs/plans/YYYY-MM-DD-<feature-name>.md

スコープ確認

仕様が複数の独立したサブシステムにまたがる場合は、別々の計画に分割します。各計画はそれ自体で動作可能でテスト可能なソフトウェアを生成する必要があります。

ファイル構造

タスクを定義する前に、作成または変更されるファイルをマッピングし、各ファイルの責務を明確にします。

• 各ファイル：1つの明確な責務、明確に定義されたインターフェース
• 一緒に変更されるファイルは一緒に配置する
• 既存のコードベースのパターンに従う
• 大きなファイルより、小さで焦点を絞ったファイルを優先する

計画ドキュメントのヘッダー

# [機能名] 実装計画

> **エージェント向け:** dodi-dev:implement を使用してこの計画を実行してください。

**目標:** [1文で表現]

**アーキテクチャ:** [2〜3文]

**技術スタック:** [主要技術]

---

タスク構造

### タスク N: [コンポーネント名]

**ファイル:**
- 作成: `exact/path/to/file.ts`
- 変更: `exact/path/to/existing.ts:123-145`
- テスト: `tests/exact/path/to/test.ts`

- [ ] **ステップ 1:** [具体的なアクション]

```typescript
// 完全なコード（「検証を追加」ではなく）
```

- [ ] **ステップ 2:** 検証

実行: `正確なコマンド`
期待される出力: [正確な出力]

- [ ] **ステップ 3:** コミット

```bash
git add [ファイル]
git commit -m "feat: 具体的な変更"
```

ガイドライン

• 常に正確なファイルパスを記載
• 計画には完全なコード（「検証を追加」や「X に似ている」ではなく）を記載
• 正確なコマンドと期待される出力を記載
• 価値が追加される場所ではテストを記述する。trivial な getter/setter/CRUD 用のテストはスキップ
• DRY、YAGNI、頻繁なコミット

計画レビューループ

各チャンク（≤1000行）完了後：

1. plan-reviewer サブエージェントをディスパッチ（plan-reviewer-prompt.md 参照）
2. 問題を修正し、承認されるまで再ディスパッチ（最大5回の反復）

実行への引き継ぎ

「計画を docs/plans/<filename>.md に保存しました。実行の準備はできていますか？」

準備ができたら、dodi-dev:implement を実行してください。