question-driven-design

name	question-driven-design
description	設計を一緒に考える・設計相談・どう作るか議論したいときに使う。実装前に設計ツリーを質問で網羅的に掘り下げ、暗黙の前提を明示化する。新機能・アーキテクチャ変更など暗黙の設計判断が多いタスクで、計画の手前に質問フェーズを挿入する。implementation-gate-rule との分岐判断基準を含む。

Question-Driven Design — 質問駆動の要件掘り下げ

grill-me スキル（Matt Pocock 作）のパターンを基に、implementation-gate-rule との統合を設計。

いつ使うか

暗黙の設計判断が多いタスクで、Plan mode に入る前に使う。

タスク特性	推奨フロー	このスキルの出番
暗黙の設計判断が多い（新機能、アーキテクチャ変更、未知ドメイン）	質問フェーズ → Plan mode → 実装	あり
技術的に明確だが規模が大きい（リファクタ、マイグレーション）	直接 Plan mode → 実装	なし
軽微な修正（1ファイル数行）	直接実装	なし

判断基準

以下の条件に複数該当する場合、質問フェーズを挟む:

• ユーザーの指示に「どう実装するか」の判断余地が複数ある
• 既存コードベースとの整合性が自明でない
• 要件の背景や制約が不明確

いつ使わないか

• ユーザーが具体的な実装方針を指定済み（「XをYに変更して」）
• Issue とコードベースの一次情報から主要な設計分岐を解ける
• 既存パターンの踏襲で済むタスク

コア指示

この計画のあらゆる側面について、共通の認識に達するまで、徹底的に質問を投げかける。設計のツリーを枝分かれの先まで一つひとつたどり、決定事項間の依存関係を順番に解決する。各質問に対し、推奨する回答も併せて提示する。

質問は一度に一つずつ。

コードベースを探索することで答えが得られる質問であれば、質問する代わりにコードベースを調査する。

implementation-gate-rule との関係

質問フェーズは implementation-gate-rule を置き換えない。通常は質問フェーズの成果（合意事項・未解決論点のリスト）を Plan の入力として Plan mode に進む。ただし、質問フェーズで十分な合意が形成され、ユーザーが直接実装を指示した場合はその判断に従う。

質問フェーズの完了

以下は完了の目安であり、チェックリストではない:

• スコープ（やること/やらないこと）がおおむね合意できた
• 主要な設計判断の分岐点が特定されている
• 主要な整合リスクが特定されている（詳細な整合確認は Plan mode 側の責務）

完了後、合意事項と未解決論点を箇条書きで要約し、ユーザーに確認を取ってから次のステップ（Plan mode または直接実装）に進む。ユーザーが途中で「もう十分」と判断した場合は、未解決の設計判断を明示した上で次のステップに進む。