search-first

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 個の小さなパッケージを組み合わせ
適切なものが見つからない	構築 -- カスタムを記述、ただしリサーチに基づいて

使い方

クイックモード（インライン）

ユーティリティを書いたり機能を追加する前に、頭の中で以下を実行します：

0. リポジトリに既に存在する？ -> まず関連モジュール/テストを rg で検索
1. よくある問題？ -> npm/PyPI を検索
2. これ用の MCP がある？ -> ~/.claude/settings.json をチェックして検索
3. これ用のスキルがある？ -> ~/.claude/skills/ をチェック
4. 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 つの小さな機能のために巨大なパッケージをインストール