---
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との整合性

矛盾がある場合のみユーザーに警告を表示。問題がなければ何も出力しない。