x-grill-me

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. 背景（接頭辞「背景：」＋1〜2文）：この質問をなぜ今するのかを書きます。これまでの回答（例：ユーザーがAと答えたので、次にBを確かめたい）や、コードベースの調査で得た事実を根拠に、この質問への答えで何が決まるかまで示します。背景が伝わると、ユーザーは何を答えればよいか分かり、的確に答えられます。
2. 質問（接頭辞「質問：」＋1文）：「はい」「いいえ」で答えられる肯定文にします。推奨される選択肢が「はい」になるように組み立てます（否定文は理解しにくく、計画を前進させる方向に答えやすくするため）。

背景・質問のどちらにも「質問文の書き方」のルールを適用します。

例：

背景：先ほど私たちは「システムは画面からの入力だけでデータを受け取る」と決めました。システムが画面から受け取ったデータをどこまで残すかによって、保存層の設計が必要かどうかが変わります。

質問：ユーザーがブラウザを閉じた後も、入力されたデータを保持しますか？

質問文の書き方

質問文がわかりにくいと正しく答えられないため、以下のルールで書きます。

• 複合名詞（名詞を助詞なしで直接つなげる形）を避け、「の・による・に関する」等の助詞を補って修飾関係を明示します
• 指示語（「この」「その」など）が指す対象を明示し、必要に応じて名詞を補います（「この入力」→「画面から受け取ったデータ」）
• 冗長な表現を短くします（「することができますか」→「できますか」、「する必要がありますか」→「しますか」）
• 主語が不明な受動態を避け、動作の主体を明示します（「処理が行われますか」→「システムが処理しますか」）
• 一文に動作主体が複数現れて読みにくいときは、文脈から明らかな主体（多くは設計対象のシステム）を省き、それ以外の主体だけを明示します（「システムは、ユーザーがブラウザを閉じた後もデータを保持しますか」→「ユーザーがブラウザを閉じた後も、データを保持しますか」）
• 抽象的な表現を避け、具体的な事象や条件で書きます（「大きな変更ですか」→「既存の動作が変わりますか」、「セッションが終了した後」→「ユーザーがブラウザを閉じた後」）

タスク登録（実行開始時に必ず実施）

フローを開始する前に、全ステップをTaskCreateで登録します。各ステップを開始するときTaskUpdateでin_progressへ、完了したときcompletedへ更新します。

#	subject	blockedBy
1	コードベース調査	—
2	質問の実施（全分岐の解消まで反復）	1
3	合意内容のまとめ	2

流れ

1. コードベースを調査すれば答えが得られる疑問はツールで先に確認し、質問に反映させます
2. もっとも根本的な決定事項から質問を始めます
3. 回答を受け取ったら、その回答を踏まえて次の質問を決定します
4. すべての分岐が解消されるまで1問ずつ繰り返します
5. すべて解消したら、合意した内容をまとめて提示します