用途
melech-buy-vs-build 用于回答一个具体问题：某项能力应该采用已有工具，还是自己实现。它针对的场景是：智能体被要求“加个后台任务”时，会顺手写一张任务表、一个轮询 worker、一个重试列和一个死信标志——能跑，但等于把 BullMQ、Trigger.dev、Cloud Tasks 或 package.json 里已有的队列库重新糟糕地实现一遍，并且从此永久维护。仓库级审查通常只问“我们代码里有没有”，而模型记忆对外部问题的回答往往自信、过时甚至虚构包名。这个技能把“自建还是采购”这个昂贵且难以逆转的决策，从默认行为变成基于证据的判断。
两种意图
- Intercept（拦截）：当代码、方案或差异已存在、可能重复造轮子时触发。目标是命名被（重新）构建的东西，找到现有方案，决定采用还是继续自建。
- Explore（探索）：开放式问题，如“X 有什么现成的”“X 有没有新工具”“现在人们怎么做 X”。目标是梳理领域，呈现值得注意的和近期出现的方案，让用户自己选择。
输入已明显表明意图时不要追问。差异或提案意味着 intercept；单纯的能力问题意味着 explore。
核心规则
搜索能力，而不是名词。 调研失败的唯一原因是用用户自己的词汇去搜索。搜“postgres polling table worker”只会找到博客文章；识别出能力是“持久化后台任务执行”才能找到整个类别。因此搜索前先把实现翻译成行业标准术语，例如：表行+轮询 worker+重试计数 → job queue、background jobs、durable task execution；自定义事件总线+处理器注册表 → pub/sub、message broker、event bus；手写带抖动的重试包装 → retry library、resilience/backoff library；定制角色/权限匹配器 → authorization / policy engine、RBAC / ReBAC；类 cron 的 setInterval+锁文件 → job scheduler、distributed cron、workflow orchestration；向导的 diff-and-apply 状态机 → state machine library、workflow engine；自定义 CSV/Excel 导出写入器 → spreadsheet / serialization library。不确定标准术语时，第一次搜索就搜术语本身：“what is it called when …”。
工作流程
- 命名能力：用一行说明这个东西做什么，剥离本地实现，列出 2–5 个标准搜索词和明显同义词，在展开前展示给用户。
- 读取事实基础（内联，必须最先）：在主线程完成，因为外部调研线没有它无法简报。收集决定适配性的约束：语言与运行时、清单中已有的依赖（package.json、requirements.txt/pyproject.toml、go.mod、Cargo.toml、Gemfile、pom.xml）；已付费的基础设施（云厂商、Postgres/Redis/Kafka、账单中已有的供应商）；硬约束（仅自托管、数据驻留、许可政策、气隙环境、不新增供应商、预算）；规模现实（每天 100 个任务和每秒 10 万个任务不会选出同样的工具）。如果这一步已发现明显命中——能力就是直接依赖或明显已启用的供应商功能——就此停止并报告，不要去买已经拥有的东西。
- 并行展开调研线：每条线一个子智能体，各自沿路径运行多次网络搜索（adopt-vs-rebuild 线以本地为主）。内部线与外部线在同一并发批次启动，避免串行延迟。调研线包括：Adopt-vs-rebuild（内部，特权，查传递依赖、框架/标准库内置、已覆盖此能力的供应商套餐、内部 monorepo 库，拥有短路权）；Canon（类别标准名称和每个对比都会列的 3–8 个选项）；Ecosystem（本项目语言中的库和开源）；Commercial（托管服务、开发工具、SaaS、云原语，包括没人提的无聊云答案）；Verdicts（实践者实际怎么说：HN/Reddit 讨论、“我们迁移离开了 X”、事后复盘、后悔原因）；Counter-case（为什么自建有时是对的，以及现有方案的已知失败模式）。explore 意图额外加一条 Frontier 线，看过去 6–12 个月发布了什么。短路规则：如果 adopt-vs-rebuild 线返回确认命中——一个真实、活跃、已拥有且覆盖需求的能力——运行结束，丢弃外部线结果，报告已拥有的选项并停止。按风险调整线数：3 条用于“有没有重试库”，6 条用于“要不要自建编排器”。不要按网站开线。用户提供的种子名称、来源或“也看看 X”应路由到专门的一条线。
- 归并：合并所有线，然后验证或丢弃 → 剔除已死项目 → 去重身份 → 按方法（而非名称）聚类 → 按第 2 步约束排序（流行度只作平局决胜，绝不是标准）。
- 交付候选清单与结论：上限 3–6 个候选。二十个的列表是研究倾倒，不是推荐。示例表格包含 Option、Kind、Why it fits、Cost、What you give up、Adoption effort 列，并附“已在你的技术栈中”“没有任何选项能给你的东西”“什么时候自建仍然胜出”等说明。然后用 ask_question 把决定交给用户：采用推荐选项并移除手写版本；采用但保留自定义层用于无人覆盖的部分；保留自定义实现（记录原因）；进一步研究——不同约束或更多选项。绝不主动删除可工作的代码，技能只报告和建议，用户说了算。
- 交接：采用 → 用最小路径集成，或如果替换会重塑设计则重新对齐设计；继续自建 → 继续，并留一条 WHY 注释记录评估和拒绝了什么，避免下一个智能体重跑这场辩论；需求本身看起来不成立 → 重新审视需求是否真实；候选需要承诺前压力测试 → 在写代码前验证选择。
证据契约
模型会虚构自信、合理、不存在的包。如果这个技能发明了 @vercel/queue-kit，它就毫无价值。因此：始终网络搜索，记忆只生成假设，只有搜索产生候选；每个候选都带一个本次运行中出现在实时结果里的 URL；每个候选都带活跃度信号（最近发布、最近提交或当前定价/文档页）；凭记忆但未验证的名称要标注，确认后才能进入候选清单；版本号、定价、限制和许可条款从来源引用或省略，绝不估算；如实报告空线，“在这个生态中没有找到可信方案”是真实且有用的发现。
适用场景与限制
适用于：代码/方案/差异可能重复造轮子时的拦截判断；开放式“X 有什么工具”的探索；需要基于实时证据而非模型记忆的采购与自建决策；已有依赖或供应商可能已覆盖能力时的内部检查。
限制：技能只报告和建议，不主动删除或替换可工作的代码；候选上限 3–6 个；需要网络搜索才能产生候选；无法确定分类时归入 other-ai-tools。关于具体收费、价格、平台支持等事实，资料未提供，暂未提供。