dd (Deep Dive) スキル

目的

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

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

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

トリガー

以下のキーワードで自動的にトリガー：

• 「深堀り」「深堀りして」
• 「検討して」
• 「ultrathink」
• 「よく考えて」
• 「他にはないか」「他の案は？」

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

基本ワークフロー

Step 1: 全体を理解する

ユーザーのリクエストを読み、全体像を把握：

• 何を求めているのか？
• どのような文脈・背景があるのか？
• どの程度の詳細度で理解できているか？

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

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

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

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

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仕様、認証方式）
• データフォーマットや制約条件（例: 入力形式、バリデーションルール）
• 非機能要件（例: パフォーマンス、セキュリティ、スケーラビリティ）
• ステークホルダーの承認が必要な意思決定事項

終了提案の例:

**現在の理解**:
[最終的な理解をまとめる]

深堀りは十分に完了したと思います。
この内容で次のステップに進んで良いでしょうか？

選択肢:
A) はい、次に進む
B) いいえ、まだ不明点がある

ユーザーが「いいえ」と回答した場合:

Step 3 に戻り、以下の項目を再確認：

1. 新たな不明点を特定

   • ユーザーに「どの部分が不明確ですか？」と質問
   • 新たに気づいた推測箇所を洗い出す

2. 既存の理解を再検証

   • 現在の理解で誤解や不足がないか確認
   • 特に以下を重点的にチェック：
     • 目的・ゴールの認識は合っているか？
     • 前提条件に抜けはないか？
     • スコープ・制約の理解は正しいか？

3. Step 4 で質問を再開

   • 新たな不明点に対する質問を作成
   • AskUserQuestion で1-4問の質問を実行

このサイクルを、ユーザーが「はい」と答えるまで繰り返す。

質問戦略

質問の深さ

• 初回（広く浅く）: 全体像把握のための広範な質問、3-4問、選択肢で回答しやすく
• 中間（焦点を絞る）: 特定領域に焦点、2-3問、具体例を交えて
• 詳細（深く掘る）: 1つのトピックを深堀り、1-2問、オープンエンド質問も活用

質問の順序（推奨）

1. 全体理解 → 5W1H で基本情報を収集
2. ゴール明確化 → ゴール逆算で方向性を定める
3. 制約特定 → 実現可能性を確認
4. 具体化 → ケースバイケースで詳細を固める
5. 推測排除 → 不確実な部分を確認

出力形式

状況に応じて柔軟に対応：

• 要件定義書 - 新機能設計の場合
• チェックリスト - 確認項目を整理
• マインドマップ - 階層的な思考の可視化
• 議事録形式 - 質問と回答の記録
• その他 - ユーザーの希望に応じて

注意事項

やるべきこと ✅

• 毎回「現在の理解」を表示する - 認識合わせのため必須
• 推測を明示する - 「これは推測ですが...」と前置きする
• 不明点を隠さない - わからないことは正直に質問する
• 柔軟に対応する - ユーザーの回答に応じて質問を調整

やってはいけないこと ❌

• 推測に基づいて進める - 必ず確認する
• 質問しすぎる - 1回に5問以上は避ける
• 同じ質問を繰り返す - 既に回答された内容を再度聞かない
• 一方的に決める - ユーザーの意向を無視しない

使用例

ユーザー: 「新しいAPI機能を追加したい。深堀りして」

実行フロー:

1. 現在の理解を表示（目的、スコープ、不明点）
2. 質問: 「どのようなAPIですか？RESTful? GraphQL?」「どのようなデータを扱いますか？」
3. 回答を元に理解を更新
4. 次の質問: 「認証は必要ですか？」「レート制限は？」
5. 繰り返して要件を明確化
6. 最終的な要件をまとめて終了提案

終了後のアクション

次のステップを提案：

• /plan - 実装計画を立てる
• /dev - 実装を開始
• ドキュメント化 - 要件定義書を作成
• 次の質問へ - 別のトピックを深堀り

参照

• 質問パターン詳細: references/question-templates.md
• 推測排除テクニック: references/question-templates.md の「推測排除のための質問テンプレート」