27 万 Star、被安装超 1800 万次，这套顶级的 Skills 有多强？

阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/superpowers-skills/ 「芋道源码」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

用 AI 写代码，返工最密集的地方通常出在同一处。需求我自己觉得讲清楚了，它答得也快，可交付出来跟我要的对不上。复盘过很多次我发现，模型聪不聪明在这里几乎不起作用，卡住的地方是我们之间少了一套干活时谁都得认的规矩，需求没被问透，写完了也没人验。

Matt Pocock 选的路子很朴素。他没有另写一套教程，只是把自己日常在用的东西摊开来放到了 GitHub 上，仓库叫 mattpocock/skills。里面装的就是他自己 .agents 目录里那些天天在调用的文件，基本没为开源做过包装，所以翻到的和他真实项目里用的是同一份。

27 万 Star 这个数字，其实有点误导

官方横幅

我先交代作者。他做的课程叫 Total TypeScript，在这个圈子里属于最有名的教育者之一。Vercel 与 Stately 这两家公司他都待过，岗位是工程师，写代码写了十几年。

再看仓库现在的体量。二十七万多 Star，两万多 Fork，MIT 协议，拿去商用也没人拦你。技能注册站 skills.sh 上挂着五十四个技能，合计被装了两千五百多万次，安装量在同类里排第一。

仓库页实时截图

五十四这个数字看着挺唬人，第一反应多半是「这么多我学不完」。这个反应恰好被数字带偏了，官方站点上真正配了文档页的只有二十五个，工程类十八个，生产力类七个。

剩下那些还在仓库另外两个桶里，一个 misc/，一个 in-progress/，分别躺着四个和九个。这两个桶不出文档页，也不承诺明天还在，属于作者边做边试的地带。

顺着说一句 skill 是什么。它就是一个文件夹配一份说明文档，写明 AI 做某一类活时该走什么顺序。用的时候敲个 /tdd 这种命令把它叫起来，也可以完全不敲，让 AI 在任务对得上时自己取用。

它跟那种每次开对话都要加载一遍的项目说明文件不一样，只在被触发的那一次进上下文，平时不占位置。技能之间互相调用也简单，调用 Skill 工具时把技能名念出来就行，不写文件路径，一次只能带一个名字。

我把二十五个成文的都过了一遍，越看越觉得能反复复用的内核只有四个动作，其余技能是把它们按不同顺序再喊一遍的入口。这四个是，动手前把问题问干净，一次只推进一小片，出问题先造复现再谈原因，持续把模块做深。后面每一节都在讲它们。

一个开关，让同一份文件在两个工具里各干各的

这套东西同时支持 Claude Code 和 Codex，作者却没有为两边各维护一套文件。他先给技能划了一条轴，一类只能由人敲出来，职责是编排；另一类人和 AI 都能叫，承载那些天天要守的纪律。前面那类可以去叫后面那类，反过来不行。

落到文件上，同一条轴在两边各写一处，不用生成两份副本。Claude Code 那边写在技能文件的 frontmatter 里，开关叫 disable-model-invocation。

Codex 那边写在每个技能旁边的 agents/openai.yaml 里，开关叫 policy.allow_implicit_invocation。根目录那个 AGENTS.md 是指向 CLAUDE.md 的软链接，两个工具读到的是同一份仓库说明。

被喊得最多的几个技能在官方站点上单独列了一组，叫参考层。grilling 是盘问这个动作的原语，grill-me、/triage、/wayfinder 和架构体检都在调它。剩下三个里，tdd 管红绿循环，domain-modeling 负责打磨项目术语，codebase-design 提供描述深模块的词汇。它们不直接解决你的需求，作用是在背后给别的技能提供纪律。

/grill-with-docs 的技能文件全文只有一行，内容就是让它连着去喊 grilling 和 domain-modeling。一个一百一十万次安装的技能，全文一行，我第一次看到就笑了。

它跟 BMAD、Spec Kit 这类流程框架是两条路子。那些框架的思路是流程优先，你按它的顺序走，代价是判断权交出去了。这一套把技能做得很小，一个技能只负责一段活，什么时候拿出来、拿出来哪个，全看你自己。

最值钱的那个动作，是让 AI 先反过来问你

安装量排第一的是 /grill-me，一百二十万次。同一族排在后面的叫 /grill-with-docs，一百一十万次。它们共同的动作只有一件，在你动手敲第一行代码之前，把提问权交到 AI 手上。

盘问的循环

注意方向反过来，是它问你，不是你问它。一次只抛一个问题，你答完它再抛下一个，一直问到需求里每一处没想清楚的岔路都摊开为止。我自己用下来最常出现的场景是被它问住，那些我以为不用交代的地方，其实一句都没想清楚。

/grill-with-docs 多做的一件事是边问边收拾项目术语，收拾出来的东西写进 CONTEXT.md。它的价值要用例子才说得清。没有它的时候，你得跟 AI 描述一遍「课程里某个章节下面挂着的课时，在生成为真实文件的时候出了问题」。

有了它，一句话就够，「materialization cascade 出问题了」。意思一个字没少，字数从二十多个压到十个以内。更值的是术语统一之后，AI 再写代码时会沿用同一套叫法。过程里那些不好反悔的技术决策，它会顺手写成架构决策记录。

五十多个技能不知道该挑哪个时还有 /ask-matt，你把项目情况描述给它，它替你挑一个。

写的时候不许跳步，跑不起来也不许猜

写代码这一段有两个技能守在两端，一个管节奏，一个管证据。管节奏的那个是 /tdd，它走红绿循环，先写一个注定跑不过的测试，再写刚好能让它变绿的那点实现，一次只切一小片。它专门盯着一种很容易糊弄过去的假测试驱动，那套做法是把测试一次性写完再回头补实现，测出来的只是想象。

管证据的那个是 /diagnosing-bugs，规矩还要硬，它要求你先造一条能稳定复现的命令出来，而且必须亲手跑通一次，做不到这一步就不许往下猜原因。这条规矩我愿意直接抄进团队的 bug 提交模板里当必填项。

排错的六个阶段

/code-review 管提交前那一道。它把检查拆成两条互不干扰的线，一条看代码有没有守住项目自己定的规范，一条看它是不是真的把当初那个需求实现了，两条分开跑，免得一边的判断把另一边带偏。

代码库开始变乱，让它先体检别动刀

AI 写得快，代码变乱也快。/improve-codebase-architecture 会先扫一遍整个仓库，把值得收拾的模块挑出来，生成一份 HTML 报告摊在你面前。你选一个想动的，它针对这一个继续跟你讨论改法，作者建议隔几天跑一次。

有一句官方写得很明白，它是体检，不是抢救。在年头够久的代码库上它确实能挑出真实候选，但不会替你上手把那团乱麻解开。

它背后那套理论是深浅模块，判断标准落在接口和实现的复杂度对比上。浅模块的接口跟它的实现一样复杂，调用方用之前得先钻进一堆细节里，这种是它最想揪出来的。深模块反过来，接口小小一个，复杂度全藏在里面。

深模块与浅模块的对照

这一带还有几个技能在多数介绍里见不到。/wayfinder 对付一个会话根本装不下的活儿，把它画成一张挂在 issue 跟踪器上的决策地图，再一张张解决策工单，默认只产决策不产交付物。

/research 会派一个后台代理去查一手来源，把结论写成带引用的 Markdown 交回来。/wizard 生成一个交互式 bash 脚本，把只有人才能做的那些步骤一步步走完，脚本底层用到的库不许手改。

/wait-what 这个名字本身就是一句没听懂的话，作用是某条消息你看不明白时，要求对方用简化的技术英语配上项目术语重讲一遍。/to-questionnaire 只盘问寄给谁、想拿回什么，不碰主题内容。/resolving-merge-conflicts 逐个冲突块按意图解决，必须做完整个合并，中途不许放弃。

一条需求从讨论走到提交，中间谁接谁

从讨论到提交的全流程

前面那些都是单点技能，官方站点把主干流程单列成一组，一共五步。起点还是 /grill-with-docs，需求聊到没有暗礁了就交给 /to-spec，它把这轮对话收成规格文档丢进 issue 跟踪器，之后不会再追问。

接下来 /to-tickets 接手，把规格切成一张张工单，谁挡着谁、先后顺序都写在工单上。/implement 照着规格或者工单动手，期间自己按 /tdd 的节奏推进，收尾前再过一道 /code-review。

除了这五步，还有三个技能管旁支。issue 堆起来的时候 /triage 按状态机把它们逐个过一遍。会话聊太长、AI 开始发钝的时候，/handoff 把进度压成交接文档，换个会话接着干，换个工具也行。

遇到说不清、必须看到实物才能定的问题，/prototype 做个一次性的原型，看完就扔，硬约束是原型不许以半成品的形式留在仓库里。

装起来两条路，二选一

想装的话有两条路，选一条走就行，两条都走每个技能会多出一份。

装到 Claude Code 上就走插件市场这条路，官方市场里直接就有，不用先加什么源。

claude plugins install mattpocock-skills

这条路是订阅式的、只读的，好处是作者那边一更新这边自动跟上，代价是你改不了它的文件。想在本地改技能文件的走另一条，用命令行装。

npx skills@latest add mattpocock/skills

它把技能文件复制进你的项目，从此变成你自己的文件，随便改。装的时候会让你勾选装哪些技能，这里有个坑，初始化的那个必须勾上。以后想拉作者的新改动，跑 npx skills update。

装完还有一步初始化，命令是 /setup-matt-pocock-skills，一个仓库做一次。它会问三件事，issue 放在哪里（GitHub、Linear 或本地文件，三选一），分诊打什么标签，文档存哪个目录。这一步不走，其他技能没有地方落笔。

最后一条，它不挑模型，说明文档里写得很明白，支持任何模型，安装时也能指定装到哪个工具。

什么时候别用它

真正划算的场合有几个。接到模糊需求的时候最值，需求越糊，grill 系列越有用，盘问那半小时看着烦，跟写完再返工比起来还是便宜太多。

bug 死活复现不出来的时候也值。盯着代码瞎猜最没用，/diagnosing-bugs 会先逼你把复现命令造出来，不少人查了好几天才解决掉的问题，事后一对，缺的都是这一步。

手上的老项目越来越难改的时候，把体检技能隔几天叫出来一次，让它列张清单，你挑着收拾。最后一个场合压根不写代码，/grill-me 离了代码一样能用，写方案、做决策、想产品点子都行，被它盘问一轮比自己关起门来琢磨扎实。
反过来也有明确用不上的场合。只为了快速糊个 demo，或者写个用完就删的小脚本，这套东西就是纯负担，让 AI 直接写完收工更省事。仓库说明很直白，这些技能是为真实工程准备的，随手 vibe coding 的玩法用不上。

还有一条起步建议，不要一次性把它全装上。先挑一两个最对症的试，作者本人也是先用了 /grill-with-docs，他管它叫整套东西的入口。

这些规矩二三十年前就有了，新的只是载体

翻完这个仓库，印象最深的一点是它里面没有新东西。测试先行、需求盘问、统一语言、架构决策记录、原型验证，全是软件工程课本里讲了几十年的老办法，这个项目要做的，是把它们翻译成 AI 照着能执行的文件。

仓库说明还给四种常见翻车场景各引了一本经典做注脚，智能体不按预期做事和代码跑不起来都引《程序员修炼之道》，话太多引《领域驱动设计》，代码库变成一团泥引《极限编程解析》与《软件设计哲学》。

这些做法拆开看都不新鲜，我依然认这个方向。如今让 AI 写代码，写不写得出来早就不是难点，麻烦在于速度快，过去那些老毛病被它挨个放大。需求含糊、代码越堆越乱，代价都比从前重，反倒是这些老办法能兜住，它们管的就是速度。

还有一点做得对，它没把流程做成黑盒。技能文件都是纯文本，摊在仓库里，看不顺眼就自己改一份，这跟那些恨不得替你做完所有决策的框架是两条路子。

仓库自己也在守自己那套规矩。根目录有 CONTEXT.md，.agents/adr/ 里躺着两份架构决策记录，.out-of-scope/ 里有三份写明「这个我们不做」的说明，最近的补丁版本还把排错技能改成先脱敏再展示命令和输出。

开源地址在 https://github.com/mattpocock/skills 。