---
argument-hint: <タスク名>
description: 実装概要と調査項目を特定してoverview.mdに追加
allowed-tools: ["Read", "Edit", "Task"]
---

# 実装概要と調査項目を特定します

タスク名をもとに、overview.mdに実装概要と調査項目を追加します。

**重要**: このコマンドは実装の大枠（どんな機能を作るか）と調査項目を決定します。詳細な調査は `/sdd:conduct-research` で実施してください。

【タスク名】
$ARGUMENTS

## 実行手順

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

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

- `specs/_steering/product.md` - プロダクト方針
- `specs/_steering/tech.md` - 技術スタック
- `specs/_steering/structure.md` - プロジェクト構造
- `specs/_steering/principles.md` - 開発原則

**ステアリングドキュメントが存在しない場合**:
- 警告メッセージを表示: 「⚠️ ステアリングドキュメントが見つかりません。先に `/sdd:steering` を実行することを推奨します。」
- AskUserQuestionツールで確認:
  - 「ステアリングドキュメントなしで続行しますか？」
  - 選択肢: 「はい（続行）」「いいえ（中断して /sdd:steering を実行）」
- 「いいえ」の場合は処理を中断

### 1. 引数チェックとoverview.mdの読み込み

`$ARGUMENTS` が空の場合：
- エラーメッセージ: 「タスク名を指定してください。例: `/sdd:plan-implementation user-authentication`」

`$ARGUMENTS` が指定されている場合：
- `specs/[taskname]/overview.md` の存在を確認
- 存在しない場合: エラーメッセージ「overview.mdが見つかりません。先に `/sdd:init-task` を実行してください。」
- 存在する場合: overview.mdを読み込み

### 2. 実装する機能の特定

overview.mdの「目的」「スコープ」「想定される成果物」から、実装する機能を特定：

**機能特定の流れ**:
1. overview.mdから実装すべき機能の候補を抽出
2. **各機能について、AskUserQuestionで確認・選択させる**
   - 例: 「ユーザー認証機能を実装しますか？」→ 「はい（必須）」「はい（任意）」「いいえ（不要）」
   - 例: 「認証方法はどうしますか？」→ 「JWT」「Session」「OAuth2」
   - 例: 「この機能の優先度は？」→ 「High（最優先）」「Medium（通常）」「Low（後回し可）」
3. ユーザーが選択した機能のみをリストに追加
4. 機能ごとに入出力イメージを記載

**技術スタックの決定**:
1. ステアリングドキュメント（tech.md）を確認
2. **tech.mdに記載がない技術要素について、複数の選択肢がある場合はAskUserQuestionで選択させる**
   - 例: 「フロントエンドフレームワークは？」→ 「React」「Vue」「Svelte」
   - 例: 「状態管理ライブラリは？」→ 「Redux」「Zustand」「Jotai」「不要」
3. ユーザーが選択した技術スタックを記録
4. **選択できなかった項目（調査が必要）は調査項目として抽出**

### 3. 調査項目の特定

実装概要から、技術的に不明な点を抽出：

**調査項目の判定基準（コマンド内部で使用、specには出力しない）**:
1. これは本当に技術的に不明な点か？
2. ドキュメントを読めばわかることではないか？
3. 一般的な実装パターンで解決できないか？
4. 複数の選択肢があり、検証が必要か？

**調査項目として抽出すべきもの**:
- プロジェクト固有の技術的課題
- 複数の技術の組み合わせで生じる不明点
- パフォーマンスやセキュリティの具体的な検証が必要な項目
- 技術選定（複数の選択肢から選ぶ必要がある）

**調査項目として抽出すべきでないもの**:
- 「ライブラリ選定」のような当たり前の項目
- 公式ドキュメントを読めばわかること
- 一般的な実装パターンで解決できること

**調査項目の特定フロー**:
1. 実装概要から調査が必要そうな項目を**全て**抽出（制限なし）
2. **抽出した全ての項目について、1つずつAskUserQuestionで確認**
   - 例: 「JWT認証のパフォーマンス検証が必要ですか？」→ 「はい」「いいえ」
   - 例: 「この技術選定は調査が必要ですか？」→ 「はい」「いいえ」
3. ユーザーが「はい」と選択した項目のみを調査項目リストに追加
4. **全ての候補について確認が完了するまで繰り返す**

### 4. overview.mdへの追記

overview.mdに以下のセクションを追加：

```markdown
## 実装概要
### 実装する機能
1. [機能名1]
   - 概要: [1-2行で説明]
   - 入力: [概要レベル]
   - 出力: [概要レベル]
   - 優先度: High/Medium/Low

2. [機能名2]
   - 概要: [1-2行で説明]
   - 入力: [概要レベル]
   - 出力: [概要レベル]
   - 優先度: High/Medium/Low

### 技術スタック（候補）
- フロントエンド: [候補]
- バックエンド: [候補]
- データベース: [候補]
- その他: [候補]

## 調査項目
| 状態 | 調査項目名 | 理由 | 概要 |
|------|-----------|------|------|
| 未着手 | [調査項目1] | [なぜこれが不明なのか] | - |
| 未着手 | [調査項目2] | [なぜこれが不明なのか] | - |

---

**次のステップ**:
- 調査が必要: `/sdd:conduct-research [taskname]`
- 調査不要: `/sdd:define-requirements [taskname]`
```

**追記時の注意点**:
- 既存の「次のステップ」セクションは削除して上書き
- 調査項目がない場合は「調査項目なし。すぐに要件定義に進めます。」と記載
- 不明な点は「**不明**」と明記
- 「将来的に」「など」の使用を禁止
- ユーザーがAskUserQuestionで選択した内容をそのまま記載（追加の確認は不要）

### 5. 完了報告

調査項目がある場合:
```markdown
✅ 実装概要と調査項目を特定しました
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📍 更新先: specs/[taskname]/overview.md
📝 実装機能数: [N]件
🔍 調査項目数: [N]件

💡 次のアクション:
   - 調査実施: `/sdd:conduct-research [taskname]`
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

調査項目がない場合:
```markdown
✅ 実装概要を特定しました
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📍 更新先: specs/[taskname]/overview.md
📝 実装機能数: [N]件
🔍 調査項目: なし

💡 次のアクション:
   - 要件定義: `/sdd:define-requirements [taskname]`
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

## 注意事項

- **⚠️ 重要**: 調査が必要そうな項目は**全て**抽出し、各項目についてユーザーに判断を仰ぐこと
- **⚠️ 重要**: 調査項目の数に制限はありません。ユーザーが「必要」と判断した項目のみをリストに追加します
- **⚠️ 重要**: ステアリングドキュメント（`specs/_steering/`）を必ず読み込み、プロジェクトのコンテキストを反映してください
- **⚠️ 重要** 不明なところは勝手に決めずに「**不明**」と明記すること
- 「将来的に必要になる」「今後〜が必要」といった適当な推測に基づいた記述は禁止
- 現時点で明確に必要なことのみを記載すること

## 内部品質チェック

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

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

ドキュメント更新後、内部的にステアリングドキュメントとの整合性を確認：
- product.mdのビジネス目標と実装機能の整合性
- tech.mdの技術方針と技術スタック候補の適切性
- structure.mdのプロジェクト構造との整合性
- principles.mdの開発原則との一致

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

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

ドキュメント更新後、内部的に仕様書間の矛盾を確認：
- overview.md内の目的・スコープと実装機能の整合性
- 調査項目と実装機能の関連性

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