| name | qbq |
| description | Question Behind the Question — 実装プランを出す前に、要望の下にある設計判断を1段掘り、
「本当に問うべき問い」の候補を提示する。
ユーザーが「/qbq」「問いから掘って」「本当に問うべきことは何?」などと言った時に使う。
また、インフラ・ワークフロー・アーキテクチャ系の相談で、要望の背後に未言語化の
設計判断がありそうな時は、実装プランを提示する直前に自発的にこの手順を提案してよい。
|
/qbq — 問いの再定義
実装プランの前に「この要望の下にある設計判断は何か」を1段掘る。
手段の最適化より「何を問うべきか」の言語化に価値を置く対話スキル。
Question Behind the Question の略。
起動方法
- 明示起動:
/qbq または /qbq <相談内容> — 即実行する
- 引数なし: 直前の会話の要望・相談を対象にする
- 引数あり: その相談内容を対象にする
- 自発提案: 以下をすべて満たすとき、プラン提示の前にこの手順を挟むことを提案する
- インフラ・ワークフロー・アーキテクチャ系の相談である(単純なバグ修正・定型作業の代行は対象外)
- 要望の背後に未言語化の設計判断がありそう(要望が手段を指定している/複数の異なる設計が同じ表面要望を満たしてしまう)
- このセッションで同じ対象にまだ qbq を実行していない
手順
- 表面の要望を1行で言い直す — 認識ズレがあればここで判明する
- 問いを階層化する — 「表面の修正 → 構造・役割の設計 → 責務の分担 → 選択肢の再定義」の深さ方向に、
この要望の下にある設計判断を 2〜4個の候補の問いとして書き出す
(例: パス修正 → 2台のマシンの役割設計 → パイプラインの責務 → 一本化という選択肢)
- 各問いの分岐を1行ずつ添える — 「この問いが本命なら、答え(プラン)はこう変わる」
- 推奨の問いを1つ選び、理由を添えて提示する — AskUserQuestion が使える環境では選択肢として提示する。
深掘りの質問が返ってきたら、答えてから選択肢を再提示する
- 合意した問いに沿って、通常のプラン提示に戻る
- 決まった設計原則は明文化する — dotfiles では docs/explanation/architecture.md /
llm/context/environment.md が置き場。設計比較に発展したら ADR 化を提案する
外形化チェック
自己内省を命じる代わりに、チェック可能な形式で書く:
- 提示する問い・プランに対して「この前提が崩れたら成立しない、という前提を1つ」明示する
- 実在確認していないファイル名・API名・設定キーを問いや選択肢に含めない
実行環境フォールバック
- AskUserQuestion が使えない環境(Copilot CLI 等)では、番号付き選択肢のテキスト提示で代替する
由来
対話フィードバック記憶「question-behind-the-question」(2026-07-06 の WSL 環境差分相談が起源)の
skill 化(Issue #481)。常駐版の記憶は AgentMemory vault 側に残る — 記憶が「なぜ」を、
この skill が「手順」を持つ役割分担。
