mcpField
T
turn-based-discovery

turn-based-discovery

github.com/alber70gエージェントワークフロー049 回インストール3 日前に更新
リポジトリ

turn-based-discovery について

turn-based-discoveryは、作業の前や途中で曖昧さを解消するスキルです。構造化された選択式の質問で素早く判断を集め、自由形式の回答にも対応します。

主な機能

  1. 01AskUserQuestionで質問
  2. 021回につき最大4問をまとめて提示
  3. 03各質問に2~4個の実質的な選択肢
  4. 04進行を妨げる不明点のみ質問

活用シーン

  1. 01曖昧な依頼の着手前に要件を確認
  2. 02調査後に未決事項を素早く解決
  3. 03重要な分岐で判断を得る

インストール

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

$npx skills add https://github.com/alber70g/skills --skill turn-based-discovery

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

詳細

ターン制の確認

目的

深掘りではなく、明確化を目指します。文章で問い詰める代わりに、自由形式の回答に切り替えられる選択式の質問を使います。

これは深掘りするためのインタビューではありません。明確化のためのツールです。次のような場合に役立ちます。

  • 依頼が曖昧で、作業に取りかかる前にいくつか決める必要がある場合
  • 調査の結果、すぐに回答してほしい未解決の質問が見つかった場合
  • 重要な細部を推測で補うことになりそうな場合

ルール

  1. AskUserQuestion ツールを使います。 ツールで質問できる場合は、文章で質問しないでください。このツールは自由形式の「その他」オプションを自動で追加します。自分で追加しないでください。
  2. 1回の呼び出しで最大4つの質問をまとめます(ツールの上限です)。回答が必要な未確定事項が本当に5つ以上ある場合は、最初の回答が返ってきてから2回目の質問を送ってください。数合わせの質問を追加しないでください。
  3. 作業を妨げていることだけを尋ねます。 ファイルシステムから確認できること、推測できること、安全に仮定できることは、自分で確認または判断してください。
  4. 各質問に十分な文脈を含めます。 ユーザーが質問の意図を推測する必要がないようにしてください。関連するファイル、ディレクトリ、最近の調査結果、制約、リポジトリの状態が判断に関わる場合は、簡潔に説明してください。特定のファイルが対象なら、その名前を明示してください。
  5. 各質問には現実的な選択肢を2~4個用意します。 それぞれ、ユーザーが実際に選びうる別個の選択肢にしてください。自分の望む回答に誘導するための見せかけの選択肢は避けてください。
  6. 誘導ではなく、明確さを重視して表現します。 すでに決めつけた内容への同意を求めるのではなく、ユーザーが本当に望んでいることを明らかにしてください。推奨案を示してもかまいません。その場合は (Recommended) と記し、[...] に入れてください。

質問の形式

AskUserQuestion に渡す各質問には、次の要素が必要です。

  • question — 明確で、疑問符で終わる質問。
  • header — 12文字以内で、判断の軸を示すもの(例:「範囲」「保存先」「形式」)。
  • options — 別個の選択肢を2~4個。それぞれに次の要素を含めます。
    • label — 1~5語。
    • description — 選んだ場合に何を意味するかを1行で説明します。
  • multiSelect — デフォルトは false です。選択肢を組み合わせて選べる場合に限り true にします。

このツールは自由形式の回答用に「その他」を常に追加します。重複して追加しないでください。

使用する場面

  • 調査や探索の結果、未決定の事項が見つかった後。
  • 依頼に実質的な曖昧さがあり、作業を始める前に確認が必要な場合。
  • 作業の途中で、尋ねるのは簡単でも、誤った推測の代償が大きい分岐点に直面した場合。
  • 質問をした後でも不明確な点や曖昧さが残る場合。ユーザーが別の方向性を望んでいる場合や、回答によって方向性が分岐する場合などが該当します。

使用しない場面

  • 文脈、ファイル、以前の会話から答えが明らかな場合。
  • 質問の答えが作業に与える影響が小さく、後から簡単に変更できる場合。そのまま決めて進めてください。
  • すでに実装の途中で、質問すること自体が形式的になってしまう場合。
  • ユーザーが「そのまま進めて」や「お任せします」と言った場合。

例

良い例 — 質問をまとめて確認する

選択肢を調査した後、2~4個の質問をまとめて尋ねます。

  • 保存先:「結果はどこに保存しますか?」→ SQLite / Postgres / JSON ファイル / メモリ上のみ
  • 起動方法:「ジョブをどのように開始しますか?」→ 手動で CLI を実行 / Cron / ファイル変更時 / HTTP エンドポイント
  • 出力:「どの形式で出力しますか?」→ JSON / Markdown / プレーンテキスト

ユーザーは3つすべてに回答し、合わない選択肢があれば「その他」を選びます。その後、作業を進めます。

良い例 — 1つだけ確認する

不明点が1つだけなら、質問も1つだけにします。4つに増やして数を合わせないでください。

悪い例 — 見せかけの選択肢

「Postgres を使いますか?」→ はい / キャッシュ付きではい / たぶん / いいえ

どの選択肢も Postgres を使うことになります。現実的な別の選択肢を用意するか、質問しないでください。

悪い例 — 些細な質問

「先ほど言っていたファイルの名前は何ですか?」

会話やファイルシステムで確認できる場合は、自分で見つけてください。尋ねないでください。

アンチパターン

  • 長々とした質問 — ツールを使い、まとめて質問してください。
  • 数合わせの水増し — 内容のある質問が2つあれば、埋め草を含む4つよりも優れています。
  • 「その他」を手動で追加する — ツールが追加するため、自分で追加すると選択肢を1つ無駄にします。
  • 決定後に質問する — すでに着手しているなら、相談するふりをしないでください。
  • 深い質問の連鎖 — このスキルの目的は明確化であり、尋問ではありません。質問1への回答を基に質問5を考えているなら、使うモードが違います。代わりに brainstorming スキルを使ってください。
  • 早く切り上げる — 質問したら、その内容を振り返り、追加の質問が必要か確認してください。必要なら続けてください。ユーザーは、以前のターンですでに質問に回答したことや、以前の想定が間違っていたことを伝える場合があります。その場合は、回答を無理に求めるのではなく、質問を修正してください。

他のモードとの連携

  • プランモード:計画に必要な情報を集めるために使います。ここから ExitPlanMode を呼び出さないでください。
  • ブレインストーミングスキル:1つずつ深く掘り下げる必要がある場合は、brainstorming に任せてください。その役割を担うのはこのスキルです。
  • 自動モード:引き続き適用されます。ユーザーがこのスキルを明示的に呼び出した場合は、質問してください。

ツールを呼び出す前のチェックリスト

  • それぞれの質問は、進行を妨げる要因を解消するために本当に必要ですか?
  • 選択肢はそれぞれ明確に異なっていますか?
  • ユーザーが推測せずに回答できるよう、十分な背景情報を含めましたか?
  • 関連するファイル、パス、リポジトリの状態が重要な場合、それらを参照しましたか?
  • 1回の呼び出しにつき4つ以下にしましたか?
  • 「その他」はツールに任せましたか?

どれか1つでも「いいえ」なら、呼び出す前に修正してください。

コメント