diegosouzapw deep-dive (Deep Dive) スキル
目的
推測を排除し、品質・信頼性を向上させる
再帰的な質問によって、ユーザーの曖昧な要件や課題を段階的に明確化し、認識のズレを最小限に抑えます。
核心原則: 推測に基づいて進めない。不明な点は必ず質問して確認する。
トリガー
以下のキーワードで自動的にトリガー：
- 「深堀り」「深堀りして」
- 「検討して」
- 「ultrathink」
- 「よく考えて」
- 「他にはないか」「他の案は？」
または /deep-dive [トピック] コマンドで明示的に呼び出し。
基本ワークフロー
Step 1: 全体を理解する（調査フェーズ含む）
1-A: ユーザーリクエストの把握
ユーザーのリクエストを読み、全体像を把握：
- 何を求めているのか？
- どのような文脈・背景があるのか？
- どの程度の詳細度で理解できているか？
1-B: コンテキスト調査（技術的な深堀りが必要な場合）
技術的な要件や実装に関する深堀りの場合、Exploreサブエージェントに調査を委譲することで、より的確な質問が可能になります。
調査すべきケース:
- 新機能の設計・実装
- バグの原因調査
- リファクタリング計画
- 技術選定
- 既存コードベースの理解
調査不要なケース:
- 概念的な質問（「〇〇とは？」）
- 一般的な相談
- ドキュメント作成のみ
調査方法（推奨）:
Taskツールでsubagent_type=Exploreを使用し、コードベースを調査：
「このプロジェクトの[対象領域]について調査してください：
- 関連するコード・ファイル構造
- 既存の実装パターン
- 依存関係・影響範囲
- 設計パターン・アーキテクチャ」
この調査により、推測ではなく実際のコードに基づいた質問ができます。
1-C: 調査結果を「現在の理解」に統合
調査結果（ある場合）を踏まえて、Step 2の「現在の理解」に反映します。
Step 2: 現在の理解状態を表示（毎回必須）
質問をする前に、毎回必ず現在の理解をまとめて表示：
**現在の理解**:
- 目的: [理解した目的]
- 前提: [理解した前提条件]
- スコープ: [理解した範囲]
- 制約: [理解した制約]
- 不明点: [まだ不明な点]
- 推測箇所: [推測している部分]
これにより、ユーザーとの認識合わせができ、誤解を早期に発見できます。
Step 3: 不明点 + 推測箇所を特定
現在の理解の中で：
- 不明な点 - 情報が欠けている箇所
- 推測している箇所 - 確認していない前提や仮定
推測の兆候：「おそらく」「たぶん」「だと思う」「一般的には」「〜のはず」
Step 4: AskUserQuestion で質問（1-4問）
状況に応じて1-4問の質問。
質問数の目安:
- 広く浅く探る初期段階: 3-4問
- 特定領域に焦点: 2-3問
- 詳細を深堀り: 1-2問
質問の観点:
- 5W1Hベース - 基本情報を網羅的に収集
- ゴール逆算 - 最終目標から必要な要素を特定
- 制約特定 - 技術的・ビジネス的制約を明確化
- ケースバイケース - 具体例で抽象的な要件を明確化
詳細は references/question-templates.md を参照。
Step 5: 回答を元に理解を更新
ユーザーからの回答を受け取ったら：
- 回答内容を整理
- 理解を更新
- 新たな不明点・推測箇所を特定
Step 6: Step 2-5 を繰り返す
理解が十分に深まるまで繰り返し。
Step 7: 終了提案 → ユーザー承認
以下の条件を満たしたら終了を提案：
- 重要な不明点がなくなった（※）
- 推測箇所が最小限になった
- 具体的な次のアクションが明確になった
※重要な不明点の定義:
- 実装アーキテクチャに直接影響する技術要件（例: API仕様、認証方式）
- データフォーマットや制約条件（例: 入力形式、バリデーションルール）
- 非機能要件（例: パフォーマンス、セキュリティ、スケーラビリティ）
- ステークホルダーの承認が必要な意思決定事項
終了提案の例:
**現在の理解**:
[最終的な理解をまとめる]
深堀りは十分に完了したと思います。
この内容で次のステップに進んで良いでしょうか？
選択肢:
A) はい、次に進む
B) いいえ、まだ不明点がある
ユーザーが「いいえ」と回答した場合:
Step 3 に戻り、以下の項目を再確認：
新たな不明点を特定
- ユーザーに「どの部分が不明確ですか？」と質問
- 新たに気づいた推測箇所を洗い出す
既存の理解を再検証
- 現在の理解で誤解や不足がないか確認
- 特に以下を重点的にチェック：
- 目的・ゴールの認識は合っているか？
- 前提条件に抜けはないか？
- スコープ・制約の理解は正しいか？
Step 4 で質問を再開
- 新たな不明点に対する質問を作成
- AskUserQuestion で1-4問の質問を実行
このサイクルを、ユーザーが「はい」と答えるまで繰り返す。
質問戦略
質問の深さ
- 初回（広く浅く）: 全体像把握のための広範な質問、3-4問、選択肢で回答しやすく
- 中間（焦点を絞る）: 特定領域に焦点、2-3問、具体例を交えて
- 詳細（深く掘る）: 1つのトピックを深堀り、1-2問、オープンエンド質問も活用
質問の順序（推奨）
- 全体理解 → 5W1H で基本情報を収集
- ゴール明確化 → ゴール逆算で方向性を定める
- 制約特定 → 実現可能性を確認
- 具体化 → ケースバイケースで詳細を固める
- 推測排除 → 不確実な部分を確認
出力形式
状況に応じて柔軟に対応：
- 要件定義書 - 新機能設計の場合
- チェックリスト - 確認項目を整理
- マインドマップ - 階層的な思考の可視化
- 議事録形式 - 質問と回答の記録
- その他 - ユーザーの希望に応じて
注意事項
やるべきこと ✅
- 毎回「現在の理解」を表示する - 認識合わせのため必須
- 推測を明示する - 「これは推測ですが...」と前置きする
- 不明点を隠さない - わからないことは正直に質問する
- 柔軟に対応する - ユーザーの回答に応じて質問を調整
やってはいけないこと ❌
- 推測に基づいて進める - 必ず確認する
- 質問しすぎる - 1回に5問以上は避ける
- 同じ質問を繰り返す - 既に回答された内容を再度聞かない
- 一方的に決める - ユーザーの意向を無視しない
使用例
ユーザー: 「新しいAPI機能を追加したい。深堀りして」
実行フロー:
- 現在の理解を表示（目的、スコープ、不明点）
- 質問: 「どのようなAPIですか？RESTful? GraphQL?」「どのようなデータを扱いますか？」
- 回答を元に理解を更新
- 次の質問: 「認証は必要ですか？」「レート制限は？」
- 繰り返して要件を明確化
- 最終的な要件をまとめて終了提案
終了後のアクション
次のステップを提案：
/plan- 実装計画を立てる/dev- 実装を開始- ドキュメント化 - 要件定義書を作成
- 次の質問へ - 別のトピックを深堀り
参照
- 質問パターン詳細:
references/question-templates.md - 推測排除テクニック:
references/question-templates.mdの「推測排除のための質問テンプレート」