clarify:unknown

未知：既知／未知の四象限で盲点を明らかにする

既知／未知の四象限フレームワークと仮説に基づく質問を使って、あらゆる戦略、計画、意思決定に潜む前提や盲点を明らかにします。

使用する場面

• 精査が必要な戦略文書や計画文書
• 方向性が不明確、または隠れた前提がある意思決定
• 「わかっていること」よりも「わかっていないこと」が重要なあらゆる状況

具体的な要件の明確化（機能リクエスト、バグ報告）には、vague スキルを使用してください。内容と形式の見直し（既存の形式の中で最適化するか、新しい形式を生み出すか）には、metamedium スキルを使用してください。

中核となる原則：選択肢としての仮説

R1／R2／R3 のすべての質問で、必ず AskUserQuestion ツールを使用してください。質問を通常のテキストで尋ねてはいけません。構造化された形式によって、仮説を選択肢として提示することを徹底し、選択による負担を抑えます。

自由回答形式の質問ではなく、仮説を選択肢として提示してください。仮説そのものが分析です。よい選択肢を設計すれば、ユーザーが回答する前に分析作業の 80％ が完了します。ユーザーの役割は、仮説を確認、修正、または予想外の回答で覆すことです。

BAD:  "Why can't you do video content?"           ← open question, high load
GOOD: "Time / Skill gap / No guests / High bar"   ← pick one or more

• 各選択肢は、ユーザーの状況について検証可能な仮説です
• 複合的な要因も捉えられるよう、multiSelect: true を使用します
• フレームに収まらない回答を選べるよう、「Other」は常に用意します

3 ラウンドの深掘りパターン

ラウンド	目的	質問数	主な特徴
R1	草案の四象限分類を検証する	3-4	幅広く、すべての象限を網羅
R2	弱点を深掘りする	2-3	R1 の回答に基づいて対象を絞る
R3	実行の詳細を詰める	2-3	具体的で、任意

重要：ラウンド N の質問は、ラウンド N-1 の回答を基に作成してください。ラウンドをまたいで事前に用意した質問を使用してはいけません。質問の合計は 7～10 件までにしてください。

プロトコル

フェーズ 1：情報の受け取り

ファイルが提供された場合：目標、構成要素、暗黙の前提、不足している要素を読み取り、抽出します。

トピックのキーワードのみの場合：まず R1 の質問を直接行い、対象範囲を定めます。フェーズ 3 の草案は大まかなものになりますが、R1 で修正します。

フェーズ 2：コンテキスト

関連するコンテキストを集め、Unknown Knowns、つまりユーザーが自分の保有に気づいていない可能性のある資産を探します。

• 関連ファイルを Glob で検索します。対象は CLAUDE.md、README、意思決定記録、プロジェクト内の過去の分析などです
• Read でプロジェクトのコンテキストを確認します。最近の目標、チーム構成、進行中の取り組みなどです
• 活用が不十分な資産を特定します。使われていない既存のツール／スキル、再利用可能なパターンがある過去のプロジェクト、活用されていないチームの専門知識などです

ここで見つかった項目は、UK の候補として R1 の質問に選択肢として含めます。

フェーズ 3：草案の作成と R1 の質問

最初の四象限分類を作成します。草案は意図的に大まかなものにします。R1 の目的は草案を確認することではなく、修正することです。不確かな項目は、KK ではなく KU に分類する方向で判断してください。

四象限の境界を検証する R1 の質問を作成します。R1 の質問はすべて、1 回の AskUserQuestion 呼び出しにまとめてください（最大 4 問）。

対象	パターン	例
KK	「本当に確かなことですか？」	「主な収益源は何ですか？」（選択肢）
KU	「最も弱い箇所はどこですか？」	「どのフライホイールのつながりが最も弱いですか？」
UK	「存在するのに使われていないものは何ですか？」	コンテキストで見つかった情報に基づく
UU	「最大の懸念は何ですか？」	リスクシナリオを選択肢として提示

フェーズ 4：深掘りと R2 の質問

R1 の回答を分析し、最も不確かな領域を見つけて深掘りします。

R2 の開始条件：複合的な回答（状況が複雑）、予想外の回答（草案が誤っている）、または「Other」が選択された場合（想定外の枠外の回答）。

R2 の質問タイプの詳細については、references/question-design.md を参照してください。

フェーズ 5：実行と R3 の質問（任意）

優先順位を決めたら、上位の項目について実行の詳細を詰めます。R2 ですでに十分な詳細が得られている場合は省略します。

フェーズ 6：プレイブックの出力

構造化された四象限のプレイブックファイルを作成します。出力テンプレートの全体については、references/playbook-template.md を参照してください。

出力構造：

# {Topic}: Known/Unknown Quadrant Analysis

## Current State Diagnosis
## Quadrant Matrix (ASCII with resource %)
## 1. Known Knowns: Systematize (60%)
## 2. Known Unknowns: Design Experiments (25%)
   - Each KU: Diagnosis → Experiment → Success Criteria → Deadline → Promotion Condition
## 3. Unknown Knowns: Leverage (10%)
## 4. Unknown Unknowns: Set Up Antennas (5%)
## Strategic Decision: What to Stop
## Execution Roadmap (week-by-week)
## Core Principles (3-5 decision criteria)

リソースの割合（60/25/10/5）はデフォルト値です。 コンテキストに応じて調整してください。たとえば、プロダクト・マーケット・フィットを模索するスタートアップでは、KU に 40％、KK に 30％を割り当てることがあります。

アンチパターン

• 自由回答形式の質問（「何をしたいですか？」）— 仮説の選択肢を使います
• 1つの質問に選択肢が5つ以上ある — 選択疲れにつながります
• R2 の設計時に R1 の回答を無視する — 質問が形骸化します
• すべての象限を同じ深さで掘り下げる — 時間を無駄にし、焦点がぼやけます
• 「やめること」のセクションがない — 何かを減らさずに追加することになります

例

入力：成長戦略ドキュメント

R1：収益源は？ → ワークショップ。最も弱い連携部分は？ → Biz→Knowledge。障壁は？ → スキル不足 + 高いハードル（multiSelect）。最大の懸念は？ → 実行が分散していること。

R2（「実行が分散していること」を踏まえて）：何をやめる？ → プロダクト開発。Knowledge→content に取り組まない理由は？ → プロセスがなく、時間もなく、抽象化が難しい。役割の明確さは？ → 不明確。

R3：動画形式は？ → 画面録画。振り返りを妨げる要因は？ → 何を記録すればよいかわからない。どんなコンテンツに反応があった？ → 生の発見。

主な発見：抽象化は不要 — 生のインサイトのほうが効果的です。3つのボトルネックを15分のパイプラインにまとめました。

ルール

1. 質問ではなく仮説：すべての選択肢を検証可能な仮説にします
2. 回答に応じて掘り下げる：R2 は R1 を、R3 は R2 を踏まえます
3. 質問は最大7〜10個：これを超えると疲れてしまいます
4. 始めることより、やめること：「やめること」を必ず含めます
5. 推進するか、打ち切るか：すべての KU に推進条件と打ち切り条件を設けます
6. 完璧さより、生の試み：完璧な計画ではなく、実用最小限の実験を促します
7. ドラフトは使い捨て：最初の象限は修正することを前提とします

追加リソース

参考ファイル

• references/question-design.md — 各ラウンドの詳細な質問タイプ、トリガー条件、AskUserQuestion のフォーマットガイド
• references/playbook-template.md — セクションごとのガイドを含む完全な出力テンプレート