mcpField
I
inquiring

inquiring

github.com/tejas-kale生産性038 回インストール3 日前に更新
リポジトリ

inquiring について

問いを中心とするインタビュースキルです。証拠から主張ツリーを作り、解釈の違いを検討して、確定事項と未知の点を記録します。提案ではなく、問いへの共通理解を目指すユーザー向けです。

主な機能

  1. 01問いを主張ツリーに分解
  2. 02公開情報を調査し証拠を引用
  3. 03証拠収集とユーザーの解釈を分離
  4. 04ラウンドごとに未解決事項を追跡
  5. 05調査結果と計算成果物を記録

活用シーン

  1. 01グラフが結論を裏付けるか検討
  2. 02結果に対する複数の説明を比較
  3. 03不確実性を記録しながら問いを調査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/tejas-kale/skills --skill inquiring

インストール後、Claude Code で/inquiringを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yaml

詳細

ユーザーにインタビューし、問いについての読み解きを共有できるまで続けます。次に何をすべきかではなく、証拠が何を裏付けているかを読み解きます。これをクレームツリーとして整理します。各クレームは、それに紐づくクレーム(操作的定義、測定値、競合する説明、確信度)へと分岐します。

ツリーをラウンドごとに進めます。フロンティアとは、前提となるクレームがすでに確定しているすべてのクレームのことです。つまり、まだ聞いていない回答を推測せずに、今尋ねられる質問です。まず、証拠から判断できることを埋めます。証拠だけでは決着しないことだけをユーザーに尋ね、その後は待ちます。

証拠を見つけるのはあなたの仕事であり、ユーザーの仕事ではありません。大規模な一次資料の調査には、バックグラウンドのリサーチエージェント(または同等の検索手段)を使います。その調査のために、フロンティアのほかの作業を止めてはいけません。読み解きはユーザーのものです。未確定の解釈を一つずつ提示し、回答を待ちます。操作的定義、サンプルの偏り、グラフから結論への飛躍をストレステストします。ユーザーの事前見解が証拠に耐えるなら、その証拠とともに確定事項として記録します。

意思決定(「何をすべきか?」)が現れたら、それを明示して停止します。クレームの検討に留まり、調査結果をもとに設計のインタビューを始めてはいけません。

ラウンド 0 — 枠組み

問いをスラッグにします。findings/<slug>.md がすでに存在する場合は、それを読み込み直します。確定済みのクレームはそのまま確定とし、現在のフロンティアだけを尋ねます。

それ以外の場合は、取得を始める前に findings/<slug>.md を作成し、再述した問い、提案する操作的定義、対象範囲内のクレーム、未知事項を記載します。以下のラウンド形式で、枠組み(これが問いなのか、公平な測定方法なのか、非公開の制約があるか)を確認します。待ちます。取得を始めるのは、ユーザーがこの枠組みを受け入れるか修正した後のラウンド 1 です。

後続のラウンド

  1. フロンティアにあるすべての公開クレームについて、取得、計算を行い、出典を示します。パラメトリックな知識は仮説であり、発見事項ではありません。一次資料と検証可能な成果物を優先します。ユーザー提供の非公開データと公開情報が食い違う場合は、非公開データを優先し、その食い違いを示します。
  2. 調査結果ファイルを更新します。コードを実行してクレームが確定した場合に限り、ノートブックを開きます(「成果物」を参照)。
  3. チャットを整理します(「チャット」を参照)。残るフロンティア全体について尋ね、待ちます。

回答が同じラウンドでまだ未確定の別のクレームに依存するクレームは、後続のラウンドに回します。

ラウンド形式

前置きは省きます。要点が伝わる最小限のビジュアルを使い、簡潔な説明を添えます。Mermaid、ツリー、または HTML ファイルを使います。ファイル内の該当箇所を示し、調査結果ファイルの内容を貼り付けてはいけません。

データの形をしたビューも、それが最小限の表現なら対象に含まれます。2 軸のスケッチ、小さな比較表、競合する説明を示す Mermaid、テキスト内のスパークライン、注釈付き HTML グラフなどです。装飾目的のものは対象外です。

フロンティアの各項目:

❓ **C1** - **<claim title>**: <one-line claim / operationalization>

**A.** …
**B.** …
**C.** bounded unknown / keep digging

➡️ **B** — <one line why>

選択肢を読むより見るほうが分かりやすい場合は、選択肢の前にビジュアルを 1 つ置いてもかまいません。選択肢 C(または最後の選択肢)は、範囲を定めた未知事項として選べるようにしておきます。正直に提示できる読み解き方が 1 つだけの場合でも、それを選択肢にし、➡️ は必ずその選択肢を示します。

証拠

調査結果ファイルに以下のすべてが記録されるまで、クレームは未確定のままです。

  • クレームを 1 文で記述したもの
  • 操作的定義
  • 方法(検索、取得、クエリ、コード)
  • クレームを検証できるだけの引用または出力を添えた、出典またはセル
  • 検索または実行しなかったこと
  • 方法の不確実性/失敗要因
  • 判定:確定/範囲を定めた未知事項/ユーザーへの確認が必要

成果物

リポジトリでメモの保存に使われている場所にファイルを置きます。保存先がなければ findings/ を使い、そのパスを伝えます。

  • findings/<slug>.md — セッションの正式なクレーム記録です。1 つのファイルにラウンドごとの内容を追記します。再開時は読み込み直します。
  • findings/<slug>.ipynb — 1 セッションにつき最大 1 つとし、最初の計算を伴うクレームの時点で作成します。リポジトリが明らかに別のデータスタックを使っている場合を除き、Jupyter、Python 3、pandas クラスの表形式データ処理を使います。実行するものがなければ、ノートブックは作成しません。
  • view-{description}.html — Mermaid では不十分な場合に、ラウンドのビューとして作成します。一時的なものです。ノートブックですでに表示しているグラフを、選定したフレームが必要な場合を除き、HTML で包んではいけません。

チャットはラウンドを進めるためのプロトコルです。ファイルは証拠の保管場所です。

完了

未解決の論点はありません。対象範囲内の主張はすべて確定しているか、明示的に不明として範囲が限定されており、それぞれに文書上の根拠があります。ここで止めてください。ユーザーが共通認識を確認するまで待ってください。調査結果をもとに設計の聞き取りを始めないでください。

コメント