/search-first — コーディング前のリサーチ

「カスタムコードを実装する前に既存ソリューションを検索する」というワークフローを体系化します。

トリガー

このスキルを使用する場合:

• 既存ソリューションが存在する可能性の高い新しい機能を開始する
• 依存関係または統合を追加する
• ユーザーが「X 機能を追加して」と依頼し、あなたがコードを書こうとしている
• 新しいユーティリティ、ヘルパー、または抽象化を作成する前

スコープと承認ルール

デフォルトは読み取り専用のリサーチです。リポジトリ、パッケージメタデータ、ドキュメント、公開例を調査した後に、依存関係または統合を推奨します。このスキルから、ユーザーが現在のタスクで明示的に承認していない限り、パッケージのインストール、MCP サーバーの構成、成果物の発行、PR のオープン、または外部書き込みアクションは実行しないでください。

候補が認証情報、有料サービス、ネットワーク書き込み、またはプロジェクト全体の設定変更を必要とする場合は、直接適用する代わりに推奨事項と承認チェックポイントを返します。

ワークフロー

┌─────────────────────────────────────────────┐
│  1. NEED ANALYSIS                           │
│     Define what functionality is needed      │
│     Identify language/framework constraints  │
├─────────────────────────────────────────────┤
│  2. PARALLEL SEARCH (researcher agent)      │
│     ┌──────────┐ ┌──────────┐ ┌──────────┐  │
│     │  npm /   │ │  MCP /   │ │  GitHub / │  │
│     │  PyPI    │ │  Skills  │ │  Web      │  │
│     └──────────┘ └──────────┘ └──────────┘  │
├─────────────────────────────────────────────┤
│  3. EVALUATE                                │
│     Score candidates (functionality, maint, │
│     community, docs, license, deps)         │
├─────────────────────────────────────────────┤
│  4. DECIDE                                  │
│     ┌─────────┐  ┌──────────┐  ┌─────────┐  │
│     │  Adopt  │  │  Extend  │  │  Build   │  │
│     │ as-is   │  │  /Wrap   │  │  Custom  │  │
│     └─────────┘  └──────────┘  └─────────┘  │
├─────────────────────────────────────────────┤
│  5. APPROVAL CHECKPOINT / IMPLEMENT         │
│     Recommend package / MCP / custom code   │
│     Apply only after explicit approval      │
└─────────────────────────────────────────────┘

意思決定マトリックス

シグナル	アクション
完全一致、よくメンテナンスされている、MIT/Apache	採用 — パッケージを推奨し、インストールまたは設定変更の前に承認をリクエスト
部分的一致、良い基盤がある	拡張 — パッケージと薄いラッパーを推奨し、適用前に承認を待機
複数の弱い一致	統合 — 2～3 個の小さなパッケージと統合計画を提案してから、何もインストールしない
適切なものが見つからない	カスタム構築 — カスタムコードが正当な理由を説明し、承認されたタスク範囲内でのみ実装

使用方法

クイックモード (インライン)

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

0. これは既にリポジトリに存在するか？ → 関連するモジュール/テストをまず検索
1. これは一般的な問題か？ → npm/PyPI を検索
2. これ用の MCP があるか？ → MCP 設定を確認して検索
3. これ用のスキルがあるか？ → 利用可能なスキルを確認
4. GitHub に実装/テンプレートがあるか？ → ネットワーク新規コードを書く前に、メンテナンスされている OSS の GitHub コード検索を実行

フルモード (サブエージェント)

自明でない機能の場合は、リサーチ重点型のサブエージェントに委譲します:

サブエージェントをこのプロンプトで起動:
  "Research existing tools for: [DESCRIPTION]
   Language/framework: [LANG]
   Constraints: [ANY]

   Search: npm/PyPI, MCP servers, skills, GitHub
   Return: Structured comparison with recommendation"

カテゴリ別検索ショートカット

開発ツーリング

• Linting → eslint, ruff, textlint, markdownlint
• フォーマッティング → prettier, black, gofmt
• テスト → jest, pytest, go test
• Pre-commit → husky, lint-staged, pre-commit

AI/LLM 統合

• Claude SDK → 最新のドキュメントを確認
• プロンプト管理 → MCP サーバーを確認
• ドキュメント処理 → unstructured, pdfplumber, mammoth

データと API

• HTTP クライアント → httpx (Python), ky/got (Node)
• バリデーション → zod (TS), pydantic (Python)
• データベース → MCP サーバーをまず確認

コンテンツとパブリッシング

• Markdown 処理 → remark, unified, markdown-it
• 画像最適化 → sharp, imagemin

統合ポイント

プランナーエージェントとの統合

プランナーはリサーチ段階 1 (アーキテクチャレビュー) の前にリサーチャーを起動する必要があります:

• リサーチャーが利用可能なツールを特定する
• プランナーが実装計画にそれを組み込む
• 計画における「車輪の再発明」を回避する

アーキテクトエージェントとの統合

アーキテクトはリサーチャーに以下の相談をする必要があります:

• テクノロジースタック決定
• 統合パターンの発見
• 既存の参照アーキテクチャ

iterative-retrieval スキルとの統合

段階的な発見の為に組み合わせます:

• サイクル 1: 広範な検索 (npm, PyPI, MCP)
• サイクル 2: 上位候補を詳細に評価
• サイクル 3: プロジェクト制約との互換性をテスト

例

例 1: 「デッドリンクチェック機能を追加」

需要: Markdown ファイルの壊れたリンクをチェック
検索: npm "markdown dead link checker"
発見: textlint-rule-no-dead-link (スコア: 9/10)
アクション: 採用 — `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 つの小さな機能の為に巨大なパッケージをインストール

このスキルを使用する場合

• 新しい機能を開始する時
• 依存関係または統合を追加する時
• ユーティリティまたはヘルパーを書く前
• テクノロジー選択を評価する時
• アーキテクチャ決定を計画する時