/search-first — コーディング前に調査する
「既存のソリューションを実装前に検索する」ワークフローを体系化します。
トリガー
以下の場合にこのスキルを使用します:
- 既存のソリューションが存在する可能性が高い新しい機能を開始する場合
- 依存関係やインテグレーションを追加する場合
- ユーザーが「X 機能を追加して」と要求し、コードを書こうとしている場合
- 新しいユーティリティ、ヘルパー、または抽象化を作成する前
ワークフロー
判断マトリクス
使い方
ステップ 0: ツール利用可能性の事前確認
これはエージェントのガイダンスであり、実行可能なセットアップスクリプトではありません。目の前のタスクとプロジェクトに関連するチャネルのみを確認します。
クイックモード(インライン)
ユーティリティを書いたり機能を追加したりする前に、以下を確認します:
- これはリポジトリに既に存在するか? → まず関連モジュール/テストを
rgで確認 - これはよくある問題か? → npm/PyPI を検索
- MCP はあるか? →
~/.claude/settings.jsonを確認して検索 - このためのスキルはあるか? →
~/.claude/skills/を確認 - GitHub に実装/テンプレートがあるか? → 新規コードを書く前に保守された OSS の GitHub コード検索を実行
フルモード(エージェント)
非自明な機能には、researcher エージェントを起動します:
古い Claude Code ドキュメントではこれを Task(...) と呼ぶ場合があります;アクティブなハーネスが公開している現在のエージェント/サブエージェントツール名を使用してください。
カテゴリ別検索ショートカット
開発ツール
- Linting →
eslint、ruff、textlint、markdownlint - フォーマット →
prettier、black、gofmt - テスト →
jest、pytest、go test - プレコミット →
husky、lint-staged、pre-commit
AI/LLM 統合
- Claude SDK → 最新ドキュメントには Context7 を使用
- プロンプト管理 → MCP サーバーを確認
- 文書処理 →
unstructured、pdfplumber、mammoth
データ & API
- HTTP クライアント →
httpx(Python)、ky/undici(Node) - バリデーション →
zod(TS)、pydantic(Python) - データベース → まず MCP サーバーを確認
コンテンツ & 公開
- Markdown 処理 →
remark、unified、markdown-it - 画像最適化 →
sharp、imagemin
統合ポイント
planner エージェントとの統合
planner はフェーズ1(アーキテクチャレビュー)の前に researcher を呼び出すべきです:
- Researcher が利用可能なツールを特定
- Planner がそれらを実装計画に組み込む
- 計画での「車輪の再発明」を回避
architect エージェントとの統合
architect は以下のために researcher に相談すべきです:
- テクノロジースタックの決定
- 統合パターンの発見
- 既存のリファレンスアーキテクチャ
iterative-retrieval スキルとの統合
段階的な発見のために組み合わせます:
- サイクル1: 広い検索(npm、PyPI、MCP)
- サイクル2: 上位候補を詳細に評価
- サイクル3: プロジェクトの制約との互換性をテスト
例
例1: 「デッドリンクチェックを追加」
例2: 「HTTP クライアントラッパーを追加」
例3: 「設定ファイルリンターを追加」
アンチパターン
- コードへの飛び込み: 既存のものがあるか確認せずにユーティリティを書く
- MCP の無視: MCP サーバーが既にその機能を提供しているかチェックしない
- サイレントスキップ: 検索チャネルが利用できなかったのに「何も見つからなかった」と報告する
- 過度なカスタマイズ: ライブラリをラップしすぎてそのメリットを失う
- 依存関係の肥大化: 1つの小さな機能のために巨大なパッケージをインストールする


