| name | search-first |
| description | Research-before-coding workflow. Search for existing tools, libraries, and patterns before writing custom code. Invokes the researcher agent. |
| origin | ECC |
/search-first -- コードを書く前にリサーチ
「実装前に既存のソリューションを検索する」ワークフローを体系化します。
トリガー
以下の場合にこのスキルを使用します：
- 既存のソリューションがある可能性の高い新機能の開始
- 依存関係やインテグレーションの追加
- ユーザーが「X 機能を追加して」と言い、コードを書こうとしている時
- 新しいユーティリティ、ヘルパー、抽象化を作成する前
ワークフロー
┌─────────────────────────────────────────────┐
│ 1. ニーズ分析 │
│ 必要な機能を定義 │
│ 言語/フレームワーク制約を特定 │
├─────────────────────────────────────────────┤
│ 2. 並列検索（researcher エージェント） │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ npm / │ │ MCP / │ │ GitHub / │ │
│ │ PyPI │ │ Skills │ │ Web │ │
│ └──────────┘ └──────────┘ └──────────┘ │
├─────────────────────────────────────────────┤
│ 3. 評価 │
│ 候補をスコアリング（機能、保守性、 │
│ コミュニティ、ドキュメント、ライセンス、依存関係）│
├─────────────────────────────────────────────┤
│ 4. 決定 │
│ ┌─────────┐ ┌──────────┐ ┌─────────┐ │
│ │ そのまま │ │ 拡張/ │ │ カスタム │ │
│ │ 採用 │ │ ラップ │ │ 構築 │ │
│ └─────────┘ └──────────┘ └─────────┘ │
├─────────────────────────────────────────────┤
│ 5. 実装 │
│ パッケージインストール / MCP 設定 / │
│ 最小限のカスタムコードを記述 │
└─────────────────────────────────────────────┘
判断マトリクス
| シグナル | アクション |
|---|
| 完全一致、メンテナンスされている、MIT/Apache | 採用 -- インストールしてそのまま使用 |
| 部分一致、良い基盤 | 拡張 -- インストール + 薄いラッパーを記述 |
| 複数の弱い一致 | 組み合わせ -- 2-3 個の小さなパッケージを組み合わせ |
| 適切なものが見つからない | 構築 -- カスタムを記述、ただしリサーチに基づいて |
使い方
クイックモード（インライン）
ユーティリティを書いたり機能を追加する前に、頭の中で以下を実行します：
- リポジトリに既に存在する？ -> まず関連モジュール/テストを
rg で検索
- よくある問題？ -> npm/PyPI を検索
- これ用の MCP がある？ ->
~/.claude/settings.json をチェックして検索
- これ用のスキルがある？ ->
~/.claude/skills/ をチェック
- GitHub に実装/テンプレートがある？ -> ネットニューのコードを書く前に、メンテナンスされている OSS を GitHub コード検索で実行
フルモード（エージェント）
非自明な機能の場合、researcher エージェントを起動します：
Task(subagent_type="general-purpose", prompt="
以下の既存ツールをリサーチ: [説明]
言語/フレームワーク: [言語]
制約: [あれば]
検索対象: npm/PyPI、MCP サーバー、Claude Code スキル、GitHub
返却: 推奨付きの構造化された比較
")
カテゴリ別検索ショートカット
開発ツール
- リンティング ->
eslint, ruff, textlint, markdownlint
- フォーマッティング ->
prettier, black, gofmt
- テスト ->
jest, pytest, go test
- Pre-commit ->
husky, lint-staged, pre-commit
AI/LLM インテグレーション
- Claude SDK -> 最新ドキュメントは Context7 で
- プロンプト管理 -> MCP サーバーをチェック
- ドキュメント処理 ->
unstructured, pdfplumber, mammoth
データ & API
- HTTP クライアント ->
httpx（Python）、ky/got（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: 「デッドリンクチェックを追加」
ニーズ: Markdown ファイルの壊れたリンクをチェック
検索: npm "markdown dead link checker"
発見: textlint-rule-no-dead-link（スコア: 9/10）
アクション: 採用 -- npm install textlint-rule-no-dead-link
結果: カスタムコードゼロ、実戦テスト済みソリューション
例 2: 「HTTP クライアントラッパーを追加」
ニーズ: リトライとタイムアウト処理付きの堅牢な HTTP クライアント
検索: npm "http client retry"、PyPI "httpx retry"
発見: got（Node）リトライプラグイン付き、httpx（Python）ビルトインリトライ付き
アクション: 採用 -- got/httpx をリトライ設定付きで直接使用
結果: カスタムコードゼロ、本番実績のあるライブラリ
例 3: 「設定ファイルリンターを追加」
ニーズ: プロジェクト設定ファイルをスキーマに対して検証
検索: npm "config linter schema"、"json schema validator cli"
発見: ajv-cli（スコア: 8/10）
アクション: 採用 + 拡張 -- ajv-cli をインストール、プロジェクト固有スキーマを記述
結果: 1 パッケージ + 1 スキーマファイル、カスタムバリデーションロジックなし
アンチパターン
- 即コード: 既存のものがあるかチェックせずにユーティリティを書く
- MCP 無視: MCP サーバーが既にその機能を提供しているかチェックしない
- 過度なカスタマイズ: ライブラリをあまりにも厚くラップして利点を失う
- 依存関係の肥大化: 1 つの小さな機能のために巨大なパッケージをインストール
