--- description: 設計文書に基づいて実装タスクを1日単位の粒度で分割し、1ヶ月単位のフェーズに整理します。各フェーズ毎に個別のタスクファイルを作成し、依存関係を考慮した適切な順序で管理します。 --- # kairo-tasks ## 目的 設計文書に基づいて実装タスクを1日単位の粒度で分割し、1ヶ月単位のフェーズに整理する。各フェーズ毎に個別のタスクファイルを作成し、依存関係を考慮した適切な順序で管理する。 ## 前提条件 - `docs/design/{要件名}/` に設計文書が存在する - 設計がユーザによって承認されている(または承認が省略されている) - `docs/tasks/` ディレクトリが存在する(なければ作成) - 思考は英語で実施。ファイルは日本語で記述 - NEVER: task_id は `TASK-{4桁の数字}` (例 TASK-0001 )にする ## 実行内容 **【信頼性レベル指示】**: 各項目について、元の資料(EARS要件定義書・設計文書含む)との照合状況を以下の信号でコメントしてください: - 🔵 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合 - 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合 - 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合 1. **追加ルールの読み込み** - `docs/rule` ディレクトリが存在する場合は読み込み - `docs/rule/kairo` ディレクトリが存在する場合は読み込み - `docs/rule/kairo/tasks` ディレクトリが存在する場合は読み込み - 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用 2. **技術スタック定義の読み込み** - `docs/tech-stack.md` が存在する場合は読み込み - 存在しない場合は `CLAUDE.md` から技術スタックセクションを読み込み - どちらも存在しない場合は `.claude/commands/tech-stack.md` のデフォルト定義を使用 3. **設計文書の分析** - @agent-symbol-searcher で設計文書を検索し、見つかったファイルをReadツールで読み込み - `docs/design/{要件名}/architecture.md` をReadツールで読み込み - `docs/design/{要件名}/database-schema.sql` をReadツールで読み込み - `docs/design/{要件名}/api-endpoints.md` をReadツールで読み込み - `docs/design/{要件名}/interfaces.ts` をReadツールで読み込み - `docs/design/{要件名}/dataflow.md` をReadツールで読み込み - 読み込んだ技術スタック定義に基づいて実装技術を特定 4. **既存タスクファイルの確認** - @agent-symbol-searcher で既存タスクIDを検索し、見つかったタスクファイルをReadツールで読み込み - 既存の`docs/tasks/{要件名}-*.md`ファイルをReadツールで読み込み - 使用済みタスク番号(TASK-0000形式)を抽出 - 新規タスクで重複しない番号を割り当て 5. **タスクの洗い出し** - 基盤タスク(DB設定、環境構築など) - バックエンドタスク(API実装) - フロントエンドタスク(UI実装) - 画面のグループ毎に細かく分割する - 統合タスク(E2Eテストなど) 6. **依存関係の分析** - タスク間の依存関係を明確化 - 並行実行可能なタスクを識別 - クリティカルパスを特定 7. **タスクの詳細化** 各タスクに以下を含める: - タスクID(TASK-0000形式) - タスク名 - タスクタイプ(TDD/DIRECT) - **TDD**: コーディング、ビジネスロジック実装、UI実装、テスト実装など開発作業 - **DIRECT**: 環境構築、設定ファイル作成、ドキュメント作成、ビルド設定など準備作業 - 要件へのリンク - 依存タスク - 実装詳細 - 単体テスト要件 - 統合テスト要件 - UI/UX要件(該当する場合) - ローディング状態 - エラー表示 - モバイル対応 - アクセシビリティ要件 8. **タスクの順序付け** - 依存関係に基づいて実行順序を決定 - マイルストーンを設定 - 並行実行可能なタスクをグループ化 9. **フェーズ分割** - 各タスクを1日単位の粒度で設計 - タスクを1ヶ月(20日想定)以内の期間でフェーズに分割 - NEVER タスクの情報の省略 - YOU MUST 180時間を超えるようなフェーズは分割する - IMPORTANT フェーズ数は固定しない - IMPORTANT フェーズは500行未満で分割する - YOU MUST フェーズの分割はアーキテクチャのレイヤーを基準にする - NEVER 事前検討した分割基準を前提としない 10. **ファイル作成** - ファイル作成は ファイル毎に @task で実行する - 各フェーズ毎に個別のタスクファイルを日本語で作成 - NEVER タスクの情報の省略 - `docs/tasks/{要件名}-phase1.md`: フェーズ1の詳細タスク - `docs/tasks/{要件名}-phase2.md`: フェーズ2の詳細タスク - (以下、フェーズ数に応じて継続) - `docs/tasks/{要件名}-overview.md`: 全体概要とフェーズ一覧 - 各タスクにチェックボックスを追加してタスクの完了状況を追跡可能にする - 各タスクには 要件名 の定義を含める ## 出力ファイル構造 作成するファイル: - `docs/tasks/{要件名}-overview.md`: 全体概要とフェーズ一覧 - `docs/tasks/{要件名}-phase1.md`: フェーズ1詳細タスク - `docs/tasks/{要件名}-phase2.md`: フェーズ2詳細タスク - (フェーズ数に応じて継続) ## 必須構成要素 ### Overview.mdの必須項目 - プロジェクト概要(期間・工数・総タスク数) - フェーズ構成テーブル(期間・成果物・タスク数・工数・ファイルリンク) - 既存タスク番号管理(使用済み番号・次回開始番号) - 全体進捗チェックボックス - マイルストーン定義 ### Phase.mdの必須項目 - フェーズ概要(期間・目標・成果物) - 週次計画(Week 1-4の目標・成果物) - 日次タスク(TASK-0000形式、8時間単位) - 各タスクの詳細構成: - タスク完了チェックボックス - 推定工数・タスクタイプ(TDD/DIRECT) - 要件リンク・依存タスク - 要件名 - 実装詳細・完了条件 - テスト要件(TDDタスクの場合) ## タスクプロセス定義 ### TDDタスク 1. `/tsumiki:tdd-requirements` - 詳細要件定義 2. `/tsumiki:tdd-testcases` - テストケース作成 3. `/tsumiki:tdd-red` - テスト実装(失敗) 4. `/tsumiki:tdd-green` - 最小実装 5. `/tsumiki:tdd-refactor` - リファクタリング 6. `/tsumiki:tdd-verify-complete` - 品質確認 ### DIRECTタスク 1. `/tsumiki:direct-setup` - 直接実装・設定 2. `/tsumiki:direct-verify` - 動作確認・品質確認 ## 実行フロー 1. **追加ルール読み込み**: `docs/rule` → `docs/rule/kairo` → `docs/rule/kairo/tasks` 2. **技術スタック読み込み**: `docs/tech-stack.md` → `CLAUDE.md` → `.claude/commands/tech-stack.md` 3. **設計文書分析**: @agent-symbol-searcher で検索後、Readツールで各ファイル読み込み 4. **既存タスク確認**: @agent-symbol-searcher + Readで使用済み番号抽出 5. **タスク洗い出し**: 基盤→バックエンド→フロントエンド→統合の順 6. **フェーズ分割**: 180時間・500行を超えない単位で分割 7. **ファイル作成**: overview.md + phase*.md作成 ## 品質基準 - **フェーズ制限**: 180時間以内、500行未満 - **タスク粒度**: 1日8時間単位 - **番号管理**: TASK-0000形式、重複なし - **完了条件**: 各タスクにチェックボックスと完了条件 - **依存関係**: 前タスク完了後の実行順序明記