今天(2026 年 10 月 8 日)的 GitHub 日榜上,mattpocock/skills 排在第 4 位,当日新增约 1,770 星。按 GitHub API 在同一时间的取数:仓库 280,662★、23,507 个 fork、MIT 协议,建仓日期写着 2026-02-03,最近一次提交就在今天。对一份纯 markdown 的技能库来说,这个星数已经把它推到了这类项目的最前排。
一句话定位:不是又一套「AI 编程流程」,是把你自己的工程习惯写成文件
作者 Matt Pocock 是 TypeScript 圈的老面孔(Total TypeScript 的作者,仓库里那张说明图就挂在 total-typescript 的图床上,主站是 aihero.dev)。这份仓库的自我介绍很直白:这是他每天用来做真工程、不是氛围编程的技能。
- 它反对什么:README 里点名了 GSD、BMAD、Spec-Kit 这类流程框架。作者的说法是,这些框架帮你"接管流程",代价是拿走你的控制权,而且流程本身出问题时很难查。
- 它主张什么:技能要小、好改、能拼装,并且不绑定模型——任何 Agent、任何模型都能用。
- 它交付什么:不是应用、不是服务,就是一堆可读可改的文本文件。你装上之后,第一件事应该是改它,把里面的措辞换成你自己团队的说法。
为什么今天又冒头
这次重新上榜有具体的由头,不是凭空热起来的:
- 10 月 4 日连发两个版本。v1.3.0 把三个技能"转正"进了正式目录:
implement-spec(整份规格一次做完,开并行子 Agent)、pr(规定 PR 正文该长什么样)、retro(复盘一次编码会话,改的是 Agent 环境而不是代码);同时删掉了resolving-merge-conflicts,理由是"不再需要,也没有替代品"。同一天它还改了约定:域名文档从CONTEXT.md改名为GLOSSARY.md,老用户得自己git mv过去。 - v1.3.1 紧随其后,修的是路由里一处过时的交接指引。
- 今天它又改了一次 README(提交信息写着"lead with self-updating installs"),把"装完能自己更新"提到最前面,顺手重写了各家的安装块。
- 它挂在两条分发链上:一边进了 Anthropic 的官方插件市场(装的时候写的是
@claude-plugins-official),一边上了 skills.sh。作者自报订阅他信件的开发者约 6 万人。
里面到底是什么:Hugo 站能数出来的那种清点
整仓 188 个文件,核心是 38 个 SKILL.md。它没有把技能平铺开,而是按成熟度分桶,桶名就直接写在仓库里:
| 目录 | 技能数 | 是否进插件 | 这一桶是干什么的 |
|---|---|---|---|
skills/engineering | 20 | 是 | 写代码的主流程:拷问、规格、拆票、实现、审查、PR、复盘 |
skills/productivity | 7 | 是 | 与代码无关的通用工作流:拷问、交接、教学、写问卷 |
skills/misc | 4 | 否 | 仓库自用杂项:git 危险命令护栏、pre-commit、练习脚手架 |
skills/in-progress | 7 | 否 | 还没毕业的草稿:幕僚长、写作分段、可循环拷问等 |
关键的那行数字在这里:插件清单(.claude-plugin/plugin.json)里只列了 27 个(20 + 7),misc 和 in-progress 那 11 个不进正式分发。也就是说,你在插件市场装到的是收敛过的那一份,草稿留在仓库里自己看。
它是怎么组织的:一条主流程,两种调用权限
这份仓库有一套自己讲得很清楚的约定,值得单独说,因为它决定了你用起来顺不顺。技能按谁能调用分成两类:
- 用户调用(user-invoked):只有你打字点名才会触发,职责是编排流程。比如
ask-matt是个路由器,你说不清该用哪个技能时先问它。 - 模型调用(model-invoked):你或 Agent 自己都能触发,存放可复用的纪律。用户调用的技能可以调模型调用的,反过来不行。
顺着这条线,它的工程主流程是这么串的:ask-matt 路由 → grill-with-docs 拷问并对齐领域模型 → to-spec 落成规格 → to-tickets 拆成带阻塞关系的票 → implement 逐票做(或 implement-spec 并行做)→ code-review 双轴审查 → pr 收尾 → retro 复盘。每一环都是一份 markdown,你能打开、能删、能改。
四条翻车场景,各配一副药(全文最厚的部分)
README 最有价值的地方,是它没有罗列"我有多少技能",而是先承认Agent 会怎么翻车,再给药。四条我逐条摆出来:
① “Agent 根本没做我想要的东西”。 作者引了《程序员修炼之道》那句"没人确切知道自己想要什么"。药方是拷问式对齐:/grill-me(非代码场景)和 /grill-with-docs(代码场景)会反过来把你按在椅子上问,一道分支一道分支地问到设计树没有歧义为止。这也是它自己承认的"最受欢迎的技能"。
② “Agent 话太多,满嘴黑话”。 病根是项目里没有一套共享语言。药方是 GLOSSARY.md:把项目术语、简写、约定写成一页文件喂给 Agent。README 里的对照例子很实在——BEFORE 是"课程某个小节被’实体化’(即在文件系统里给它一个位置)时有问题",AFTER 是"物化级联(materialization cascade)有问题"。顺带三个收益:命名一致、代码更好导航、Agent 思考更省 token。配套技能是 domain-modeling 和一句"我没听懂"就能触发的 wait-what。
③ “对齐了,代码还是跑不起来”。 药方回到反馈回路:静态类型、浏览器访问、自动化测试。它专门做了 /tdd,逼出先写一个失败的测试再修的红绿重构循环;另配 /diagnosing-bugs,把难 bug 和性能回归拆成"先做出一个会因这个 bug 变红的回路 → 最小化 → 立假设 → 加观测 → 修 → 补回归测试"的分阶段流程。README 直说:没有反馈回路,Agent 就是在盲飞。
④ “我们造了一坨泥球”。 作者引用 Kent Beck 的"每天都要投资系统设计"和《软件设计哲学》的"好模块是深的"。因为 Agent 把写代码速度拉满,软件熵也同步加速,代码库会以前所未有的速度变复杂。药方是 to-spec(动手前先问你要碰哪些模块)和 improve-codebase-architecture——扫一遍代码库、把"值得加深的模块"列成候选、出一个可视报告。作者特别留了一句实话:它是巡检,不是抢救;真正老旧的代码库它能找到真机会,但不会替你解开那团乱麻。
怎么用起来:30 秒装完,再跑一次初始化
它给了六条安装路径,原则是一个 Agent 只挑一条——README 明确警告,两条都装会让每个技能出现两次:
| 你的 Agent | 一条命令 | 更新方式 |
|---|---|---|
| Claude Code | claude plugin install mattpocock-skills@claude-plugins-official | 自动 |
| Codex | codex plugin marketplace add mattpocock/skills 再 codex plugin add mattpocock-skills@mattpocock | 启动时自动 |
| GitHub Copilot | copilot plugin marketplace add mattpocock/skills 再 copilot plugin install mattpocock-skills@mattpocock | 需在设置里加市场 |
| Gemini CLI | gemini skills install https://github.com/mattpocock/skills.git --path skills/engineering | 手动重跑 |
| 其他 Agent / 要可改文件 | npx skills@latest add mattpocock/skills -a <agent> | 手动重跑 |
装完还有一步不能省:在每个仓库里跑一次 /setup-matt-pocock-skills。它会问你三件事——用哪个 issue tracker(GitHub、GitLab、本地文件,或你自己描述的任何东西)、triage 时给票打哪些标签、以及文档存哪。答完这三问,后面的 triage、to-tickets、wayfinder 才知道去哪读写。作者的说法是:先建上下文,再干活。
和同类比,它买的是哪一层
| 做法 | 谁在掌控流程 | 你能改多少 | 绑定 | 费用 |
|---|---|---|---|---|
| 自己攒提示词 | 你 | 全部 | 任意 | 免费 |
| GSD / BMAD / Spec-Kit | 框架 | 少,改框架成本高 | 通常指定 | 免费 |
| 商业 Agent 平台 | 平台 | 少 | 平台与账号 | 订阅制 |
| mattpocock/skills | 你 | 全部(纯文本) | 任意模型 | MIT 免费 |
它没发明新的能力边界,买的是把一套成体系的工程纪律变成 Agent 的默认动作。工程上的另一个加分项是它的"自我交代":仓库里专门有一组 .out-of-scope/ 文件(8 份),记录"我们决定不做的事"和为什么不做;还有 ADR 决策记录、changeset 变更说明,以及一份写给自己 Agent 的调用约定。一个把"不做什么"也写进仓库的项目,通常比只列功能清单的项目更值得读。
顺带一提,本站之前拆过的几篇是同一类思路:marketingskills 把 50 件营销活拆成技能文件,却明确说这套玩法不只能写代码;humanizer 把"去 AI 味"做成可执行的模式清单;open-code-review 和 security-audit-skill 则用规则文件压住审查与审计。区别在于,那几份解决的是某个职能,mattpocock/skills 解决的是工程纪律本身,而且把"你该改它"写在了首页。
我的判断:谁该上、谁再等等、谁别碰
该上的:① 已经在用编码 Agent 的独立开发者和小团队——你缺的往往不是模型,是"每次都要重新交代一遍"的那套上下文,这里有一半技能就是冲这个来的;② 前端 / TypeScript 方向的人——作者的路子和案例都贴着这条线,理解成本最低;③ 想学"怎么给 Agent 写文档"的人——writing-for-agents 这一支本身就是教材,哪怕你不用它的编码流程。
再等等的:① 不写代码、只想做内容副业的人——它的 productivity 桶才 7 个技能,而且偏开发场景,专门为它装一整套插件不划算;② 团队里没有 issue tracker 习惯的人——主流程(拆票、wayfinder、triage)全都假设你有票在流转,先建跟踪再谈技能;③ 只想吃现成的人——它给的是纪律,不是替你按下按钮。
别碰的:① 指望一个插件就把项目从泥球变干净的人——README 自己都说架构巡检只是"巡检";② 不愿意让 Agent 读写本地文件的人——它的全部前提就是那些 markdown 能被 Agent 读到。真要上手,建议只装 engineering 桶,先跑 /grill-with-docs 和 /tdd 两周,看你自己的仓库有没有实际变顺,再决定要不要把 27 个全铺开。
本文由拾光札记编辑部整理,勘误请联系我们