/search-first — 编码前进行调查¶

将“在实现之前搜索现有解决方案”的工作流程体系化。

触发条件¶

在以下情况下使用此技能： - 开始新功能，且很可能已存在解决方案 - 添加依赖项或集成 - 用户要求“添加 X 功能”，而你正准备写代码 - 在创建新的工具函数、辅助函数或抽象之前

工作流程¶

┌─────────────────────────────────────────────┐
│  0. ツール利用可能性の事前確認              │
│     依存する前に検索チャネルを確認；        │
│     スキップしたチャネルを正直に報告する    │
├─────────────────────────────────────────────┤
│  1. ニーズ分析                              │
│     必要な機能を定義する                    │
│     言語/フレームワークの制約を特定する     │
├─────────────────────────────────────────────┤
│  2. 並列検索（researcher エージェント）     │
│     ┌──────────┐ ┌──────────┐ ┌──────────┐  │
│     │  npm /   │ │  MCP /   │ │  GitHub / │  │
│     │  PyPI    │ │  スキル  │ │  Web      │  │
│     └──────────┘ └──────────┘ └──────────┘  │
├─────────────────────────────────────────────┤
│  3. 評価                                    │
│     候補をスコアリング（機能性、保守性、    │
│     コミュニティ、ドキュメント、ライセンス、│
│     依存関係）                              │
├─────────────────────────────────────────────┤
│  4. 決定                                    │
│     ┌─────────┐  ┌──────────┐  ┌─────────┐  │
│     │ 採用    │  │ 拡張/   │  │ カスタム │  │
│     │ そのまま│  │ ラップ   │  │ ビルド   │  │
│     └─────────┘  └──────────┘  └─────────┘  │
├─────────────────────────────────────────────┤
│  5. 実装                                    │
│     パッケージをインストール / MCP を設定 / │
│     最小限のカスタムコードを書く            │
└─────────────────────────────────────────────┘

决策矩阵¶

信号	操作
完全匹配、维护良好、MIT/Apache	采用 — 直接安装并使用
部分匹配、基础良好	扩展 — 安装 + 编写薄封装
多个弱匹配	组合 — 组合 2 到 3 个小包
找不到合适项	构建 — 编写自定义实现，但基于调研

使用方法¶

步骤 0：工具可用性预检¶

这是代理指导，而不是可执行的设置脚本。只检查与当前任务和项目相关的通道。

通道	检查	缺失时
仓库搜索	`rg --files` 和有针对性的 `rg` 查询	明确说明只检查了可见文件
包注册表	`npm --version`、`python -m pip --version`，或项目的包管理器	使用 Web/文档搜索，不声称覆盖注册表
GitHub CLI	`gh auth status`	仅使用公开 Web 或本地 git 历史
MCP/文档工具	可用工具列表或本地 MCP 配置	回退到官方文档/网络搜索
技能目录	`ls ~/.claude/skills ~/.codex/skills`（如适用）	明确说明本地技能目录不可用

快速模式（内联）¶

在编写工具函数或添加功能之前，检查以下内容：

它是否已存在于仓库中？ → 首先用 rg 检查相关模块/测试
这是常见问题吗？ → 搜索 npm/PyPI
是否有 MCP？ → 检查并搜索 ~/.claude/settings.json
是否有对应技能？ → 检查 ~/.claude/skills/
GitHub 上是否有实现/模板？ → 在编写新代码之前，执行针对维护良好的 OSS 的 GitHub 代码搜索

完整模式（代理）¶

对于非平凡功能，启动 researcher 代理：

Agent(subagent_type="general-purpose", prompt="
  既存のツールを調査してください: [説明]
  言語/フレームワーク: [言語]
  制約: [あれば]

  検索先: npm/PyPI、MCP サーバー、Claude Code スキル、GitHub
  返却: 推薦付きの構造化比較
")

旧的 Claude Code 文档可能将其称为 Task(...)；请使用当前活动 harness 公开的当前代理/子代理工具名。

按类别划分的搜索快捷方式¶

开发工具¶

代码检查 → eslint、ruff、textlint、markdownlint
格式化 → prettier、black、gofmt
测试 → jest、pytest、go test
提交前 → husky、lint-staged、pre-commit

AI/LLM 集成¶

Claude SDK → 使用 Context7 获取最新文档
Prompt 管理 → 检查 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：“添加死链检查”¶

必要: 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）with retry plugin, httpx（Python）with built-in retry
アクション: 採用 — got/httpx をリトライ設定で直接使用
結果: カスタムコードなし、本番実証済みのライブラリ

示例 3：“添加配置文件检查器”¶

必要: プロジェクト設定ファイルをスキーマに対して検証
検索: npm "config linter schema", "json schema validator cli"
発見: ajv-cli（スコア: 8/10）
アクション: 採用 + 拡張 — ajv-cli をインストール、プロジェクト固有のスキーマを記述
結果: 1 パッケージ + 1 スキーマファイル、カスタム検証ロジックなし

反模式¶

直接写代码：未确认是否已有现成实现就编写工具函数
忽略 MCP：不检查 MCP 服务器是否已提供该功能
静默跳过：搜索通道不可用，却报告“什么都没找到”
过度定制：对库封装过多，导致失去其优势
依赖膨胀：为一个很小的功能安装巨大的包

本页原文 Markdown：在 AtomGit 查看·内容源自开源项目 ev/ECC