research-scoping

調査スコーピング

実際にトークンを費やすと決める前に、質問の全体像を把握するための、単一コンテキストでのトリアージです。Stanford の STORM メソッドにある多角的な検討を、1つのプロンプトに凝縮して実行します。質問が求める視点を見つけ、意見が対立する箇所を明らかにし、完全な回答の構成案を描き、そのうえでインラインで対応するか、エスカレーションするかを判断します。情報の検索も引用も行いません。出力するのは、追究すべき問いとして示した地図と計画であり、答えではありません。

その価値は、経済面と分析面の両方にあります。完全な COMPLEX /ann の実行には数十万トークンがかかりますが、このパスはサブエージェントに展開せず、1つのコンテキストでその一部のコストしかかかりません。そのため、大規模な実行を省けることもあれば、担当者の構成を絞り込み、より的確に大規模な実行を行えることもあります。

使い分け — このスキルを使うとき、他のスキルではなく

• research-scoping（このスキル）：低コストの1回のパスで質問の視点と緊張関係を整理し、トリアージします。検索、引用、サブエージェント、成果物はありません。
• /grill-mel：Ane がすでに持っている設計を磨くため、Ane に一度に1つずつ質問します。research-scoping は逆方向に働き、インタビューをせずに Ane へ地図を渡します。
• /ann：成果物を作成するための完全なオーケストレーションです。research-scoping は、その実行に進むかを判断する前に通る入口です。
• /researcher, /evidence-synthesis：実際の情報源を検索し、引用します。research-scoping は決して行わず、質問に証拠が必要な場合はこれらのスキルへ引き継ぎます。
• /decision-debate：争点のある1つの意思決定について、トークンを多く使って複数エージェントで議論します。research-scoping は単一コンテキストで行い、何も起動しません。

質問が成果物を明らかに必要としている場合は、スコーピングを省略し、/ann または適切なビルダーに直接進んでください。

誠実さを構造で担保するルール

このスキルは、IPPF、MA、パートナー、連絡先、数値、日付について、引用を出したり、事実として断定したりしてはなりません。ここで示す内容はすべて、意図的に検証すべき仮説として扱います。権威があるように見える、出典のない簡易マップは、MEL システム全体が防ごうとしている失敗です。そのため、ガードレールは文体ではなく構造で設けます。

• Author (year) 形式の引用は禁止です。フレームワークが関連する場合は、分析の進め方（「対立する説明を検証する」など）に言及し、引き継ぎ用の検証項目リストに追加します。引用はしないでください。
• 事実として断定しないでください。事実が重要となる箇所では、値の代わりに ⚠️ to verify: [what] と記載します。
• 読み手がこのマップを調査結果と誤認しないよう、すべての出力の末尾に以下のバナーを付けます。

方法 — 1つのコンテキストで、展開なし

すべての手順を1回のパスで実行します。質問を理解するために会話や名前を指定したプロジェクトファイルを軽く参照してもかまいません。文献検索を行ったり、専門家を起動したりしないでください。それは引き継ぎ先の役割です。検索や専門家の起動が必要になったなら、このスキルを使う場面ではありません。

1. 質問を言い換える。 範囲を明確にし、共有できるよう、1行で言い換えます。
2. 視点を見つける。 一般的なチェックリストではなく、質問が実際に必要とする4〜6個の切り口を導き出します。これは Vi が SELECT で行うのと同じ手順ですが、単独で、最初に実施します。各切り口には、わかりやすい名前を付けます。
3. 最も鋭い問い。 各視点が最も強く問うであろう質問を1つか2つ挙げます。
4. 緊張関係の整理。 これらの視点が最も意見を異にしそうな箇所を示します。ここが出力の要点です。対立をならした要約ではありません。現在有効な緊張関係を1行ずつ記載します。実質的な緊張関係を3つ見つけられない場合、その質問はおそらく SIMPLE です。
5. 完全な回答の構成。 実際の成果物を依頼された場合にどのような構成にするか、骨子を示します。
6. トリアージの判定。 SIMPLE（今すぐインラインで対応）または COMPLEX（エスカレーション）とします。COMPLEX の場合は、候補となる専門家チームと、検証が必要な主張を挙げます。SIMPLE の場合は、インラインの回答で扱う内容を説明します。

出力形式

毎回、次のテンプレートを使用します。

スコーピングマップ：[質問]

1. 質問 — 質問を一文で言い換えます。
2. 視点 — 4〜6 個の切り口に名前を付けます。
3. 各視点が問うこと — 各視点から投げかける、最も鋭い質問を示します。
4. 対立点 — 意見が分かれる点を、対立ごとに一行で示します。ここが核心です。
5. 回答全体の構成 — 骨子を示します。
6. 判定 — SIMPLE または COMPLEX を示し、推奨する次のステップを提示します。COMPLEX の場合は、候補者リストと ⚠️ 要確認: のリストも含めます。

最後は次の文で締めます。

スコーピングマップであり、調査結果ではありません。 ここに出てくる主張には出典がありません。それぞれの行は回答ではなく、検証すべき仮説として扱ってください。実際の回答を作成するには、このマップを /ann、/researcher、または /evidence-synthesis に渡してください。

常設ルール

• 低コストを保つ。 コンテキストは一つ、サブエージェントは使わず、検索もしません。文献検索が必要になった時点で、引き継いでください。
• 調査先を並べるのではなく、推奨する。 判定では SIMPLE または COMPLEX を選び、次のステップを名指しで示します。選択肢の列挙にはしません。
• 文体。 平易な英語を使います（Flesch-Kincaid グレード 9〜10）。MEL の用語は、初出時に説明します。本文では em ダッシュを使いません。翻訳しやすさを確認します。ルーマニア、チュニジア、エチオピア、ベトナムの英語話者が一読して理解できる表現にしてください。
• 最低 3 つの視点。 発見のための手順として必須です。実質的な切り口が 3 つ未満なら、それ自体が質問は SIMPLE だという兆候です。

締めくくり

マップを提示してから、引き継ぎを提案します。

「マップができました。判定：[SIMPLE / COMPLEX]。これを /ann、/researcher、または /evidence-synthesis に引き継ぎますか。それとも SIMPLE の場合は、このままここで対応しますか？」

このスキル内で成果物の作成を始めないでください。マップが成果物であり、回答の作成は引き継ぎ先で行います。