deep-dive

# deep-dive (Deep Dive) スキル

## 目的

**推測を排除し、品質・信頼性を向上させる**

再帰的な質問によって、ユーザーの曖昧な要件や課題を段階的に明確化し、認識のズレを最小限に抑えます。

**核心原則**: 推測に基づいて進めない。不明な点は必ず質問して確認する。

## トリガー

以下のキーワードで自動的にトリガー：
- 「深堀り」「深堀りして」
- 「検討して」
- 「ultrathink」
- 「よく考えて」
- 「他にはないか」「他の案は？」

または `/deep-dive [トピック]` コマンドで明示的に呼び出し。

## 基本ワークフロー

### Step 1: 全体を理解する（調査フェーズ含む）

#### 1-A: ユーザーリクエストの把握

ユーザーのリクエストを読み、全体像を把握：
- 何を求めているのか？
- どのような文脈・背景があるのか？
- どの程度の詳細度で理解できているか？

#### 1-B: コンテキスト調査（技術的な深堀りが必要な場合）

**技術的な要件や実装に関する深堀りの場合**、Exploreサブエージェントに調査を委譲することで、より的確な質問が可能になります。

**調査すべきケース:**
- 新機能の設計・実装
- バグの原因調査
- リファクタリング計画
- 技術選定
- 既存コードベースの理解

**調査不要なケース:**
- 概念的な質問（「〇〇とは？」）
- 一般的な相談
- ドキュメント作成のみ

**調査方法（推奨）:**

Taskツールでsubagent_type=Exploreを使用し、コードベースを調査：

```text
「このプロジェクトの[対象領域]について調査してください：
- 関連するコード・ファイル構造
- 既存の実装パターン
- 依存関係・影響範囲
- 設計パターン・アーキテクチャ」
```

この調査により、推測ではなく**実際のコードに基づいた質問**ができます。

#### 1-C: 調査結果を「現在の理解」に統合

調査結果（ある場合）を踏まえて、Step 2の「現在の理解」に反映します。

### Step 2: 現在の理解状態を表示（毎回必須）

質問をする前に、**毎回必ず**現在の理解をまとめて表示：

```markdown
**現在の理解**:
- 目的: [理解した目的]
- 前提: [理解した前提条件]
- スコープ: [理解した範囲]
- 制約: [理解した制約]
- 不明点: [まだ不明な点]
- 推測箇所: [推測している部分]
```

これにより、ユーザーとの認識合わせができ、誤解を早期に発見できます。

### Step 3: 不明点 + 推測箇所を特定

現在の理解の中で：
- **不明な点** - 情報が欠けている箇所
- **推測している箇所** - 確認していない前提や仮定

推測の兆候：「おそらく」「たぶん」「だと思う」「一般的には」「〜のはず」

### Step 4: AskUserQuestion で質問（1-4問）

状況に応じて1-4問の質問。

**質問数の目安**:
- 広く浅く探る初期段階: 3-4問
- 特定領域に焦点: 2-3問
- 詳細を深堀り: 1-2問

**質問の観点**:
1. **5W1Hベース** - 基本情報を網羅的に収集
2. **ゴール逆算** - 最終目標から必要な要素を特定
3. **制約特定** - 技術的・ビジネス的制約を明確化
4. **ケースバイケース** - 具体例で抽象的な要件を明確化

詳細は `references/question-templates.md` を参照。

### Step 5: 回答を元に理解を更新

ユーザーからの回答を受け取ったら：
1. 回答内容を整理
2. 理解を更新
3. 新たな不明点・推測箇所を特定

### Step 6: Step 2-5 を繰り返す

理解が十分に深まるまで繰り返し。

### Step 7: 終了提案 → ユーザー承認

以下の条件を満たしたら終了を提案：
- **重要な不明点**がなくなった（※）
- 推測箇所が最小限になった
- 具体的な次のアクションが明確になった

**※重要な不明点の定義:**
- 実装アーキテクチャに直接影響する技術要件（例: API仕様、認証方式）
- データフォーマットや制約条件（例: 入力形式、バリデーションルール）
- 非機能要件（例: パフォーマンス、セキュリティ、スケーラビリティ）
- ステークホルダーの承認が必要な意思決定事項

**終了提案の例**:
```markdown
**現在の理解**:
[