---
argument-hint: <taskname> [phase.task]
allowed-tools: ["Read", "Write", "Edit", "Bash", "Task", "AskUserQuestion", "TodoWrite"]
---

# specs/[taskname]/配下の仕様書ドキュメントを読み込み、それに基づいて実装作業を行います

以下の引数で指定されたタスクについて、仕様書に基づいた実装作業を行ってください。

【引数】
$ARGUMENTS

## 引数の形式
- `[taskname]` - タスク名のみ指定した場合、そのタスクの最初から作業開始
- `[taskname] [phase].[task]` - Phase番号とタスク番号を指定した場合、そのタスクから作業開始
  - 例: `user-authentication 2.3` → user-authenticationのphase2のタスク3から開始

## 実行手順

### 0. TodoWriteで実装ステップをTodoリストに追加

コマンド実行時、最初に以下の4つのステップをTodoWriteツールでTodoリストに追加：

```
TodoWrite([
  {
    content: "タスクとPhaseの特定",
    activeForm: "タスクとPhaseを特定中",
    status: "in_progress"
  },
  {
    content: "ステアリングドキュメントと仕様書の読み込み",
    activeForm: "ステアリングドキュメントと仕様書を読み込み中",
    status: "pending"
  },
  {
    content: "Phase状況の確認",
    activeForm: "Phase状況を確認中",
    status: "pending"
  },
  {
    content: "実装作業の実行",
    activeForm: "実装作業を実行中",
    status: "pending"
  }
])
```

その後、以下のステップを順番に実行し、各ステップ完了時にTodoの状態を更新：

### 1. タスクとPhase/タスクの特定
上記の引数を解析して作業対象を特定：

1. **引数が指定されている場合**
   - `[taskname]`のみ: specs/[taskname]/を対象とし、Phase 1から開始
   - `[taskname] [phase].[task]`: specs/[taskname]/を対象とし、指定されたPhaseとタスクから開始

2. **引数が指定されていない場合**
   - `specs/`ディレクトリ内のサブディレクトリを一覧表示
   - 複数のタスクがある場合、ユーザーに選択させる：
     「どのタスクで作業しますか？」
     - [1] specs/user-authentication/
     - [2] specs/payment-integration/
     - [3] specs/admin-dashboard/
   - 単一のタスクのみの場合は自動選択

3. **指定されたタスクディレクトリが存在しない場合**
   - エラーメッセージを表示: 「specs/[taskname]/ ディレクトリが見つかりません」
   - specs/配下の利用可能なタスクを一覧表示

### 2. ステアリングドキュメントの読み込み

プロジェクト全体のコンテキストを把握するため、以下のステアリングドキュメントを読み込みます：

**`specs/_steering/product.md`**:
- プロダクトの目的とビジョン
- ターゲットユーザー
- 主要機能とビジネス目標

**`specs/_steering/tech.md`**:
- 技術スタックとアーキテクチャ
- 開発標準（型安全性、コード品質、テスト戦略）
- 重要な技術的決定事項

**`specs/_steering/structure.md`**:
- プロジェクト構造と命名規則
- コード組織原則
- モジュール境界

**`specs/_steering/principles.md`**:
- 開発原則

**ステアリングドキュメントが存在しない場合**:
- 警告メッセージを表示: 「⚠️ ステアリングドキュメントが見つかりません。プロジェクト固有のコンテキストなしで進めます。」
- `/sdd:steering` コマンドでステアリングドキュメントを作成することを推奨
- 処理は続行（ステアリングドキュメントは必須ではない）

### 3. 仕様書の確認
選択されたタスクディレクトリ（specs/[taskname]/）から以下のファイルを読み込んで内容を把握：

1. **specs/[taskname]/overview.md** - プロジェクト全体の概要とPhase構成を理解
2. **specs/[taskname]/specification.md** - 機能要件と非機能要件の詳細を確認
3. **specs/[taskname]/technical-details.md** - 技術的な実装方針を確認
4. **specs/[taskname]/tasks/phase{N}-{phaseName}.md** - 該当するPhaseの計画書を確認

### 4. 現在の状況確認
以下を確認してユーザーに報告：
- 各Phaseの現在の状態（未着手/進行中/完了）
- 実装可能なPhaseの特定（依存関係を考慮）
- ブロッカーの有無

### 5. 作業開始位置の決定

#### 5-1. `[phase].[task]` が指定されている場合
1. 指定されたPhaseファイル（phase{N}-{phaseName}.md）を読み込む
2. 指定されたタスク番号のタスクを特定
3. そのタスクの依存関係を確認：
   - 依存関係が満たされていない場合、警告を表示し、ユーザーに続行するか確認
   - 依存関係が満たされている場合、そのまま続行
4. 指定されたタスクの詳細を表示し、実装計画に進む

#### 5-2. `[phase].[task]` が指定されていない場合
ユーザーに以下を質問：
「どのPhaseの作業を進めますか？」

選択肢：
- Phase {N}: {phaseName}（状態: 〇〇、依存関係: 〇〇）
- または、特定のタスク番号を指定（例: 2.3 でPhase 2のタスク3）

### 6. タスクの確認と実行計画
選択されたPhaseまたはタスクについて：

1. **仕様の確認**
   - specification.mdから該当機能の詳細仕様を抽出
   - technical-details.mdから技術的な実装方針を確認
   - Phase計画書から具体的なタスクとその依存関係を確認

2. **実行可能性の確認**
   - 依存関係が満たされているか確認
   - ブロッカーがないか確認
   - 必要なライブラリやツールが揃っているか確認

3. **TodoWriteで実装タスクを追加**

   Phase計画書のタスクリストから、以下の形式でTodoWriteに実装用Todoを追加：

   ```
   - content: "{タスク名} の実装"
     activeForm: "{タスク名} を実装中"
     status: "pending"
   ```

   **重要**:
   - Phase計画書のタスク1つにつき、Todoアイテム1つを作成
   - タスクの依存関係順に並べる
   - 各Todoには以下の情報を含める：
     - 実装対象のファイルパス
     - 実装する機能の概要
     - テスト対象

4. **ユーザーに確認**

   追加した実装用Todoリストを表示し、AskUserQuestionで確認：
   「この計画で実装作業を開始してよろしいですか？」

   承認された場合、次のステップへ進む

### 7. 実装作業
承認後、追加した実装用Todoを1つずつ実行：

各Todoについて以下の手順で作業：

1. **Todoを`in_progress`に更新**

2. **実装**
   - specification.mdの要件を満たすコードを実装
   - technical-details.mdの技術方針に従う
   - 既存のコードベースとの整合性を保つ
   - any型は絶対に使用しない

3. **品質チェック**
   - コードレビュー基準に従っているか確認
   - エラーハンドリングが適切か確認
   - 関数型プログラミングのスタイルを意識（map/filterの活用）

4. **テスト**
   - Phase計画書のテスト計画に従ってテストを実装
   - ユニットテスト
   - 統合テスト（必要に応じて）

5. **Todoを`completed`に更新**

6. **次のTodoへ** - すべての実装Todoが完了するまで繰り返し

### 8. 完了報告と状態更新

作業完了後の報告フォーマット：

```
✅ タスク [Phase.Task] の実装が完了しました
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📍 対象: specs/{taskname}/ - Phase {N}, Task {M}

💡 次のアクション:
   - 次のタスク実施: `/sdd:implement-phase {taskname} {phase}.{task+1}`
   - Phase検証実施: `/sdd:verify-phase {taskname} {phase}` （Phase内の全タスク完了時）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

**Phase状態の更新**:
- specs/[taskname]/overview.mdのPhase状態を更新
- 該当するspecs/[taskname]/tasks/phase{N}-{phaseName}.mdのタスク状態を更新
- タスク目次の該当タスクの状態とTDDステップを更新

### 9. 品質チェックの実施
作業完了前に必ず以下を確認：

- [ ] 仕様書の要件を満たしているか
- [ ] 依存関係が適切に処理されているか
- [ ] エラーハンドリングが実装されているか
- [ ] テストが実装され、パスしているか
- [ ] any型を使用していないか
- [ ] 関数型のスタイルを意識しているか（配列操作など）
- [ ] 既存の類似実装を確認し、重複を避けているか
- [ ] 既存ライブラリで実現できないか検討したか

## 重要な注意事項

- 実装中は仕様書（overview.md、specification.md、technical-details.md）を常に参照し、要件から逸脱しないこと
- Phase計画書の依存関係を必ず確認し、順序を守ること
- タスク・Phaseの状態を適切に更新すること
- 不明点や仕様の矛盾があれば、実装前にユーザーに確認すること

## 使用例

1. タスク全体を最初から開始:
   `/sdd:implement-phase user-authentication`

2. Phase 2のタスク3から開始:
   `/sdd:implement-phase user-authentication 2.3`

3. 引数なしで対話的に選択:
   `/sdd:implement-phase`

## 内部品質チェック

**重要**: 以下のチェックはコマンド内部で実施し、**生成されるspecファイルには結果を記載しません**。

### ステアリングドキュメントレビュー（内部処理）

実装完了後、内部的にステアリングドキュメントとの整合性を確認：
- product.mdのビジネス目標との整合性
- tech.mdのコーディング標準との整合性
- structure.mdの命名規則・モジュール境界の遵守
- principles.mdの開発原則との一致

問題がある場合のみユーザーに修正を促す。準拠している場合は何も出力しない。

### 矛盾チェック（内部処理）

実装完了後、内部的に仕様書間の矛盾を確認：
- 実装内容とPhase計画書の整合性
- specification.mdとの整合性
- technical-details.mdとの整合性
- 依存関係のあるドキュメント間の矛盾

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