description: 编码前研究的工作流程。在编写自定义代码之前，先搜索现有的工具、库和模式。调用研究员智能体。

/search-first — 编码前先研究

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

触发时机

在以下情况使用此技能：

开始一个很可能已有解决方案的新功能时
添加依赖项或集成时
用户要求“添加X功能”而你正准备编写代码时
在创建新的工具、助手或抽象之前

工作流程

┌─────────────────────────────────────────────┐
│  1. 需求分析                                │
│     定义所需功能                             │
│     识别语言/框架约束                        │
├─────────────────────────────────────────────┤
│  2. 并行搜索（研究员智能体）                  │
│     ┌──────────┐ ┌──────────┐ ┌──────────┐  │
│     │  npm /   │ │  MCP /   │ │  GitHub / │  │
│     │  PyPI    │ │  技能    │ │  网页     │  │
│     └──────────┘ └──────────┘ └──────────┘  │
├─────────────────────────────────────────────┤
│  3. 评估                                     │
│     对候选方案评分（功能、维护、社区、文档、许可、依赖）│
├─────────────────────────────────────────────┤
│  4. 决策                                     │
│     ┌─────────┐  ┌──────────┐  ┌─────────┐  │
│     │  采用    │  │  扩展/包装 │  │  自定义构建 │
│     │ 原样使用  │  │          │  │          │
│     └─────────┘  └──────────┘  └─────────┘  │
├─────────────────────────────────────────────┤
│  5. 实施                                     │
│     安装包 / 配置MCP / 编写最少的自定义代码      │
└─────────────────────────────────────────────┘

决策矩阵

信号	行动
完全匹配，维护良好，MIT/Apache许可	采用 — 直接安装并使用
部分匹配，基础良好	扩展 — 安装 + 编写薄包装层
多个弱匹配	组合 — 结合2-3个小包
未找到合适的	构建 — 编写自定义代码，但基于研究信息

使用方法

快速模式（内联）

在编写工具或添加功能之前，在脑中快速过一遍：

这是常见问题吗？ → 搜索 npm/PyPI
有相关的MCP吗？ → 检查 ~/.claude/settings.json 并搜索
有相关的技能吗？ → 检查 ~/.claude/skills/
有GitHub模板吗？ → 搜索 GitHub

完整模式（智能体）

对于非平凡的功能，启动研究员智能体：

Task(subagent_type="general-purpose", prompt="
  研究现有工具：[描述]
  语言/框架：[语言]
  约束条件：[任何]

  搜索：npm/PyPI、MCP服务器、Claude Code技能、GitHub
  返回：结构化比较与推荐
")

按类别搜索捷径

开发工具

代码检查 → eslint、ruff、textlint、markdownlint
代码格式化 → prettier、black、gofmt
测试 → jest、pytest、go test
预提交钩子 → 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

集成点

与规划智能体

规划智能体应在第一阶段（架构评审）之前调用研究员：

研究员识别可用工具
规划智能体将其纳入实施计划
避免在计划中“重新发明轮子”

与架构智能体

架构智能体应咨询研究员以获取：

技术栈决策
集成模式发现
现有参考架构

与迭代检索技能

结合进行渐进式发现：

第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服务器是否已提供该功能
过度定制：过度包装库以至于失去其优势
依赖膨胀：为一个小功能安装庞大的包