| name | dig |
| description | 現在のPlanに対して実装に必要な不足情報を繰り返し質問し、Planを充実させるスキル。/plan-reviewの前に使用する。 |
| allowed-tools | Skill(plan-review) |
Dig
現在のPlanファイルを読み込み、実装に移る際に不足している情報を特定し、ユーザーへ繰り返しAskUserQuestionで質問する。得られた回答をPlanに反映し、更新後のPlanを再分析して、さらなる不足があれば再度質問する。情報が十分に揃うまでこのサイクルを繰り返す。
前提条件
実行フロー
Phase 1: 最新Planファイルの検出
ls -t ./plans/*.md 2>/dev/null | head -1
ファイルが見つからない場合はエラー終了。
Readツールで検出したPlanファイルの内容を取得。
Phase 2: 不足情報の分析
Planの内容を以下の観点で分析し、実装に着手するために不足している情報を洗い出す:
分析観点
-
技術的な設計判断
- 使用するライブラリ・フレームワークの選択が明示されているか
- データ構造・アルゴリズムの選択が明確か
- APIの設計(エンドポイント、リクエスト/レスポンス形式)が具体的か
-
ビジネス要件の明確さ
- エッジケースの挙動が定義されているか
- エラー時のユーザー向け挙動が決まっているか
- 入力値の制約・バリデーション要件が明確か
- 成功/失敗の判定基準が定義されているか
-
既存コードとの整合性
- 既存APIや型定義との互換性が考慮されているか
- 命名規則・コーディング規約との一貫性があるか
- 既存モジュールとの依存関係が明確か
-
実装の具体性
- 各ステップが実装可能な粒度まで分解されているか
- ファイルの作成・変更対象が特定されているか
- テスト戦略(何をどうテストするか)が明確か
Phase 3: 質問サイクル
不足情報が見つかった場合、以下のサイクルを繰り返す:
┌─→ 不足情報を特定
│ ↓
│ AskUserQuestionで質問(1回につき1〜3個の関連する質問をまとめる)
│ ↓
│ ユーザーの回答を受け取る
│ ↓
│ 回答内容をPlanファイルに反映(Editツールで更新)
│ ↓
│ 更新後のPlanを再度読み込み・再分析
│ ↓
└── まだ不足があれば繰り返す
質問のルール
- 1回の質問で1〜3個の関連する質問をまとめて聞く(質問が多すぎると負担になる)
- 具体的に聞く: 「設計はどうしますか?」ではなく「返り値の型はResult<T, E>とOptionのどちらを想定していますか?」のように選択肢や具体例を提示する
- コードベースの情報を活用する: 質問前に関連コードを読み、既存の実装パターンを把握した上で質問する。既にコードから読み取れる情報は質問しない
- 優先度順に聞く: 実装のブロッカーになる情報から先に聞く
終了条件
以下のいずれかを満たした場合、質問サイクルを終了する:
- すべての分析観点で十分な情報が揃った
- ユーザーが「十分」「OK」「もういい」等、終了の意思を示した
Phase 4: 完了報告と自動レビュー
質問サイクル終了後、以下を報告する:
=== Dig 完了 ===
更新したPlanファイル: <path>
追加された情報:
- [追加された主要な決定事項を箇条書き]
/plan-review を自動実行します...
報告後、Skillツールで /plan-review を自動実行する。ユーザーの追加操作は不要。
エラーハンドリング
| 状況 | 対応 |
|---|
| Planファイルが見つからない | plansディレクトリにファイルがないことを通知 |
| Planファイルの更新に失敗 | エラー内容を報告し、手動更新を促す |
Notes
- plansディレクトリは
./plans(プロジェクトルート相対)
- 最新ファイルを自動検出(ユーザーによるパス指定は不要)
/plan-review の前に使用することで、レビューの質を向上させる
- 質問前に関連コードを読むことで、既にコードベースから判断可能な情報の質問を避ける