search-first

概要: 検索先行型 skill

search-first とは

search-first skill は、コードを書く前に既存のツール、ライブラリ、実装パターンを調べるための「調査先行」のワークフローです。まずは推測で実装するのではなく、慎重に探索する役としてアシスタントを使いたいときに向いています。

どんな人に向いているか

新しい機能の着手、依存関係の評価、統合の追加、すでに存在するかもしれない補助ツールの作成を始めるときに、search-first skill を使ってください。特に、ゼロから新しく考えるのではなく、実績のあるパターンを再利用したい search-first for Skill Scaffolding の用途と相性が良いです。

重要な理由

この skill の最大の価値は、判断の質を上げることです。コードを提案する前に、npm、PyPI、GitHub、Web ソース、関連 skill を横断して検索するよう促します。その結果、重複作業を減らし、依存関係の選定精度を上げ、build vs adopt vs wrap の判断をより説明可能にできます。

search-first skill の使い方

インストールして起動する

search-first install の場合は、npx skills add affaan-m/everything-claude-code --skill search-first で skill を追加します。「X を追加したい」「Y に使えるライブラリを探したい」「これより良い方法はもうないのか」といった依頼で起動してください。search-first usage の流れは、実装より先に調査を明示的に求めるときに最も効果を発揮します。

判断材料が伝わる依頼文にする

弱い依頼文は「ファイルパーサーを作って」です。より強い依頼文は、たとえばこうです。「Node 18 向けの TypeScript ファイルパーサーが必要。streaming 対応、native deps 不可、MIT license を優先。adopt-or-build の候補を 3 つ、トレードオフ付きで出してほしい。」この形なら、skill が十分な文脈をもとに検索し、候補を比較できます。曖昧な提案で終わりにくくなります。

まず読むべきファイルを押さえる

最初に SKILL.md を読み、その後で README.md、AGENTS.md、metadata.json、さらに存在するなら rules/、resources/、references/、scripts/ フォルダを確認してください。この repo では SKILL.md が一次情報なので、補助ファイルを探し回らずに素早く進められます。

ワークフローをプロンプトのひな形として使う

実用的な search-first guide のプロンプトには、必要性、制約、候補検索、評価基準、そして明確な判断を含めるとよいです。たとえば、「X の既存 विकल्पを調査し、3 候補を maintenance、docs、license、fit で採点したうえで、adopt、extend、build custom のどれを推奨するか示してほしい」といった形です。この構造にすると、researcher agent が雑な一覧ではなく、使える出力を返しやすくなります。

search-first skill の FAQ

search-first は大規模プロジェクトだけのもの？

いいえ。むしろ、helper 関数、UI ユーティリティ、依存関係の選定のように、気づかないうちに tech debt を生みやすい小さなタスクでこそ価値があります。調査を省いたときのコストは、変更が一見シンプルに見えるほど大きくなりがちです。

通常のプロンプトと何が違うの？

通常のプロンプトはアイデアを求めるだけかもしれませんが、search-first skill は調査ワークフローと意思決定を求めます。この違いは重要です。出力の目的が「何を書けるか」ではなく、「採用するかどうかの判断」を支えることだからです。

初心者でも使いやすい？

はい。目的と制約を説明できるなら使えます。初心者にとっては、検索範囲を絞り、知らなかった既存 विकल्पを見つけやすくなるのが利点です。ただし、トレードオフの分析なしにすぐコードが欲しい場合は、効果は小さくなります。

使わないほうがよいのはどんなとき？

明らかに独自実装が必要なとき、時間制約が厳しすぎるとき、あるいはコードベース内で閉じた非常に局所的な作業で外部解が現実的に当てはまらないときは、使わないほうがよいです。すでに使いたい package や pattern がはっきり決まっているなら、フル検索より直接実装のほうが速いこともあります。

search-first skill を改善するには

検索内容を変える制約を最初に出す

品質を最も大きく上げるのは、language、runtime、framework、license、bundle size、security rules、platform 制約、native dependencies の可否といった厳しい条件を最初に明示することです。こうした情報があると、skill は人気はあるが実際には使えない候補を避けて絞り込めます。

推奨だけでなく比較を求める

より良い search-first usage の依頼は、短い候補リストと理由付きの推奨を求めます。たとえば、「3 つの library を比較し、それぞれが失敗しうる理由も説明したうえで、production 用と fallback 用を 1 つずつ選んでほしい」といった形です。これなら、単独名の回答よりずっと実用的な調査結果になります。

表面的な新しさバイアスに注意する

よくある失敗は、最も新しい、あるいは最も目立つ project を選んでしまい、maintenance、docs、統合コストを確認しないことです。search-first skill には、導入時の摩擦、エコシステムとの適合性、そして候補を不採用にする条件まで含めるよう求めると改善します。

最初の結果を受けて繰り返す

最初の結果が広すぎる場合は、次のプロンプトで不足している制約を 1 つだけ追加するか、受け入れ条件を 1 つだけ絞ってください。search-first for Skill Scaffolding なら、対象言語、repo 構成、再利用したい scaffold の具体的な種類を足すのが有効です。