| name | deep-interview |
| description | 要件が曖昧なとき、ソクラテス式に1問ずつ質問して要件を掘り下げる。十分に明確になったら discovery-council にハンドオフ。「要件が曖昧」「何を作ればいいか」「掘り下げて」「インタビューして」で発動。※ 完成した plan/design を詰問するなら grill、非対話で一括批判するなら critic。 |
| argument-hint | <vague feature idea> |
| allowed-tools | ["Read","Glob","Grep","AskUserQuestion","Skill"] |
| effort | medium |
Deep Interview - ソクラテス式要件掘り下げ
discovery-council の前段。要件が曖昧なときに使う。まだ plan が無い段階で要件を引き出すのが役割。逆に既にある plan/design を詰問したいなら /o-m-cc:grill（こちらは掘り下げでなく stress-test）。
対話前提スキル: 1 問ずつの掘り下げが本質なので、AskUserQuestion が使えない環境では「要件が曖昧です。対話モードで /deep-interview を実行してください」と案内して終了する。
入力
$ARGUMENTS（ユーザーの曖昧なアイデア・要望）
原則
- 1回に1つの質問。バッチで聞かない
- 前の回答を踏まえて次の質問を決める
- 選択肢を提示する（答えやすくする）
- 「なぜ？」「たとえば？」「もし○○なら？」の形で掘り下げる
- 最大 7問 で打ち切る（ユーザーの負担を最小化）
5軸の曖昧性評価
各質問の前に、以下の5軸で内部評価する（ユーザーには見せない）:
| 軸 | 問い |
|---|
| WHO | 誰のための機能か？ユーザーは誰か？ |
| WHAT | 何を実現するか？具体的な振る舞いは？ |
| WHY | なぜ必要か？現状の課題は何か？ |
| SCOPE | 何を含み、何を含まないか？ |
| CONSTRAINT | 技術的制約、期限、依存は？ |
Step 1: 初期分析
ユーザー入力を読み、5軸それぞれを [明確 / やや曖昧 / 曖昧] で評価する。既存コードベースがある場合は Glob/Grep/Read で関連コードを確認し、質問の精度を上げる。
Step 2: インタビューループ
最も曖昧な軸から順に1問ずつ質問する。
AskUserQuestion:
question: "<最も曖昧な軸に対する具体的な質問>"
options:
- "<選択肢A>"
- "<選択肢B>"
- "<選択肢C>"
- "自由に記述"
質問の形: 「なぜ？」「たとえば？」「もし○○なら？」で掘り下げ、必ず3-4個の選択肢 + 自由記述を提示する。
ループ終了条件: 全軸が [明確] / 7問到達 / ユーザーが「もういい」「十分」。
回答への対応:
- 「分からない」→ 仮定を提案して確認を取る（「○○と仮定してよいですか？」）
- 抽象的な回答 → 具体例を求める（「たとえばどんなケースですか？」）
- 矛盾する回答 → 優先順位を聞く（「○○と△△は両立しにくいですが、どちらを優先しますか？」）
Step 3: 要件サマリーの確認
掘り下げた結果を5軸で構造化し、最終確認する（OK / 修正あり）。
Step 4: discovery-council へハンドオフ
確認が取れたら、整理した要件をそのまま discovery-council に渡す:
Skill: discovery-council
Args: <整理された要件サマリー>
Gotchas
- 7問超過でユーザー疲弊: 7問で打ち切り、残った曖昧軸は仮定として明記して discovery-council へ渡す（完璧を狙って質問しすぎない）
- 既にある plan を掘り下げ直さない: 完成した plan/design を持っているなら、掘り下げでなく
/o-m-cc:grill（詰問）を使う。deep-interview は「ゼロから要件を引き出す」用途
- 初期分析を飛ばすと無駄質問: Step 1 で5軸評価＋既存コード確認をせずに質問を始めると、コードを見れば分かることを聞いてループが伸びる
- 「分からない」を放置しない: 仮定を提案して確認を取る。抽象回答は具体例を、矛盾回答は優先順位を聞く
