Initial commit

commands/breakdown-phase.md

@@ -0,0 +1,378 @@
+---
+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との整合性
+
+矛盾がある場合のみユーザーに警告を表示。問題がなければ何も出力しない。