dig

name	dig
description	現在のPlanに対して実装に必要な不足情報を繰り返し質問し、Planを充実させるスキル。/plan-reviewの前に使用する。
allowed-tools	Skill(plan-review)

Dig

現在のPlanファイルを読み込み、実装に移る際に不足している情報を特定し、ユーザーへ繰り返しAskUserQuestionで質問する。得られた回答をPlanに反映し、更新後のPlanを再分析して、さらなる不足があれば再度質問する。情報が十分に揃うまでこのサイクルを繰り返す。

前提条件

• Plan modeでプランファイルが作成済み

実行フロー

Phase 1: 最新Planファイルの検出

ls -t ./plans/*.md 2>/dev/null | head -1

ファイルが見つからない場合はエラー終了。 Readツールで検出したPlanファイルの内容を取得。

Phase 2: 不足情報の分析

Planの内容を以下の観点で分析し、実装に着手するために不足している情報を洗い出す:

分析観点

1. 技術的な設計判断

   • 使用するライブラリ・フレームワークの選択が明示されているか
   • データ構造・アルゴリズムの選択が明確か
   • APIの設計（エンドポイント、リクエスト/レスポンス形式）が具体的か

2. ビジネス要件の明確さ

   • エッジケースの挙動が定義されているか
   • エラー時のユーザー向け挙動が決まっているか
   • 入力値の制約・バリデーション要件が明確か
   • 成功/失敗の判定基準が定義されているか

3. 既存コードとの整合性

   • 既存APIや型定義との互換性が考慮されているか
   • 命名規則・コーディング規約との一貫性があるか
   • 既存モジュールとの依存関係が明確か

4. 実装の具体性

   • 各ステップが実装可能な粒度まで分解されているか
   • ファイルの作成・変更対象が特定されているか
   • テスト戦略（何をどうテストするか）が明確か

Phase 3: 質問サイクル

不足情報が見つかった場合、以下のサイクルを繰り返す:

┌─→ 不足情報を特定
│   ↓
│   AskUserQuestionで質問（1回につき1〜3個の関連する質問をまとめる）
│   ↓
│   ユーザーの回答を受け取る
│   ↓
│   回答内容をPlanファイルに反映（Editツールで更新）
│   ↓
│   更新後のPlanを再度読み込み・再分析
│   ↓
└── まだ不足があれば繰り返す

質問のルール

• 1回の質問で1〜3個の関連する質問をまとめて聞く（質問が多すぎると負担になる）
• 具体的に聞く: 「設計はどうしますか？」ではなく「返り値の型はResult<T, E>とOptionのどちらを想定していますか？」のように選択肢や具体例を提示する
• コードベースの情報を活用する: 質問前に関連コードを読み、既存の実装パターンを把握した上で質問する。既にコードから読み取れる情報は質問しない
• 優先度順に聞く: 実装のブロッカーになる情報から先に聞く

終了条件

以下のいずれかを満たした場合、質問サイクルを終了する:

1. すべての分析観点で十分な情報が揃った
2. ユーザーが「十分」「OK」「もういい」等、終了の意思を示した

Phase 4: 完了報告と自動レビュー

質問サイクル終了後、以下を報告する:

=== Dig 完了 ===

更新したPlanファイル: <path>

追加された情報:
- [追加された主要な決定事項を箇条書き]

/plan-review を自動実行します...

報告後、Skillツールで /plan-review を自動実行する。ユーザーの追加操作は不要。

エラーハンドリング

状況	対応
Planファイルが見つからない	plansディレクトリにファイルがないことを通知
Planファイルの更新に失敗	エラー内容を報告し、手動更新を促す

Notes

• plansディレクトリは ./plans（プロジェクトルート相対）
• 最新ファイルを自動検出（ユーザーによるパス指定は不要）
• /plan-review の前に使用することで、レビューの質を向上させる
• 質問前に関連コードを読むことで、既にコードベースから判断可能な情報の質問を避ける