Open Mercato Skills

四十一个 agent 技能，跑完整条 pull request 流水线；它是从作者们在 Open Mercato 做的那套 ERP 产品里抽出来的，目的是让任何仓库都能跑同一套流程。通过 skills.sh 一条命令即可装进仓库，可配合二十多种编码 agent 使用。三条入口——一份自由格式的任务简报、一份规格文档、一个 tracker issue——汇入同一条评审环和同一道 QA 关卡，而每个技能结尾都会留下一个可被机器解析的引用行，交给下一个技能。所有与项目相关的取值都来自一个提交进仓库的配置文件：基线分支、校验命令、标签体系与工作路径；tracker 与浏览器的命令则写在提交进仓库的描述文件里，随包发布 GitHub、GitLab、Linear、Jira 四份，因此没有任何技能自己去调 tracker 命令。团队自己主张（本记录未予核实）：这套流程产出了约 80 万行代码且没有一行手写，合并了 1,700+ 个 pull request，有 4,000 个单元测试、730 个集成测试、每周发版；而仓库描述给的是 1.2M+ 行——README 里没有再用这个数字。MIT 许可。

谁做的仓库归 Open Mercato 组织所有，而 Karwatka 是压倒性的提交者：369 次提交里有 274 次记在 pkarw 这个账号上，与「他两个邮箱地址合计 271 次、加上 GitHub 匿名邮箱的 3 次」正好对上。另有十个账号贡献过代码，最多的是 matgren 的 41 次；154 次提交带共同作者尾注，其中 153 条指向某个 Claude 模型，而其中 102 条只写「Claude Fable 5」。README 结尾说团队在波兰的一门 AI 工程课上教这套做法；README 里也还留着两处 HTML 注释，请他把文案改写成自己的口吻。

1. 01

   一句自述，一次抽取，和三个月的提交

   这个仓库值得记下来，是因为它写在自己描述里的那句话：「Enterprise AI Engineering skills we coined at Open Mercato」（「1.2M+ lines of code ERP built with AI」）。那是项目自己的说法，也是它用到的最大一个数字——README 把同一套流程记为约 80 万行、1,700+ 个已合并 pull request、4,000 个单元测试、730 个集成测试、每周发版，以及 100+ 位贡献者。这些在本记录里一概不作核实；可以核实的是它周围这次抽取本身。组织在 2026-06-26 建库，第一次提交出现在 2026-07-02，提交信息只说它是一个仓库空壳外加 README 与许可证；此后不到三个月里有 369 次提交：7 月 244 次，8 月 68 次，9 月 57 次。由此出了两个 release——2026-07-21 的 v1.0.0 与 2026-08-13 的 v1.1.0；周围是 210 个星、30 个 fork、22 个打开的 issue，以及十一个贡献者账号，其中一个占掉 369 次提交里的 274 次。

2. 02

   抽取时丢下的东西

   从产品里剥出来的流水线不会完好无损，而 tracker 把这些账都留着。有两个已发布的技能仍在把工作交给 1.1.0 已经删掉的名字——前一个被改了名，后一个被并进了另一个技能。两处引用都写成了「可选依赖」，于是运行时 agent 把它读成「用户只是没装这个技能」，跳过交接并报告成功；没有任何东西大声失败，这个回归还活过了一个 release。修法是把它们指向当前名字，并加一道 lint 闸门，让下一个过期名字发不出去。第二处丢失更安静：规格技能里的「反打包」检查在上游是分两半发布的——规则写在技能正文里，作为必须提出的开放问题；让规则真正能触发的证据写在另一个 references 文件里——而迁移只带走了正文。这个检查就这样穿过了迁移，却没有任何东西可供它触发。

3. 03

   规则是文档，闸门是脚本

   让四十来份指令文档不至于彼此漂开的，是 AGENTS.md 里那张任务路由表，以及它背后一套有约束力的契约：技能 frontmatter 里的 name 必须等于目录名，description 至多 500 字符；lint 闸门会在技能树里搜产品引用，也会搜硬编码的基线分支或包管理器；tracker 状态只能通过具名操作改动；任何配置值都不许写进技能。在此之上是 scripts/lint.sh（8,375 字节）和五个 Node 契约测试套件，分别盯着 tracker provider、browser provider、discovery 技能、run 分类器和关闭关键词。一个每周运行的 workflow 会刷新一个被钉住的浏览器版本，还自己开了一个 pull request；提交说明特意点出：它改的那份描述文件，正是用来钉住 setup 下载并按 SHA-256 校验的那些二进制包。PR #114 最能说明这里一条规则是怎么装上去的：给 2026-09-11 当时存在的全部 37 个技能加上强制、精确路径的本地覆盖前置检查，再加一条 lint 不变量——技能的覆盖命令缺失或指错路径就直接判不合格——而证据是一次反向探测：删掉某一个技能的前置检查，确认报出的正是那条错误，再把文件放回去。

4. 04

   先得给自己修一次的仓库

   这个项目替别人的仓库配置 agent 流水线，而它自己有两个月跑着的，是这套配置的一份过期拷贝。它自己的配置写于 2026-07-10，比 browser-provider 契约落地早四天；因为文件里没有 browser 这个键，所有带浏览器能力的技能都悄悄把这个仓库当成 Playwright 仓库，而文档里描述的那个 provider 描述文件目录，在这里根本不存在。同一个文件列出的校验命令，只是集成流程真正会跑的五个命令里的一个。第二处自伤更锋利：lint 步骤要求「已安装的浏览器描述文件」与「随包发布的那个」完全一致，于是当一次 setup 用了较旧的已安装拷贝、把 v0.34.0 的内容盖到 v0.35.2 的描述文件上时，默认分支变红了——而且一直红着，因为每一个合并了默认分支的 pull request 都继承了这次失败。修法是把随包发布的那份原样拷回来，选这条路的理由恰恰是：不让任何已评审的内容发生变化。

5. 05

   退休一道已经验证不了任何东西的闸门

   这个原型技能是从上游产品单仓的一个 pull request 里引进来的，而为这次引进写下的上线条件说：只有等上游那个 pull request 合并、并让引进的文件对照合并后的提交再比一次，才能合并。上游那个一直没合，于是这次引进在队列里趴了数周；等到有评审者接手这份过期的认领时，诚实的标签不是「要求修改」而是「阻塞」，因为作者已经没有代码可改了。四个非阻塞的发现被有意留着不修，而不是在本地打补丁——因为在本地打补丁会造出这道闸门本来就存在的意义所要防住的那种漂移。2026-09-15，闸门本身被协商替换：改成从某个被钉住的源提交做一次有据可查的引进，配一份验证记录，把 13 个引进文件逐一映射并说明每一处有意为之的差异；新的条件写进规格文档，而不是留在 pull request 的评论串里。让它退休的理由才是最有意思的部分——改过名、重写过流程之后，再对着一个已合并的上游去比一次，已经验证不了任何东西，而这个集合从现在起就是源头。

6. 06

   这套流水线正跑在发布它的仓库上

   去读这个仓库的 pull request，你读到的是流水线自己的输出：机器人评论以技能标记加一句用途封装，一个 pull request 只有一条合并后的标签理由，每个标签配一整句解释；认领与释放的锁让并发的 agent 各自退开；摘要里还会数出自动修复迭代了几轮——有一处是八条评审发现一轮修完，另一处是七条。这套自动化也一直承认一个它绕不过去的限制：GitHub 不允许自我批准，所以当评审账号就是作者本人时，结论会作为评论贴出来，并需要一个第二个账号去补上原生批准；报告把这件事直接说出来，而不是假装已经批准。同一种纪律还长出了给 fork 贡献用的「接力」做法——一个基线冲突的 fork pull request 被关掉，改由维护者开一个替代 PR 把工作接过来，原作者在关闭评论里被点名致谢；另有一条替代致谢规则，让 changelog 把功劳记给作者而不是合并的人。还没写出来的是证据：README 里留着两处 HTML 注释，请创始人把文案改成自己的口吻；而它那节讲「用这套工作流产出的产品」的地方，写的是案例研究还在添加——也就是说，「这套流水线真的交付过一个产品」这个主张，在仓库里至今没有案例。