| name | x-grill-me |
| description | 計画や設計について、共通認識に至り、意思決定ツリーのすべての分岐が解消されるまで、ユーザーを徹底的に問い詰めてください。これは、ユーザーが計画の「ストレステスト」を行いたい場合や、設計について厳しく追及されたい場合、あるいは「厳しく問い詰めて（grill me）」と要望した際に使用します。 |
| allowed-tools | ["AskUserQuestion","Read","Bash","Glob","Grep","TaskCreate","TaskUpdate","TaskList"] |
計画・設計・アイデアのあらゆる側面について、私たちが共通の認識に至るまで、徹底的に質問攻めにしてください。設計ツリーの枝を1つずつたどり、決定事項間の依存関係を順番に解消していきましょう。
質問のルール
AskUserQuestion ツールを必ず使いますquestions 配列には要素を1つだけ入れ、必ず1問ずつ質問します- 抽象度の高い質問から始め、回答を踏まえて具体的な質問に絞り込みます（詳細が不明でも会話を始められ、認識のずれを早期に発見できるため）
- 各選択肢の
description フィールドに、その選択がもたらす意味やトレードオフを簡潔に書きます
各質問文は「背景 → 質問」の2部構成にし、AskUserQuestion の question フィールドにこの順で入れます。背景と質問の間には空行を1つ入れて区切ります。
- 背景（接頭辞「背景：」＋1〜2文）：この質問をなぜ今するのかを書きます。これまでの回答（例：ユーザーがAと答えたので、次にBを確かめたい）や、コードベースの調査で得た事実を根拠に、この質問への答えで何が決まるかまで示します。背景が伝わると、ユーザーは何を答えればよいか分かり、的確に答えられます。
- 質問（接頭辞「質問：」＋1文）：「はい」「いいえ」で答えられる肯定文にします。推奨される選択肢が「はい」になるように組み立てます（否定文は理解しにくく、計画を前進させる方向に答えやすくするため）。
背景・質問のどちらにも「質問文の書き方」のルールを適用します。
例：
背景：先ほど私たちは「システムは画面からの入力だけでデータを受け取る」と決めました。システムが画面から受け取ったデータをどこまで残すかによって、保存層の設計が必要かどうかが変わります。
質問：ユーザーがブラウザを閉じた後も、入力されたデータを保持しますか？
質問文の書き方
質問文がわかりにくいと正しく答えられないため、以下のルールで書きます。
- 複合名詞（名詞を助詞なしで直接つなげる形）を避け、「の・による・に関する」等の助詞を補って修飾関係を明示します
- 指示語（「この」「その」など）が指す対象を明示し、必要に応じて名詞を補います（「この入力」→「画面から受け取ったデータ」）
- 冗長な表現を短くします（「することができますか」→「できますか」、「する必要がありますか」→「しますか」）
- 主語が不明な受動態を避け、動作の主体を明示します（「処理が行われますか」→「システムが処理しますか」）
- 一文に動作主体が複数現れて読みにくいときは、文脈から明らかな主体（多くは設計対象のシステム）を省き、それ以外の主体だけを明示します（「システムは、ユーザーがブラウザを閉じた後もデータを保持しますか」→「ユーザーがブラウザを閉じた後も、データを保持しますか」）
- 抽象的な表現を避け、具体的な事象や条件で書きます（「大きな変更ですか」→「既存の動作が変わりますか」、「セッションが終了した後」→「ユーザーがブラウザを閉じた後」）
タスク登録（実行開始時に必ず実施）
フローを開始する前に、全ステップをTaskCreateで登録します。各ステップを開始するときTaskUpdateでin_progressへ、完了したときcompletedへ更新します。
| # | subject | blockedBy |
|---|
| 1 | コードベース調査 | — |
| 2 | 質問の実施（全分岐の解消まで反復） | 1 |
| 3 | 合意内容のまとめ | 2 |
流れ
- コードベースを調査すれば答えが得られる疑問はツールで先に確認し、質問に反映させます
- もっとも根本的な決定事項から質問を始めます
- 回答を受け取ったら、その回答を踏まえて次の質問を決定します
- すべての分岐が解消されるまで1問ずつ繰り返します
- すべて解消したら、合意した内容をまとめて提示します
