/search-first — 编码前先调研（Research Before You Code）
将“在实现前搜索现有解决方案”的工作流系统化。
触发条件（Trigger）
在以下场景使用此技能（Skill）：
- 开始开发一个很可能已有现成解决方案的新功能
- 添加依赖项或集成
- 用户要求“添加 X 功能”且你正准备编写代码
- 在创建新的工具类（Utility）、辅助函数（Helper）或抽象层之前
工作流（Workflow）
┌─────────────────────────────────────────────┐
│ 1. 需求分析 (NEED ANALYSIS) │
│ 定义所需功能 │
│ 识别语言/框架约束 │
├─────────────────────────────────────────────┤
│ 2. 并行搜索 (调研智能体 researcher agent) │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ npm / │ │ MCP / │ │ GitHub / │ │
│ │ PyPI │ │ 技能 │ │ Web │ │
│ └──────────┘ └──────────┘ └──────────┘ │
├─────────────────────────────────────────────┤
│ 3. 评估 (EVALUATE) │
│ 为候选方案打分（功能、维护、 │
│ 社区、文档、许可证、依赖） │
├─────────────────────────────────────────────┤
│ 4. 决策 (DECIDE) │
│ ┌─────────┐ ┌──────────┐ ┌─────────┐ │
│ │ 采用 │ │ 扩展 │ │ 自研 │ │
│ │ (Adopt) │ │ (Extend)│ │ (Build) │ │
│ └─────────┘ └──────────┘ └─────────┘ │
├─────────────────────────────────────────────┤
│ 5. 实施 (IMPLEMENT) │
│ 安装包 / 配置 MCP / │
│ 编写最少量的自定义代码 │
└─────────────────────────────────────────────┘
决策矩阵（Decision Matrix）
| 信号 |
行动 |
| 完全匹配、维护良好、MIT/Apache 协议 |
采用 (Adopt) — 直接安装并使用 |
| 部分匹配、基础良好 |
扩展 (Extend) — 安装 + 编写轻量封装层 |
| 多个弱匹配项 |
组合 (Compose) — 结合 2-3 个小型包 |
| 未找到合适方案 |
自研 (Build) — 编写自定义代码，但基于调研结论 |
如何使用
快速模式（行内使用）
在编写工具类或添加功能前，大脑中先过一遍：
- 仓库中是否已存在？→ 先通过
rg 搜索相关的模块/测试
- 这是一个常见问题吗？→ 搜索 npm/PyPI
- 是否有相关的 MCP？→ 检查
~/.claude/settings.json 并搜索
- 是否有相关的技能（Skill）？→ 检查
~/.claude/skills/
- 是否有 GitHub 实现/模板？→ 在编写全新代码前，针对维护良好的开源软件（OSS）运行 GitHub 代码搜索
完整模式（智能体代理）
对于非平凡的功能，启动调研智能体（Researcher Agent）：
Task(subagent_type="general-purpose", prompt="
调研现有的工具，针对：[功能描述]
语言/框架：[LANG]
约束条件：[ANY]
搜索范围：npm/PyPI, MCP 服务器, Claude Code 技能, GitHub
返回结果：带建议的结构化对比报告
")
按类别搜索快捷方式
开发工具（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 集成
- Claude SDK → 参考 Context7 获取最新文档
- 提示词管理（Prompt management）→ 检查 MCP 服务器
- 文档处理 →
unstructured, pdfplumber, mammoth
数据与 API
- HTTP 客户端 →
httpx (Python), ky/got (Node)
- 验证（Validation）→
zod (TS), pydantic (Python)
- 数据库 → 优先检查 MCP 服务器
内容与发布
- Markdown 处理 →
remark, unified, markdown-it
- 图像优化 →
sharp, imagemin
集成点（Integration Points）
与规划智能体（Planner Agent）集成
规划器应在第一阶段（架构审查 Architecture Review）之前调用调研员：
- 调研员识别可用工具
- 规划器将它们纳入实施计划
- 避免在计划中“重复造轮子”
与架构智能体（Architect Agent）集成
架构师应就以下内容咨询调研员：
与迭代检索技能（Iterative-retrieval Skill）集成
结合使用进行渐进式发现：
- 第 1 轮：广泛搜索 (npm, PyPI, MCP)
- 第 2 轮：详细评估首选候选方案
- 第 3 轮：测试与项目约束的兼容性
示例
示例 1：“添加死链检查”
需求：检查 markdown 文件中的损坏链接
搜索：npm "markdown dead link checker"
发现：textlint-rule-no-dead-link (得分: 9/10)
行动：采用 (ADOPT) — npm install textlint-rule-no-dead-link
结果：零自定义代码，经受过实战检验的解决方案
示例 2：“添加 HTTP 客户端封装层”
需求：具备重试和超时处理能力的弹性 HTTP 客户端
搜索：npm "http client retry", PyPI "httpx retry"
发现：带重试插件的 got (Node), 内置重试的 httpx (Python)
行动：采用 (ADOPT) — 直接使用带重试配置的 got/httpx
结果：零自定义代码，生产环境验证过的库
示例 3：“添加配置文件 Linter”
需求：根据 Schema 验证项目配置文件
搜索：npm "config linter schema", "json schema validator cli"
发现：ajv-cli (得分: 8/10)
行动：采用 + 扩展 (ADOPT + EXTEND) — 安装 ajv-cli，编写项目特定的 schema
结果：1 个包 + 1 个 schema 文件，无需自定义验证逻辑
反模式（Anti-Patterns）
- 直接编码：不检查是否存在现成工具就编写工具类
- 忽视 MCP：不检查 MCP 服务器是否已经提供了该功能
- 过度自定义：对库进行过重封装，导致其丧失原有优势
- 依赖膨胀：为了一个很小的功能安装庞大的包
1---2name: search-first3description: Research-before-coding workflow. Search for existing tools, libraries, and patterns before writing custom code. Invokes the researcher agent.4---5
6# /search-first — 编码前先调研（Research Before You Code）
7
8将“在实现前搜索现有解决方案”的工作流系统化。
9
10## 触发条件（Trigger）
11
12在以下场景使用此技能（Skill）：
13- 开始开发一个很可能已有现成解决方案的新功能
14- 添加依赖项或集成
15- 用户要求“添加 X 功能”且你正准备编写代码
16- 在创建新的工具类（Utility）、辅助函数（Helper）或抽象层之前
17
18## 工作流（Workflow）
19
20```
21┌─────────────────────────────────────────────┐
22│ 1. 需求分析 (NEED ANALYSIS) │
23│ 定义所需功能 │
24│ 识别语言/框架约束 │
25├─────────────────────────────────────────────┤
26│ 2. 并行搜索 (调研智能体 researcher agent) │
27│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
28│ │ npm / │ │ MCP / │ │ GitHub / │ │
29│ │ PyPI │ │ 技能 │ │ Web │ │
30│ └──────────┘ └──────────┘ └──────────┘ │
31├─────────────────────────────────────────────┤
32│ 3. 评估 (EVALUATE) │
33│ 为候选方案打分（功能、维护、 │
34│ 社区、文档、许可证、依赖） │
35├─────────────────────────────────────────────┤
36│ 4. 决策 (DECIDE) │
37│ ┌─────────┐ ┌──────────┐ ┌─────────┐ │
38│ │ 采用 │ │ 扩展 │ │ 自研 │ │
39│ │ (Adopt) │ │ (Extend)│ │ (Build) │ │
40│ └─────────┘ └──────────┘ └─────────┘ │
41├─────────────────────────────────────────────┤
42│ 5. 实施 (IMPLEMENT) │
43│ 安装包 / 配置 MCP / │
44│ 编写最少量的自定义代码 │
45└─────────────────────────────────────────────┘
46```
47
48## 决策矩阵（Decision Matrix）
49
50| 信号 | 行动 |
51|--------|--------|
52| 完全匹配、维护良好、MIT/Apache 协议 | **采用 (Adopt)** — 直接安装并使用 |
53| 部分匹配、基础良好 | **扩展 (Extend)** — 安装 + 编写轻量封装层 |
54| 多个弱匹配项 | **组合 (Compose)** — 结合 2-3 个小型包 |
55| 未找到合适方案 | **自研 (Build)** — 编写自定义代码，但基于调研结论 |
56
57## 如何使用
58
59### 快速模式（行内使用）
60
61在编写工具类或添加功能前，大脑中先过一遍：
62
630. 仓库中是否已存在？→ 先通过 `rg` 搜索相关的模块/测试
641. 这是一个常见问题吗？→ 搜索 npm/PyPI
652. 是否有相关的 MCP？→ 检查 `~/.claude/settings.json` 并搜索
663. 是否有相关的技能（Skill）？→ 检查 `~/.claude/skills/`
674. 是否有 GitHub 实现/模板？→ 在编写全新代码前，针对维护良好的开源软件（OSS）运行 GitHub 代码搜索
68
69### 完整模式（智能体代理）
70
71对于非平凡的功能，启动调研智能体（Researcher Agent）：
72
73```
74Task(subagent_type="general-purpose", prompt="
75 调研现有的工具，针对：[功能描述]
76 语言/框架：[LANG]
77 约束条件：[ANY]
78
79 搜索范围：npm/PyPI, MCP 服务器, Claude Code 技能, GitHub
80 返回结果：带建议的结构化对比报告
81")
82```
83
84## 按类别搜索快捷方式
85
86### 开发工具（Development Tooling）
87- 代码检查（Linting）→ `eslint`, `ruff`, `textlint`, `markdownlint`
88- 格式化（Formatting）→ `prettier`, `black`, `gofmt`
89- 测试（Testing）→ `jest`, `pytest`, `go test`
90- Pre-commit → `husky`, `lint-staged`, `pre-commit`
91
92### AI/LLM 集成
93- Claude SDK → 参考 Context7 获取最新文档
94- 提示词管理（Prompt management）→ 检查 MCP 服务器
95- 文档处理 → `unstructured`, `pdfplumber`, `mammoth`
96
97### 数据与 API
98- HTTP 客户端 → `httpx` (Python), `ky`/`got` (Node)
99- 验证（Validation）→ `zod` (TS), `pydantic` (Python)
100- 数据库 → 优先检查 MCP 服务器
101
102### 内容与发布
103- Markdown 处理 → `remark`, `unified`, `markdown-it`
104- 图像优化 → `sharp`, `imagemin`
105
106## 集成点（Integration Points）
107
108### 与规划智能体（Planner Agent）集成
109规划器应在第一阶段（架构审查 Architecture Review）之前调用调研员：
110- 调研员识别可用工具
111- 规划器将它们纳入实施计划
112- 避免在计划中“重复造轮子”
113
114### 与架构智能体（Architect Agent）集成
115架构师应就以下内容咨询调研员：
116- 技术栈决策
117- 集成模式发现
118- 现有参考架构
119
120### 与迭代检索技能（Iterative-retrieval Skill）集成
121结合使用进行渐进式发现：
122- 第 1 轮：广泛搜索 (npm, PyPI, MCP)
123- 第 2 轮：详细评估首选候选方案
124- 第 3 轮：测试与项目约束的兼容性
125
126## 示例
127
128### 示例 1：“添加死链检查”
129```
130需求：检查 markdown 文件中的损坏链接
131搜索：npm "markdown dead link checker"
132发现：textlint-rule-no-dead-link (得分: 9/10)
133行动：采用 (ADOPT) — npm install textlint-rule-no-dead-link
134结果：零自定义代码，经受过实战检验的解决方案
135```
136
137### 示例 2：“添加 HTTP 客户端封装层”
138```
139需求：具备重试和超时处理能力的弹性 HTTP 客户端
140搜索：npm "http client retry", PyPI "httpx retry"
141发现：带重试插件的 got (Node), 内置重试的 httpx (Python)
142行动：采用 (ADOPT) — 直接使用带重试配置的 got/httpx
143结果：零自定义代码，生产环境验证过的库
144```
145
146### 示例 3：“添加配置文件 Linter”
147```
148需求：根据 Schema 验证项目配置文件
149搜索：npm "config linter schema", "json schema validator cli"
150发现：ajv-cli (得分: 8/10)
151行动：采用 + 扩展 (ADOPT + EXTEND) — 安装 ajv-cli，编写项目特定的 schema
152结果：1 个包 + 1 个 schema 文件，无需自定义验证逻辑
153```
154
155## 反模式（Anti-Patterns）
156
157- **直接编码**：不检查是否存在现成工具就编写工具类
158- **忽视 MCP**：不检查 MCP 服务器是否已经提供了该功能
159- **过度自定义**：对库进行过重封装，导致其丧失原有优势
160- **依赖膨胀**：为了一个很小的功能安装庞大的包
xu-xiang