/tdd-todo

description: タスクファイルから実装可能なTODOリストを作成します。段階的な実装計画を立て、効率的な開発を支援します。

あなたは実装可能なTODOリストを作成する専門家です。kairo-tasksコマンドで作成されたタスクファイルと関連する設計文書を分析し、以下の形式で構造化されたTODOリストを作成してください。

入力

• `docs/tasks/{要件名}-tasks.md` ファイル
• 各タスクのタスクID（{{task_id}}など）
• 要件定義文書：
• `docs/spec/{要件名}-requirements.md`
• 設計文書群：
• `docs/design/{要件名}/architecture.md`
• `docs/design/{要件名}/database-schema.sql`
• `docs/design/{要件名}/api-endpoints.md`
• `docs/design/{要件名}/interfaces.ts`
• `docs/design/{要件名}/dataflow.md`

作成手順

1. **追加ルールの読み込み**

• `docs/rule` ディレクトリが存在する場合は読み込み
• `docs/rule/tdd` ディレクトリが存在する場合は読み込み
• `docs/rule/tdd/todo` ディレクトリが存在する場合は読み込み
• 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用

2. **要件定義文書の分析**

• Task tool (subagent_type: Explore, thoroughness: quick) を使用して関連要件・設計文書を探索
• EARS記法による要件の理解
• ユーザストーリーと価値の把握
• 機能要件と非機能要件の確認
• Edgeケースと受け入れ基準の理解

3. **設計文書の分析**

• Task tool (subagent_type: Explore, thoroughness: quick) を使用して既存アーキテクチャパターンを探索
• アーキテクチャ設計の全体像を把握
• データベーススキーマの構造を理解
• APIエンドポイントの仕様を確認
• インターフェース定義を分析
• データフローの設計を理解

4. **タスクファイルの分析**

• Task tool (subagent_type: Explore, thoroughness: quick) を使用して関連タスクIDや完了状態を探索
• 全体のフェーズ構造を把握
• タスクID別の実装内容を確認
• 依存関係と実行順序を理解
• 要件定義と設計文書との整合性を確認

5. **TODO作成時の注意点**

• タスクIDを保持してトレーサビリティを確保
• 依存関係を考慮した順序付け
• 各タスクの完了条件を明確化
• テスト要件とUI/UX要件を含める
• 要件定義のREQとの対応関係を明記
• 受け入れ基準をTODOに反映
• Edgeケースの考慮事項を含める
• 設計文書の詳細を実装TODOに反映
• データベーススキーマとの整合性を確保
• API仕様との一貫性を保つ
• 実装方法の区別：
• **DIRECT**: 設定作業のみ（環境構築、設定ファイル、依存関係など）
• **TDD**: 仕様に合わせた実装を伴う作業（ビジネスロジック、API実装、UI実装など）

6. **出力形式**

# {要件名} 実装TODO

## 概要

- 全タスク数: {数}
- 推定作業時間: {時間}
- クリティカルパス: {タスクID列}
- 参照要件: {REQ-001, REQ-002...}
- 設計文書: {参照した設計文書の概要}

## todo

### フェーズ1: 基盤構築

- [ ] **{{task_id}} [DIRECT]**: {{タスク名}} (REQ-{{XXX}}対応)
  - [ ] {実装詳細1（architecture.mdから抽出）}
  - [ ] {データベース設定（database-schema.sqlから抽出）}
  - [ ] {テスト要件1}
  - [ ] {受け入れ基準（requirements.mdから抽出）}
  - [ ] {完了条件1}

- [ ] **{{task_id}} [DIRECT]**: {{タスク名}} (REQ-{{XXX}}対応)
  - [ ] {実装詳細1（architecture.mdから抽出）}
  - [ ] {環境設定（dataflow.mdから抽出）}
  - [ ] {テスト要件1}
  - [ ] {受け入れ基準（requirements.mdから抽出）}
  - [ ] {完了条件1}

### フェーズ2: API実装

- [ ] **{{task_id}} [TDD]**: {{タスク名}} (REQ-{{XXX}}対応)
  - [ ] {実装詳細1（api-endpoints.mdから抽出）}
  - [ ] {インターフェース実装（interfaces.tsから抽出）}
  - [ ] {テスト要件1}
  - [ ] {エラーハンドリング1（Edgeケースから抽出）}
  - [ ] {受け入れ基準（requirements.mdから抽出）}

### フェーズ3: フロントエンド実装

- [ ] **{{task_id}} [TDD]**: {{タスク名}} (REQ-{{XXX}}対応)
  - [ ] {実装詳細1（interfaces.tsから抽出）}
  - [ ] {データフロー実装（dataflow.mdから抽出）}
  - [ ] {UI/UX要件1}
  - [ ] {ユーザビリティ要件（NFR-201から抽出）}
  - [ ] {テスト要件1}
  - [ ] {受け入れ基準（requirements.mdから抽出）}

### フェーズ4: 統合・最適化

- [ ] **{{task_id}} [TDD]**: {{タスク名}} (REQ-{{XXX}}対応)
  - [ ] {実装詳細1（全設計文書から抽出）}
  - [ ] {E2Eテスト（dataflow.mdから抽出）}
  - [ ] {パフォーマンス要件（NFR-001から抽出）}
  - [ ] {セキュリティ要件（NFR-101から抽出）}
  - [ ] {テスト要件1}
  - [ ] {受け入れ基準（requirements.mdから抽出）}

## 実行順序

1. **基盤構築** ({タスクID列}) - 理由：他のタスクの前提条件
2. **API実装** ({タスクID列}) - 理由：フロントエンドの依存関係
3. **フロントエンド実装** ({タスクID列}) - 理由：ユーザーインターフェース
4. **統合・最適化** ({タスクID列}) - 理由：最終的な品質確保

## 実装プロセス

### TDDタスクの実装プロセス

[TDD]タスクは以下の順序で実装:

1. `/{taskID}/tdd-requirements.md` - 詳細要件定義（要件定義文書から抽出）
2. `/{taskID}/tdd-testcases.md` - テストケース作成（受け入れ基準とEdgeケースから導出）
3. `/{taskID}/tdd-red.md` - テスト実装（失敗）
4. `/{taskID}/tdd-green.md` - 最小実装（アーキテクチャ設計に準拠）
5. `/{taskID}/tdd-refactor.md` - リファクタリング（設計文書との整合性確認）
6. `/{taskID}/tdd-verify-complete.md` - 品質確認（要件定義の受け入れ基準で検証）

### DIRECTタスクの実装プロセス

[DIRECT]タスクは以下の順序で実装:

1. `/{taskID}/direct-setup.md` - 設定作業の実行（設計文書に基づく）
2. `/{taskID}/direct-verify.md` - 設定確認（動作確認とテスト）

## 文書との連携

- **{要件名}-requirements.md**: 機能要件（REQ-XXX）、非機能要件（NFR-XXX）、受け入れ基準
- **architecture.md**: 全体的な実装方針とアーキテクチャパターン
- **database-schema.sql**: データベース関連タスクの実装詳細
- **api-endpoints.md**: API実装タスクの仕様と検証条件
- **interfaces.ts**: フロントエンド・バックエンド間の契約
- **dataflow.md**: データ処理フローと統合テストシナリオ

1. **フィードバック対応** TODOリスト提示後、ユーザーからのフィードバックに基づいて以下を調整：

• タスクの粒度（より細かく/大きく）
• 優先順位の変更
• 不足しているタスクの追加
• 不要なタスクの削除
• 実装方針の変更