16 KiB
16 KiB
argument-hint, description, allowed-tools
| argument-hint | description | allowed-tools | ||||
|---|---|---|---|---|---|---|
| <タスク名> <phase番号> | 指定されたPhaseの詳細タスク計画書を生成 |
|
指定された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は以下の基準で分割してください：
-
独立してデプロイ・リリース可能な単位
- 各Phaseは独立して動作確認とリリースができる状態になるように分割
- Phase完了時点で品質チェックに成功する状態であること（必須）
-
機能の依存関係による分割
- 後続Phaseが前Phaseの成果物に依存する構造
- 並行開発可能なPhaseは別々に分ける
-
リスクとビジネス価値による優先順位付け
- 高リスク・高価値の機能は早期のPhaseで実装
- 基盤機能 → コア機能 → 拡張機能の順に配置
Phase内のタスク分けの基準
各Phase内でさらに小さいタスクに分ける場合、以下の基準を適用してください：
-
適切な粒度の単位
- 大きすぎる場合はさらに分割を検討
- 小さすぎる場合は統合を検討
-
TDDサイクルが完結する単位
- Red → Green → Refactor のサイクルが1回以上完結すること
- テストと実装がセットで完了すること
-
単一の機能または責任を持つ単位
- 単一責任の原則に従う
- タスク名が「〇〇と△△」のように複数の責任を示す場合は分割
-
他のタスクとの依存関係が明確
- タスク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 <phase番号>」
- 両方未指定:
specs/ディレクトリ内のタスクをリスト表示し、AskUserQuestionツールで選択を求める
Phase番号が数値でない場合:
- エラーメッセージ「Phase番号は数値で指定してください」
2. タスクディレクトリの確認
specs/[taskname]/ディレクトリの存在を確認- 必須ファイルの存在確認:
overview.md（Phase構成が含まれているはず）specification.mdtechnical-details.md
specs/[taskname]/tasks/ディレクトリが存在しない場合は作成
3. ステアリングドキュメントの読み込み
プロジェクト全体のコンテキストを把握するため、以下のステアリングドキュメントを読み込みます：
specs/_steering/product.md:
- プロダクトの目的とビジョン
- ターゲットユーザー
- 主要機能とビジネス目標
specs/_steering/tech.md:
- 技術スタックとアーキテクチャ
- 開発標準（型安全性、コード品質、テスト戦略）
- 重要な技術的決定事項
specs/_steering/structure.md:
- プロジェクト構造と命名規則
- コード組織原則
- モジュール境界
ステアリングドキュメントが存在しない場合:
- 警告メッセージを表示: 「⚠️ ステアリングドキュメントが見つかりません。プロジェクト固有のコンテキストなしで進めます。」
/sdd:steeringコマンドでステアリングドキュメントを作成することを推奨- 処理は続行（ステアリングドキュメントは必須ではない）
4. 調査完了の確認
詳細タスク計画作成前に、必ず調査が完了していることを確認:
-
overview.mdの調査セクション確認
specs/[taskname]/overview.mdの調査項目表を読み込み- 全ての調査項目の状態を確認
-
調査ステータスの判定
- 全て「完了」の場合: 次のステップへ進む
- 「未着手」がある場合:
- 警告メッセージを表示: 「⚠️ 調査が完了していません」
- 未完了の調査項目をリスト表示
- 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への移動を提案
ファイルフォーマット:
# 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との整合性
矛盾がある場合のみユーザーに警告を表示。問題がなければ何も出力しない。