qbq

name	qbq
description	Question Behind the Question — 実装プランを出す前に、要望の下にある設計判断を1段掘り、 「本当に問うべき問い」の候補を提示する。 ユーザーが「/qbq」「問いから掘って」「本当に問うべきことは何?」などと言った時に使う。 また、インフラ・ワークフロー・アーキテクチャ系の相談で、要望の背後に未言語化の 設計判断がありそうな時は、実装プランを提示する直前に自発的にこの手順を提案してよい。

/qbq — 問いの再定義

実装プランの前に「この要望の下にある設計判断は何か」を1段掘る。 手段の最適化より「何を問うべきか」の言語化に価値を置く対話スキル。 Question Behind the Question の略。

起動方法

• 明示起動: /qbq または /qbq <相談内容> — 即実行する
  • 引数なし: 直前の会話の要望・相談を対象にする
  • 引数あり: その相談内容を対象にする
• 自発提案: 以下をすべて満たすとき、プラン提示の前にこの手順を挟むことを提案する
  • インフラ・ワークフロー・アーキテクチャ系の相談である(単純なバグ修正・定型作業の代行は対象外)
  • 要望の背後に未言語化の設計判断がありそう(要望が手段を指定している/複数の異なる設計が同じ表面要望を満たしてしまう)
  • このセッションで同じ対象にまだ qbq を実行していない

手順

1. 表面の要望を1行で言い直す — 認識ズレがあればここで判明する
2. 問いを階層化する — 「表面の修正 → 構造・役割の設計 → 責務の分担 → 選択肢の再定義」の深さ方向に、 この要望の下にある設計判断を 2〜4個の候補の問いとして書き出す (例: パス修正 → 2台のマシンの役割設計 → パイプラインの責務 → 一本化という選択肢)
3. 各問いの分岐を1行ずつ添える — 「この問いが本命なら、答え(プラン)はこう変わる」
4. 推奨の問いを1つ選び、理由を添えて提示する — AskUserQuestion が使える環境では選択肢として提示する。 深掘りの質問が返ってきたら、答えてから選択肢を再提示する
5. 合意した問いに沿って、通常のプラン提示に戻る
6. 決まった設計原則は明文化する — 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 が「手順」を持つ役割分担。