search-first

name search-first description 研究优先于编码的工作流程。在编写自定义代码之前，搜索现有的工具、库和模式。调用研究员代理。 origin ECC /search-first — 编码前先研究 系统化“在实现之前先寻找现有解决方案”的工作流程。 触发时机 在以下情况使用此技能： 开始一项很可能已有解决方案的新功能 添加依赖项或集成 用户要求“添加 X 功能”而你准备开始编写代码 在创建新的实用程序、助手或抽象之前 工作流程 ┌─────────────────────────────────────────────┐ │ 1. 需求分析 │ │ 确定所需功能 │ │ 识别语言/框架限制 │ ├─────────────────────────────────────────────┤ │ 2. 并行搜索（研究员代理） │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ npm / │ │ MCP / │ │ GitHub / │ │ │ │ PyPI │ │ 技能 │ │ 网络 │ │ │ └──────────┘ └──────────┘ └──────────┘ │ ├─────────────────────────────────────────────┤ │ 3. 评估 │ │ 对候选方案进行评分（功能、维护、 │ │ 社区、文档、许可证、依赖） │ ├─────────────────────────────────────────────┤ │ 4. 决策 │ │ ┌─────────┐ ┌──────────┐ ┌─────────┐ │ │ │ 采用 │ │ 扩展 │ │ 构建 │ │ │ │ 原样 │ │ /包装 │ │ 定制 │ │ │ └─────────┘ └──────────┘ └─────────┘ │ ├─────────────────────────────────────────────┤ │ 5. 实施 │ │ 安装包 / 配置 MCP / │ │ 编写最小化自定义代码 │ └─────────────────────────────────────────────┘ 决策矩阵 信号 行动 完全匹配，维护良好，MIT/Apache 许可证 采纳 — 直接安装并使用 部分匹配，基础良好 扩展 — 安装 + 编写薄封装层 多个弱匹配 组合 — 组合 2-3 个小包 未找到合适的 构建 — 编写自定义代码，但需基于研究 使用方法 快速模式（内联） 在编写实用程序或添加功能之前，在脑中过一遍： 这已经在仓库中存在吗？ → 首先通过相关模块/测试检查 rg 这是一个常见问题吗？ → 搜索 npm/PyPI 有对应的 MCP 吗？ → 检查 ~/.claude/settings.json 并进行搜索 有对应的技能吗？ → 检查 ~/.claude/skills/ 有 GitHub 上的实现/模板吗？ → 在编写全新代码之前，先运行 GitHub 代码搜索以查找维护中的开源项目 完整模式（代理） 对于非平凡的功能，启动研究员代理： 任务（子代理类型="通用型"，提示=" 研究现有工具用于：[描述] 语言/框架：[语言] 约束：[任何] 搜索：npm/PyPI、MCP 服务器、Claude Code 技能、GitHub 返回：结构化对比与推荐 ") 按类别搜索快捷方式 开发工具 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 获取最新文档 提示词管理 → 检查 MCP 服务器 文档处理 → unstructured , pdfplumber , mammoth 数据与 API HTTP 客户端 → httpx (Python), ky / got (Node) 验证 → zod (TS), pydantic (Python) 数据库 → 首先检查是否有 MCP 服务器 内容与发布 Markdown 处理 → remark , unified , markdown-it 图片优化 → sharp , imagemin 集成点 与规划器代理 规划器应在阶段 1（架构评审）之前调用研究员： 研究员识别可用的工具 规划器将它们纳入实施计划 避免在计划中“重新发明轮子” 与架构师代理 架构师应向研究员咨询： 技术栈决策 集成模式发现 现有参考架构 与迭代检索技能 结合进行渐进式发现： 循环 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：“添加配置文件 linter” 需求：根据模式验证项目配置文件 搜索：npm "config linter schema"、"json schema validator cli" 发现：ajv-cli（评分：8/10） 操作：采用 + 扩展 —— 安装 ajv-cli，编写项目特定的模式 结果：1 个包 + 1 个模式文件，无需自定义验证逻辑 反模式 直接跳转到编码 ：不检查是否存在就编写实用程序 忽略 MCP ：不检查 MCP 服务器是否已提供该能力 过度定制 ：对库进行如此厚重的包装以至于失去了其优势 依赖项膨胀 ：为了一个小功能安装一个庞大的包