Search First

是什么

在动手写代码之前，先把 npm / PyPI / MCP 服务器 / Claude 技能库 / GitHub 翻一遍，帮你在 15 分钟里判断"这事到底是装一个包、套个壳、还是真的得自己造"，把"重复造轮子"的概率压到最低。

怎么用

1. 先做需求拆解：把"我要的能力"用一句话写清楚，标注语言 / 框架 / 许可 / 维护活跃度的硬约束。
2. 并行检索四路：包管理器（npm / PyPI）+ MCP 服务器 + 本地 skills 目录 + GitHub 仓库 / 模板搜索。
3. 用打分矩阵评候选（功能匹配 / 维护活跃 / 社区规模 / 文档完整 / 许可 / 依赖体积）。
4. 做决策：完全匹配就直接 Adopt；部分匹配就 Extend 写薄壳；多个弱匹配就 Compose 组合；都不行才 Build。
5. 实施时优先 install + 最小配置，自己写的代码越少越好，最后回头把研究结论沉淀进项目文档。

架构图

flowchart LR
  A[需求拆解] --> B[并行检索 npm/PyPI/MCP/GitHub]
  B --> C[候选打分矩阵]
  C --> D{匹配程度}
  D -->|完全| E[Adopt 直接装]
  D -->|部分| F[Extend 薄壳]
  D -->|弱匹配| G[Compose 组合]
  D -->|无| H[Build 自己造]

/search-first — Research Before You Code

Systematizes the "search for existing solutions before implementing" workflow.

Trigger

Use this skill when:

• Starting a new feature that likely has existing solutions
• Adding a dependency or integration
• The user asks "add X functionality" and you're about to write code
• Before creating a new utility, helper, or abstraction

Workflow

┌─────────────────────────────────────────────┐
│  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. IMPLEMENT                               │
│     Install package / Configure MCP /       │
│     Write minimal custom code               │
└─────────────────────────────────────────────┘

Decision Matrix

How to Use

Quick Mode (inline)

Before writing a utility or adding functionality, mentally run through:

0. Does this already exist in the repo? → rg through relevant modules/tests first
1. Is this a common problem? → Search npm/PyPI
2. Is there an MCP for this? → Check ~/.claude/settings.json and search
3. Is there a skill for this? → Check ~/.claude/skills/
4. Is there a GitHub implementation/template? → Run GitHub code search for maintained OSS before writing net-new code

Full Mode (agent)

For non-trivial functionality, launch the researcher agent:

Task(subagent_type="general-purpose", prompt="
  Research existing tools for: [DESCRIPTION]
  Language/framework: [LANG]
  Constraints: [ANY]

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

Search Shortcuts by Category

Development Tooling

• Linting → eslint, ruff, textlint, markdownlint
• Formatting → prettier, black, gofmt
• Testing → jest, pytest, go test
• Pre-commit → husky, lint-staged, pre-commit

AI/LLM Integration

• Claude SDK → Context7 for latest docs
• Prompt management → Check MCP servers
• Document processing → unstructured, pdfplumber, mammoth

Data & APIs

• HTTP clients → httpx (Python), ky/got (Node)
• Validation → zod (TS), pydantic (Python)
• Database → Check for MCP servers first

Content & Publishing

• Markdown processing → remark, unified, markdown-it
• Image optimization → sharp, imagemin

Integration Points

With planner agent

The planner should invoke researcher before Phase 1 (Architecture Review):

• Researcher identifies available tools
• Planner incorporates them into the implementation plan
• Avoids "reinventing the wheel" in the plan

With architect agent

The architect should consult researcher for:

• Technology stack decisions
• Integration pattern discovery
• Existing reference architectures

With iterative-retrieval skill

Combine for progressive discovery:

• Cycle 1: Broad search (npm, PyPI, MCP)
• Cycle 2: Evaluate top candidates in detail
• Cycle 3: Test compatibility with project constraints

Examples

Example 1: "Add dead link checking"

Need: Check markdown files for broken links
Search: npm "markdown dead link checker"
Found: textlint-rule-no-dead-link (score: 9/10)
Action: ADOPT — npm install textlint-rule-no-dead-link
Result: Zero custom code, battle-tested solution

Example 2: "Add HTTP client wrapper"

Need: Resilient HTTP client with retries and timeout handling
Search: npm "http client retry", PyPI "httpx retry"
Found: got (Node) with retry plugin, httpx (Python) with built-in retry
Action: ADOPT — use got/httpx directly with retry config
Result: Zero custom code, production-proven libraries

Example 3: "Add config file linter"

Need: Validate project config files against a schema
Search: npm "config linter schema", "json schema validator cli"
Found: ajv-cli (score: 8/10)
Action: ADOPT + EXTEND — install ajv-cli, write project-specific schema
Result: 1 package + 1 schema file, no custom validation logic

Anti-Patterns

• Jumping to code: Writing a utility without checking if one exists
• Ignoring MCP: Not checking if an MCP server already provides the capability
• Over-customizing: Wrapping a library so heavily it loses its benefits
• Dependency bloat: Installing a massive package for one small feature