melech-scout 是一个调研型技能，定位为“研究伙伴”，用于在从零构建某项能力之前，先找出并比较世界上已经发布的现成方案。它强调基于实时来源验证，而不是依赖模型记忆，避免推荐不存在或已过时的包。
用途
当有人要求“加个后台任务”时，代理往往会自己写任务表、轮询 worker、重试列和死信标记。这能跑，但可能是在糟糕地重造 BullMQ、Trigger.dev、Cloud Tasks，或 package.json 里已有的队列库，并且从此要永久维护。melech-scout 的目标就是先调研：这项能力业界已经有什么，是否值得采用，还是继续自建。
两种意图
- 拦截（Intercept）：已存在代码、计划或 diff，可能正在重复造轮子。需要命名被（重新）构建的东西，找出既有方案，决定采用还是继续自建。
- 探索（Explore）：开放式问题，如“X 有什么现成方案”“X 有什么新工具”“现在人们怎么做 X”。需要梳理领域，呈现值得注意的和近期出现的方案，帮助用户选择。
如果输入已明显指向某种意图，不要追问。diff 或提案意味着拦截；单纯的能力问题意味着探索。
核心规则：搜索能力，而非名词
调研失败的根本原因是用用户自己的词汇去搜索。搜索“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 万个任务不会选出同样的工具）。已安装或已被付费服务覆盖的候选方案，优先于其他所有候选。
- 并行展开调研通道：并发派发独立调研通道，每条通道一个子代理，各自沿路径运行多次网络搜索。通道按答案类型划分，而非关键词：Canon（类别标准名称及所有对比都会列出的 3–8 个选项）、Ecosystem（本项目语言中的库与开源）、Commercial（托管服务、开发工具、SaaS、云原语）、Already yours（当前依赖、框架标准库或账单中已有供应商里隐藏的能力，价值最高、成本最低）、Verdicts（实践者真实评价：HN/Reddit 讨论、“我们迁移离开了 X”、事后复盘）、Counter-case（为什么自建有时是对的，以及既有方案的已知失败模式）。探索意图需增加 Frontier 通道，覆盖最近 6–12 个月发布的内容。通道数量按风险调整：3 条用于“有没有重试库”，6 条用于“要不要自建编排器”。不要按网站开通道。用户提供的种子名称、来源或“也看看 X”应路由到专门通道。通道简报、查询模式、搜索场域和候选行模式见 references/lanes.md。每条通道需给出能力陈述、第 2 步约束、其唯一问题、来源上限和证据契约。
- 归并：合并所有通道的候选行；未验证的杀掉（没有实时 URL 就没有候选）；已死的杀掉（约 18 个月无发布或实质提交、仓库归档、日落通知、公司不存在）；跨改名、分支、包装器和同一产品不同名称去重；按方法聚类而非按名称（如托管服务 vs 自托管 broker vs 数据库内库），用户首先选的是方法；按第 2 步约束适配度排序，再看采用度和成熟度，流行度只作平局裁决，绝不作为标准。
- 交付候选清单与结论：上限 3–6 个候选，二十个是研究倾倒而非推荐。示例表格包含选项、类型、为何适配、成本、放弃什么、采用工作量。每行必须可追溯到本轮捕获的来源 URL。然后用 ask_question 把决定交给用户：采用推荐选项并移除手写版本；采用但保留自定义层用于某部分；保留自定义实现（记录原因）；进一步调研——不同约束或更多选项。绝不主动拆除可工作的代码，Scout 只报告和建议，用户决定。
- 交接：采用 → 以最小路径集成，或若替换会重塑设计则重新对齐设计；继续自建 → 继续，并留下一条 WHY 注释记录评估和拒绝了什么，避免下一个代理重复这场讨论；需求本身现在看起来不牢靠 → 重新审视需求是否真实；候选方案需要承诺前压力测试 → 写代码前先验证选择。
证据契约
模型会自信地编造看似合理但不存在的包。本技能若虚构 @vercel/queue-kit 就毫无价值。因此：始终进行网络搜索，记忆只生成假设，只有搜索产生候选；每个候选都带有本轮实时结果中出现的 URL；每个候选都带有存活信号（最近发布、最近提交或当前定价/文档页）；回忆但未验证的名称需标注，并在进入候选清单前确认；版本号、定价、限制和许可条款从来源引用或省略，绝不估算；如实报告空通道，“该生态中未找到可信内容”是真实且有用的发现。
Do / Don't
Do：说明“这是任务队列。通用术语：background jobs、durable task execution、work queue。先搜这些。” Don't：搜索用户措辞（“带状态列的任务表”）然后断定不存在。Do：先检查清单——“p-retry 已是传递依赖；你的自定义退避包装只是它的 40 行。” Don't：当能力已安装或已计费时推荐新供应商。Do：“其中三个已死：最后发布于 2021 年、仓库归档、公司被收购并日落。剔除。” Don't：用废弃项目填充候选清单以显得周全。Do：“这些都不处理你的按租户公平规则。无论选哪个，这部分都归你。” Don't：暗示某库是直接替代却不说明它缺什么。Do：“以你的量级，手写版本确实更简单。保留它。” Don't：每次都得出“用库”的结论；总是说采用的技能不是调研，是条件反射。Do：呈现候选清单让用户选择。Don't：因为存在更流行的选项就开始替换可工作的代码。
适用场景与限制
适用于产品与工程工作中“是否已有现成方案”的调研，尤其是可能重复造轮子的代码、计划或 diff，以及开放式工具探索。限制：它只做调研与建议，不主动修改或替换代码；候选必须经实时来源验证，未验证或已死的方案会被剔除；版本、定价、限制和许可条款不估算；若某生态无可信内容会如实报告为空。