Communitygithub.com

scout

問題やアイデアに対して、「完了」とは何かを明確にし、そこに至るまでの未解決の疑問を幅広く洗い出し、一つずつ解決していくことで経路を明らかにします。

scout とは?

scoutは、AIエージェントが漠然とした問題やアイデアに対して、「どこに向かって進むべきか」と「そこにどうやって到達するか」を明確にするためのスキルです。従来のスキルが既に決まった目標を前提としているのに対し、scoutは目標そのものを発見・定義する役割を担います。このスキルは、ユーザーが「完了」の状態を定義することから始め、目的地と現状の間にある未解決の疑問を幅広く収集(幅優先探索)し、それらを一つずつ解決していくことで明確な経路を導き出します。コードの実装や詳細な仕様書の作成は行わず、あくまでも意思決定のプロセスを支援します。主に開発初期の「どこから手をつければいいかわからない」段階で有効であり、Claude Codeのようなプラットフォームで使用されることを想定しています。scoutはデフォルトで1セッション内で完結するよう設計されており、必要に応じてhandover-saveでセッションをまたぐことも可能です。

対応✓Claude Code~Codex CLI~Cursor
npx skills add AhmedMerza/claude-skills

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

/scout — 私は実際どこへ向かっているのか、そしてどうやってそこへ行くのか?

あなたには問題やアイデアがあり、正直なところどう扱えばいいかわからない状態です。「三つのアプローチのうちどれか」という段階ではありません。まだ遠くの終点を十分に見通せないので、三つものアプローチを考えることができません。このコレクションの他のすべてのスキルは、目標がすでに存在することを前提としています。これだけが、目標を見つけに行くスキルです。

仕事は地形を調査し、それからルートを選ぶことです。目的地に突進することでも、最初に作れそうなものを作り始めることでもありません。

これが何でないか — 適切なものを呼び出すために:

  • grill-me ではありません。grill-meはすでにある計画について、深さ優先で一つの決定木を進みながらインタビューします。これは計画が存在する前に実行され、意図的に幅優先で進みます。scoutが終了したら、grill-meは妥当な次のステップです。
  • explain ではありません。explainはすでに存在するコードをマッピングします。これは存在しない作業をマッピングします。
  • root-cause ではありません。root-causeは既知の症状を持つ壊れたもののためのものです。何かが失敗している場合はまずそれを呼び出し、修正が明らかでなければ、その対応をscoutで探索します。
  • validate-plan / ship-check ではありません。それらは計画と差分を評価します。Scoutはそれらの上流で実行され、それらが評価するものを生成します。

自制ゲート — 最初に読んでください。 失敗パターンは、無理やり旅を作り出すことです。最初のパスで目的地とそこへのステップをすでに述べられることが示されたなら、そう言って止めてください:「これはスカウトを必要としません — 計画はこちらです。実行してください。」ほとんどの問題はそのようなものです。明確な道筋に対する儀式的な手続きは、純粋なコストです。同様に、ユーザーが /scout と入力したのではなく、あなたがこのスキルを使おうとした場合は、開始する前に確認してください。要求されていない20の質問インタビューは悪い驚きです。

パス

1. 目的地に名前を付ける — 他のどの質問よりも先に

完了がどのようなものかを尋ね、それを1行か2行にまとめます。それは、決定が確定した状態、引き渡すべき仕様、その場で完了した移行、エンドツーエンドで動作する機能かもしれません。目的地が異なればまったく異なるルートが生まれるため、これは最初に確定され、決して推測されません。

目的地はスコープを固定します。以下のすべての質問はそれに対して測定されます。ユーザーがまだ目的地を名付けることができない場合、それが最初に取り組むべきことであり、名前が付けられるまでは何も始まりません。

2. 幅を広げる — 幅優先で、答えようとするのを抑える

ここから目的地までの空間全体をスキャンし、未解決の質問を収集します。まだどれも解決しようとしないでください。質問1にすぐに答えたいという衝動は、このパスが打ち負かそうとしているものです。最初に気づく質問が形状を決定することはめったになく、早期に答えることは間違ったものを非常に注意深く計画することを意味します。

深くではなく、広く進みます。知らなかった質問を表面化させることを目指します。

調べられる事実は調べ、決定事項は尋ねます。 何かが確認可能な場合(スキーマ、呼び出し元、実際のデータ、ライブラリのドキュメント、コードが現在実際に何をしているかなど)、質問に時間を費やさずに確認しに行ってください。真の決定事項だけがユーザーに送られます。

3. 三つのバケットに分類する

バケットテストあなたがすること
シャープ質問を正確に今述べることができるそれを解決する(パス4)
曖昧質問があることは感じられるが、まだ表現できない大まかな一文で書き留め、放置する
スコープ外目的地を超えている書き留める;戻ってこない

シャープ/曖昧のテストは、それを述べることができるかどうかであり、それに答えられるかどうかではありません。答えが難しい、または未知の質問でも、正確に表現できるならシャープです。それらはしばしば最も重要な質問です。

スコープ外は異なるテストを使います — スコープ、シャープネスではなく。何かが完全にシャープでも、目的地を超えているためスコープ外になることがあります。それを明示的に除外し、その理由を述べてください。目的地自体が動かない限り戻ってくることはなく、それは新しいスカウトです。

次に、シャープな質問を何が最も多くのものをブロック解除するかで順序付けます — 最も多くの他の質問をなくす答えが最初に来ます。

4. 一つずつ解決する

一度に一つの質問をし、待ちます。それぞれの質問に対してあなたの推奨する答えを添えてください — しかしそれは推奨であり、決定はユーザーのものです。彼らに代わって決定に答えてはならず、質問をまとめて送ってはいけません。五つの壁は混乱を招き、怠惰な返信を一つ得るだけです。

各回答の後、バケットを更新します:

  • それは曖昧さを研ぎ澄まして、本当の、述べられる質問にしましたか? 昇格させてください。
  • それはもはや重要でない質問を殺しましたか? 削除してください。
  • それは目的地を動かしましたか? それを大声で伝え、新しい目的地に対して他のバケットを再チェックしてください。すべては古い線に対して測定されていました。

見栄えを良くするために曖昧さを偽の質問に事前にスライスしないでください。曖昧さは道標であり、TODOリストではありません。

5. 経路が明確になったら停止する

完了とは:シャープな質問が残っておらず、残っている曖昧さが本当に延期可能であるか、またはスコープ外であることを意味します。目的地、そこに至るまでの決定事項、そして具体的な次のステップを添えて締めくくります。

そして引き継ぎます — 構築しません。 スカウトはルートを生成しますが、成果物は生成しません。計画モード(またはそこから計画が出てきた場合は /validate-plan)に進み、その後実装します。スカウト内でプロダクションコードを書いていることに気づいたら、スキルをオーバーランしています。

唯一の例外は使い捨てです。質問が紙の上で本当に解決できない場合(「この状態モデルは正しく感じられるか」、「これはどのように見えるべきか」)、それに答える最小のラフなものを作り、それを見て、答えを保持し、コードを捨てます。

セッションをまたぐ — 本当に必要な場合のみ

デフォルトは1セッション、成果物なしです。ほとんどのスカウトはこれに収まり、20分後に終了した会話のために書かれたファイルは単なるゴミです。

以下のいずれかが真である場合にのみ、/handover-save にエスカレーションします:

  • セッションが長くなりすぎて、流れを見失いそうな場合、
  • ユーザーが停止して後で再開したい場合、
  • 質問が会話の外の何か(他の誰かの回答、プロビジョニングへのアクセス、最初に収集するデータ)によってブロックされている場合。

引き継ぎドキュメントは、目的地と3つのバケットを保持します。/handover-resume で再開し、続行する前にドリフトを再同期します。セッションにまたがることは、ここでは避難ハッチであり、設計ではありません。

出力の形式

マップが実質的に変化したときに表示します。目的地が命名された後、幅出しの後、そして答えがバケットを再編成するたびに。毎ターンではありません。

## スカウティング: <アイデアを一行で>

**目的地:** <完了の状態 — 以下のすべてはこれに対して測定されます>

**決定済み**
- <質問> → <答え>

**未解決 — シャープ**
1. <正確に述べられた質問>   ← 現在これに取り組んでいます
2. <...>

**まだ曖昧**
- <大まかな一文> — <X>が解決されたら明確になります

**スコープ外**
- <除外されたもの> — <それが目的地を超えている理由>

締めくくり:目的地、順序付けられた決定事項、そして唯一の次のステップ。

ガードレール

  • 深さより先に幅。 空間全体を見る前に最初の質問に答えることは、このスキルが防ごうとしている失敗です。
  • 質問せずに調べる。 grepで答えられた質問は、ユーザーのターンと忍耐を無駄にします。
  • 一度に一つの質問、そして待つ。 毎回答えを推奨し、決して彼らに代わって決定しないでください。
  • シャープネス ≠ 回答可能性。 曖昧さテストは「それを述べられるか」であり、「それに答えられるか」ではありません。
  • 曖昧さはバックログではない。 それを緩く残しておいてください。事前にチケットにスライスすることは、次の答えが削除するかもしれない作業を発明することになります。
  • スコープ外はスコープの判断であり、ステップではない。 それは独自のバケットに入れられ、決して決定事項リストには入りません。
  • 目的地は動く可能性がある — 動いたら発表すること。 黙って目的地を変更すると、その前に行われたすべての判断が無効になります。
  • 構築しない。 成果物ではなく決定事項を出力します。使い捨てプロトタイプは唯一の例外です。
  • デフォルトではファイルを作成しない。 /handover-save は、作業が本当にセッションを超えた場合のみ。
  • 自制ゲート。 「ここに曖昧さはありません — あなたはこれをどうやるかすでに知っています」は、実際の価値ある結果です。スキルを実行することを正当化するために、未解決の質問を発明しないでください。

目的地優先の枠組み、幅優先の展開、状態を述べることと答えることの曖昧さテスト、およびスコープ対シャープネスの分割は、Matt Pocock の wayfinder (github.com/mattpocock/skills) から適応しました。そのイシュートラッカーマップ、子チケット機構、および1セッション1チケットのルールは意図的に削除されています。このコレクションは /handover-save を使用してセッションをまたいで存続します。

関連スキル