379 lines
16 KiB
Markdown
379 lines
16 KiB
Markdown
---
|
||
argument-hint: <タスク名> <phase番号>
|
||
description: 指定されたPhaseの詳細タスク計画書を生成
|
||
allowed-tools: ["Read", "Write", "Task", "AskUserQuestion"]
|
||
---
|
||
|
||
# 指定されたPhaseの詳細タスク計画書を生成します
|
||
|
||
このコマンドは、**TDD（Test-Driven Development）とSOLID原則**に基づいた指定Phaseの詳細計画書を `specs/[taskname]/tasks/phase{N}-{name}.md` として生成します。
|
||
|
||
**重要**: Phase構成は `/sdd:plan-phases` で決定済みであることが前提です。
|
||
|
||
【引数】
|
||
$ARGUMENTS
|
||
|
||
**引数の形式**:
|
||
- `<タスク名>` - 必須
|
||
- `<phase番号>` - 必須（例: 1, 2, 3）
|
||
|
||
## Phase分けの基本方針
|
||
|
||
Phase分けは以下の原則に基づいて行います：
|
||
|
||
### 重要な前提条件
|
||
|
||
**⚠️ 調査・設計はPhase分け前に完了させること**
|
||
- Phase内のタスクには調査・設計タスクを含めてはいけません
|
||
- 技術選定、アーキテクチャ設計、実装方法の検討など、全ての調査・設計作業は `/sdd:conduct-research` コマンドで完了させてください
|
||
- Phase内のタスクは「実装」のみに焦点を当てます
|
||
|
||
**Phase内に含めてはいけないタスクの例**:
|
||
- ❌ 「認証ライブラリの選定」
|
||
- ❌ 「データベーススキーマの設計検討」
|
||
- ❌ 「API設計の方針決定」
|
||
- ❌ 「パフォーマンスの実現可能性調査」
|
||
|
||
**Phase内に含めるべきタスクの例**:
|
||
- ✅ 「ユーザーテーブルのマイグレーション作成」
|
||
- ✅ 「認証APIエンドポイントの実装」
|
||
- ✅ 「ログインUIコンポーネントの実装」
|
||
- ✅ 「ユニットテストの作成」
|
||
|
||
### タスク分解の方針
|
||
|
||
#### Phase分けの基準
|
||
Phaseは以下の基準で分割してください：
|
||
|
||
1. **独立してデプロイ・リリース可能な単位**
|
||
- 各Phaseは独立して動作確認とリリースができる状態になるように分割
|
||
- Phase完了時点で品質チェックに成功する状態であること（必須）
|
||
|
||
2. **機能の依存関係による分割**
|
||
- 後続Phaseが前Phaseの成果物に依存する構造
|
||
- 並行開発可能なPhaseは別々に分ける
|
||
|
||
3. **リスクとビジネス価値による優先順位付け**
|
||
- 高リスク・高価値の機能は早期のPhaseで実装
|
||
- 基盤機能 → コア機能 → 拡張機能の順に配置
|
||
|
||
#### Phase内のタスク分けの基準
|
||
各Phase内でさらに小さいタスクに分ける場合、以下の基準を適用してください：
|
||
|
||
1. **適切な粒度の単位**
|
||
- 大きすぎる場合はさらに分割を検討
|
||
- 小さすぎる場合は統合を検討
|
||
|
||
2. **TDDサイクルが完結する単位**
|
||
- Red → Green → Refactor のサイクルが1回以上完結すること
|
||
- テストと実装がセットで完了すること
|
||
|
||
3. **単一の機能または責任を持つ単位**
|
||
- 単一責任の原則に従う
|
||
- タスク名が「〇〇と△△」のように複数の責任を示す場合は分割
|
||
|
||
4. **他のタスクとの依存関係が明確**
|
||
- タスクAが完了しないとタスクBに着手できない場合は依存関係を明記
|
||
- 並行作業可能なタスクは独立させる
|
||
|
||
#### 具体例：空のWebアプリにログイン機能を実装する場合
|
||
|
||
**Phase 1: ユーザーテーブルとモデル**
|
||
- タスク1: ユーザーテーブルのマイグレーションファイル作成
|
||
- タスク2: マイグレーション実行とテスト
|
||
- タスク3: ユーザーモデルの基本構造作成（ID、メール、パスワードハッシュフィールド）
|
||
|
||
**Phase 2: ログインAPI**
|
||
- タスク1: ログインエンドポイントの骨組み作成（POST /api/auth/login、リクエスト受付のみ）
|
||
- タスク2: パスワード検証ロジックの実装
|
||
- タスク3: JWTトークン生成機能の実装
|
||
|
||
**Phase 3: ログインUI**
|
||
- タスク1: ログインフォームコンポーネントの骨組み作成（メール・パスワード入力欄のみ）
|
||
- タスク2: フォーム送信処理とAPIとの連携
|
||
- タスク3: エラー表示UI（バリデーションエラー、認証エラー）
|
||
|
||
各タスクはTDDサイクル（Red→Green→Refactor）が1回完結する粒度です。
|
||
|
||
### 開発原則
|
||
各Phaseでは `specs/_steering/principles.md` に記載された以下の原則を適用します：
|
||
- **TDD（Test-Driven Development）**: Red-Green-Refactorサイクル
|
||
- **SOLID原則**: 単一責任、開放/閉鎖、リスコフの置換、インターフェース分離、依存性逆転
|
||
- **YAGNI原則**: 実際に必要になるまで機能を追加しない
|
||
|
||
### ⚠️ 重要な制約事項
|
||
- **過度な抽象化を避ける**: インターフェース（抽象）を作ることが目的化してはいけない
|
||
- **型定義だけを先に作ることは禁止**: 実装と共に型を作成し、必要に応じて分離する
|
||
- **YAGNI原則の徹底**: 将来の要件を予測した実装は行わない
|
||
|
||
## 実行手順
|
||
|
||
### 1. 引数のパースと検証
|
||
|
||
`$ARGUMENTS` から タスク名 と Phase番号 を抽出：
|
||
|
||
**引数が不足している場合**:
|
||
- タスク名のみ指定: エラーメッセージ「Phase番号を指定してください。使用方法: /sdd:breakdown-phase <taskname> <phase番号>」
|
||
- 両方未指定: `specs/` ディレクトリ内のタスクをリスト表示し、**AskUserQuestionツールで選択**を求める
|
||
|
||
**Phase番号が数値でない場合**:
|
||
- エラーメッセージ「Phase番号は数値で指定してください」
|
||
|
||
### 2. タスクディレクトリの確認
|
||
|
||
- `specs/[taskname]/` ディレクトリの存在を確認
|
||
- 必須ファイルの存在確認:
|
||
- `overview.md` （Phase構成が含まれているはず）
|
||
- `specification.md`
|
||
- `technical-details.md`
|
||
- `specs/[taskname]/tasks/` ディレクトリが存在しない場合は作成
|
||
|
||
### 3. ステアリングドキュメントの読み込み
|
||
|
||
プロジェクト全体のコンテキストを把握するため、以下のステアリングドキュメントを読み込みます：
|
||
|
||
**`specs/_steering/product.md`**:
|
||
- プロダクトの目的とビジョン
|
||
- ターゲットユーザー
|
||
- 主要機能とビジネス目標
|
||
|
||
**`specs/_steering/tech.md`**:
|
||
- 技術スタックとアーキテクチャ
|
||
- 開発標準（型安全性、コード品質、テスト戦略）
|
||
- 重要な技術的決定事項
|
||
|
||
**`specs/_steering/structure.md`**:
|
||
- プロジェクト構造と命名規則
|
||
- コード組織原則
|
||
- モジュール境界
|
||
|
||
**ステアリングドキュメントが存在しない場合**:
|
||
- 警告メッセージを表示: 「⚠️ ステアリングドキュメントが見つかりません。プロジェクト固有のコンテキストなしで進めます。」
|
||
- `/sdd:steering` コマンドでステアリングドキュメントを作成することを推奨
|
||
- 処理は続行（ステアリングドキュメントは必須ではない）
|
||
|
||
### 4. 調査完了の確認
|
||
|
||
詳細タスク計画作成前に、必ず調査が完了していることを確認:
|
||
|
||
1. **overview.mdの調査セクション確認**
|
||
- `specs/[taskname]/overview.md` の調査項目表を読み込み
|
||
- 全ての調査項目の状態を確認
|
||
|
||
2. **調査ステータスの判定**
|
||
- 全て「完了」の場合: 次のステップへ進む
|
||
- 「未着手」がある場合:
|
||
- 警告メッセージを表示: 「⚠️ 調査が完了していません」
|
||
- 未完了の調査項目をリスト表示
|
||
- AskUserQuestionツールで確認して続行するか判断
|
||
- 続行しない場合: `/sdd:conduct-research [taskname]` を推奨
|
||
|
||
### 5. 既存ドキュメントの分析
|
||
|
||
以下のドキュメントから情報を抽出:
|
||
|
||
**`overview.md`**:
|
||
- 調査結果（調査セクションおよびspecs/research/配下の個別ファイル）
|
||
- **指定されたPhase番号のPhase情報のみ**を抽出
|
||
- Phase名、状態、目標、依存関係、成果物
|
||
- Phase番号が overview.md に存在しない場合:
|
||
- エラーメッセージ「Phase {N} は overview.md に存在しません。/sdd:plan-phases でPhase構成を作成してください。」
|
||
- 処理を中断
|
||
|
||
**`specification.md`**:
|
||
- 機能要件の詳細
|
||
- 指定Phaseで実装する機能
|
||
- 非機能要件
|
||
|
||
**`technical-details.md`**:
|
||
- 技術スタックと技術選定
|
||
- データ設計とAPI設計
|
||
- セキュリティ要件
|
||
|
||
### 6. Phase計画書の生成/更新
|
||
|
||
指定されたPhase番号に対して `specs/[taskname]/tasks/phase{N}-{phaseName}.md` ファイルを生成または更新:
|
||
|
||
**ファイル名の決定**:
|
||
- Phase番号: 引数で指定された番号
|
||
- Phase名: overview.mdから抽出したPhase名（kebab-case に変換）
|
||
- 例: Phase 2 "Core Features" → `phase2-core-features.md`
|
||
|
||
**生成・更新モードの判定**:
|
||
- ファイルが存在しない場合: 新規作成
|
||
- ファイルが存在する場合:
|
||
- 既存内容を確認
|
||
- **AskUserQuestionツール**で「上書き/スキップ/マージ」を確認
|
||
- マージの場合は既存の進捗情報（チェックボックスの状態、開始日時、完了済みタスク）を保持しながら更新
|
||
|
||
**Phase内タスクの検証**:
|
||
- 各タスクが実装タスクのみであることを確認
|
||
- 調査・設計タスクが含まれていないかチェック
|
||
- 調査・設計タスクが見つかった場合: 警告を表示し、research.mdへの移動を提案
|
||
|
||
**ファイルフォーマット**:
|
||
|
||
```markdown
|
||
# Phase {N}: {phaseName} 計画書
|
||
|
||
## タスク目次
|
||
|
||
- 1. [タスク名]
|
||
- 2.1. [タスク名]（2.x系は並列実行可能）
|
||
- 2.2. [タスク名]
|
||
- 2.3. [タスク名]
|
||
- 3. [タスク名]
|
||
|
||
**並列実行の判断基準（明示的並列宣言方式）:**
|
||
- デフォルトは全て直列実行
|
||
- 並列実行するタスクは明示的にn.x形式で番号付け（例: 2.1, 2.2, 2.3）
|
||
- タスク作成者が並列実行して問題ないことを保証する責任を持つ
|
||
- Phase分け時にユーザーに依存関係の妥当性を確認する
|
||
|
||
## Phase概要
|
||
- **Phase名**: {phaseName}
|
||
- **状態**: 未着手/進行中/完了
|
||
- **目標**:
|
||
|
||
## 開発原則
|
||
|
||
このPhaseでは `specs/_steering/principles.md` に記載された開発原則を適用します。
|
||
各タスクでTDD（Red-Green-Refactor）サイクルを実施してください。
|
||
|
||
## 依存関係
|
||
- **前提条件**: [Phase N-1の完了、必要なライブラリの選定など]
|
||
- **ブロッカー**: [なし、または現在のブロッカー]
|
||
- **後続Phaseへの影響**: [Phase N+1が依存する機能]
|
||
|
||
## 実装する機能
|
||
- 機能1
|
||
- 機能2
|
||
- 機能3
|
||
|
||
## タスク詳細
|
||
|
||
### タスク1: [タスク名]
|
||
- **説明**: [実装内容]
|
||
- **状態**: 未着手
|
||
- **開始日時**:
|
||
- **TDDステップ**:
|
||
- [ ] Red: テストケース作成
|
||
- [ ] Green: 最小実装
|
||
- [ ] Refactor: リファクタリング
|
||
- **依存関係**: なし
|
||
|
||
### タスク2.1: [タスク名]
|
||
- **説明**: [実装内容]
|
||
- **状態**: 未着手
|
||
- **開始日時**:
|
||
- **TDDステップ**:
|
||
- [ ] Red: テストケース作成
|
||
- [ ] Green: 最小実装
|
||
- [ ] Refactor: リファクタリング
|
||
- **依存関係**: タスク1
|
||
|
||
### タスク2.2: [タスク名]
|
||
- **説明**: [実装内容]
|
||
- **状態**: 未着手
|
||
- **開始日時**:
|
||
- **TDDステップ**:
|
||
- [ ] Red: テストケース作成
|
||
- [ ] Green: 最小実装
|
||
- [ ] Refactor: リファクタリング
|
||
- **依存関係**: タスク1
|
||
|
||
### タスク3: [タスク名]
|
||
- **説明**: [実装内容]
|
||
- **状態**: 未着手
|
||
- **開始日時**:
|
||
- **TDDステップ**:
|
||
- [ ] Red: テストケース作成
|
||
- [ ] Green: 最小実装
|
||
- [ ] Refactor: リファクタリング
|
||
- **依存関係**: タスク2.x系全て
|
||
|
||
## テスト戦略
|
||
|
||
- **単体テスト**: 各関数/メソッドの振る舞いを検証
|
||
- **統合テスト**: モジュール間の連携を検証
|
||
- **E2Eテスト**: エンドユーザーの視点からの動作を検証
|
||
|
||
## Phase完了条件
|
||
- [ ] 全タスク完了
|
||
- [ ] 全テスト通過
|
||
- [ ] 品質チェックコマンドが成功（lint、type check、buildなど）
|
||
- [ ] コードレビュー承認
|
||
|
||
## 技術的課題と解決方針（必要な場合のみ）
|
||
[想定される課題と解決方針がある場合に記述]
|
||
|
||
## リスク管理（必要な場合のみ）
|
||
[Phase固有のリスクがある場合に記述]
|
||
|
||
## 次Phaseへの引き継ぎ事項（必要な場合のみ）
|
||
[引き継ぎ事項がある場合に記述]
|
||
```
|
||
|
||
### 7. 完了報告
|
||
|
||
```
|
||
✅ Phase {N} の詳細計画書を生成/更新しました
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
📍 対象ファイル: specs/[taskname]/tasks/phase{N}-{name}.md
|
||
📝 モード: [新規作成/更新/マージ]
|
||
|
||
📊 Phase {N} 概要:
|
||
- Phase名: {name}
|
||
- 状態: {status}
|
||
- 目標: {goal}
|
||
- タスク数: {count}
|
||
|
||
💡 次のアクション:
|
||
- Phase計画書の内容を確認・編集してください
|
||
- TDDサイクル（Red→Green→Refactor）を意識して進めてください
|
||
- 他のPhaseの計画書を作成する場合: `/sdd:breakdown-phase [taskname] [phase番号]`
|
||
- Phase実装を開始する場合: `/sdd:implement-phase [taskname] [phase番号]`
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
```
|
||
|
||
## 注意事項
|
||
|
||
- **⚠️ 重要**: このコマンドは**指定された1つのPhase**の詳細計画のみを生成します
|
||
- **⚠️ 重要**: Phase構成は事前に `/sdd:plan-phases` で決定されている必要があります
|
||
- **⚠️ 重要**: 詳細であれば詳細であるほど良いわけではない。必要な部分だけを必要なだけ書くこと
|
||
- **⚠️ 重要**: インターフェースや抽象クラスは、それを使用しなければ実現できない時以外は使用禁止
|
||
- **⚠️ 重要**: 型定義だけを先に作ることは絶対に行わないこと。タスク単位で型定義だけを作ることは禁止。実装を作った後、他でもその型を使用する場合に分離する
|
||
- **⚠️ 重要**: 推測される開発期間、工数、見積もり時間などは一切記載しないこと（タスクの開始日時は記録する）
|
||
- **⚠️ 重要**: 「将来的に必要になる」「今後〜が必要」といった適当な推測に基づいた記述は禁止。現時点で明確に必要なことのみを記載すること
|
||
- **⚠️ 重要**: 不明なところは勝手に決めずに「**不明**」と明記し、複数の案（案A、案B、案Cなど）を記述すること。ユーザーは `/sdd:clarify-spec [taskname]` コマンドで不明箇所を明確化できる
|
||
- **配置先**: `specs/[taskname]/tasks/phase{N}-{name}.md`
|
||
- 既存のPhase計画書がある場合、進捗情報（状態、タスクの開始日時、チェックボックス、完了済みタスク）は保持する
|
||
- **TDD原則**: 各タスクでRed→Green→Refactorサイクルを明記
|
||
- **設計原則**: 各Phase/タスクでどの設計原則を適用するか明確に記述
|
||
- 依存関係は具体的かつ明確に記述し、依存性注入（関数やオブジェクトを引数として渡す）を活用
|
||
- overview.mdの「Phase概要と依存関係」セクションと整合性を保つ
|
||
- Phase名は overview.md から自動抽出し、ファイル名は `phase{N}-{kebab-case-name}.md` 形式とする
|
||
|
||
## 内部品質チェック
|
||
|
||
**重要**: 以下のチェックはコマンド内部で実施し、**生成されるspecファイルには結果を記載しません**。
|
||
|
||
### ステアリングドキュメントレビュー（内部処理）
|
||
|
||
Phase詳細計画書生成後、内部的にステアリングドキュメントとの整合性を確認：
|
||
- tech.mdのコーディング標準・テスト戦略への準拠
|
||
- structure.mdのモジュール境界・命名規則の遵守
|
||
- product.mdのビジネス目標との整合性
|
||
- principles.mdの開発原則（TDD、SOLID、YAGNI）への従属
|
||
|
||
問題がある場合のみユーザーに修正を促す。準拠している場合は何も出力しない。
|
||
|
||
### 矛盾チェック（内部処理）
|
||
|
||
Phase詳細計画書作成後、内部的に仕様書間の矛盾を確認：
|
||
- overview.mdとの整合性
|
||
- specification.mdとの一致
|
||
- technical-details.mdとの整合性
|
||
|
||
矛盾がある場合のみユーザーに警告を表示。問題がなければ何も出力しない。
|