23 万 Star。这个顶级的 Skills 有多强？

用 AI 写代码，最让人头疼的返工场景，几乎都长一个样：需求明明说得挺清楚，AI 也写得飞快，可跑起来一看——完全不是自己想要的东西。

翻过自己的返工记录之后，我发现多数时候跟模型聪不聪明关系不大，而是我和 AI 之间少了一套干活的规矩：需求没问透，写完也没验。

直到我遇见了 Matt Pocock 的开源项目 —— mattpocock/skills。他把自己每天在用的那套规矩整理出来，原样公开了。

这个仓库到底是什么？

Matt Pocock 是 Total TypeScript 的作者，TypeScript 圈子里最有影响力的教育者之一，曾在 Vercel 和 Stately 担任工程师，写了十几年代码。

这个仓库说起来很简单：他把自己的 .agents 目录里每天在用的 skill 文件原样公开了。没有包装，没有修饰，就是他日常干活真实在用的那一套。

这个仓库目前 23.8 万 Star，2 万多 Fork，MIT 协议，随便用。在 skills.sh 上挂着 53 个 skill，加起来被装了 1800 多万次，是目前安装量最高的一套技能集。

它和 Spec Kit、BMAD 这些项目思路不同。那些项目让流程接管一切，你跟着走就行；Matt 这套正好反过来——每个 skill 都很小，只干一件事，用哪个、什么时候用，全由你说了算。

这套技能都能干什么？

仓库里的 skill 有五十来个，真正日常高频用的就二十多个。我按干活的顺序把它们分成四组，一组一组说。

📋 动手之前，先把需求问清楚

/grill-me 和 /grill-with-docs 是整个仓库最火的两个 skill，光 /grill-me 一个就被装了 九十多万次。

它们干的事就一件：在你动手写代码之前，让 AI 反过来盘问你。注意是 AI 问你，不是你问它。它会把你需求里没想清楚的岔路一个一个问出来，一次只问一个，一直问到每条岔路都有答案为止。

我实际用下来，经常被它问住，很多「想当然」的地方都是被这么问出来的。

/grill-with-docs 在此基础上多干一件事：盘问的过程中，它会把项目里的术语整理进一个叫 CONTEXT.md 的文件，把那些不好撤销的技术决策写成 ADR 文档存下来。

/ask-matt ——五十多个 skill 看着眼晕，不知道哪个适合自己的情况，就直接问它，它会根据你描述的情况帮你挑一个。

⚙️ 写代码的时候，测试和排错都有规矩

/tdd ——测试驱动开发，先写一个注定失败的测试，再写刚好够它通过的实现，一次只切一小片。它专门防一种很常见的假 TDD：先把所有测试写完再写所有实现——那样测的全是你想象出来的形状，不是真实行为。

/diagnosing-bugs ——排查 bug 用的。它的规矩很硬：必须先造出一条能稳定复现问题的命令，并且真的跑过一次，才允许进入猜原因的阶段。跑不出来就不许猜。这条规矩我觉得直接抄进团队的 bug 模板里都不过分。

/code-review ——提交前的检查。一边看代码有没有遵守项目自己定的规范，一边看它是不是真的实现了当初的需求，两边分开跑，谁也不干扰谁。

🏗️ 管住代码库，别让它越写越乱

/improve-codebase-architecture ——AI 写代码快，代码变乱也快。这个 skill 会扫一遍整个仓库，找出那些值得收拾的模块，生成一份 HTML 报告摆在你面前。你挑一个想改的，它会针对这个候选继续跟你讨论怎么改。

Matt 建议隔几天就跑一次。它只负责把候选找出来给你看，不会自作主张动手重构。它背后用的是「深模块、浅模块」那套经典理论——浅模块的接口和实现一样复杂，基本就是个传话的，这种就是它要揪出来的对象。

🔗 把一个完整需求串成流程

前面这些 skill 都是单个的，下面这几个负责把流程串起来。一个需求从讨论到提交，中间这几步它们各管一段：

• /to-spec：聊得差不多了，直接把当前对话整理成一份规格说明，发到 issue 跟踪器里。它不会再追问你，只把已经聊过的东西收拢成文档。
• /to-tickets：把规格拆成一张张工单，每张都标清楚谁阻塞谁，先干什么后干什么。
• /implement：照着规格或工单开始干活，中间自动走 /tdd 的节奏，提交之前再过一遍 /code-review。
• /triage：issue 一多就需要分诊，它按一套状态机把 issue 一个个过一遍。
• /handoff：会话聊得太长、AI 开始变迟钝的时候，把当前进度压成一份交接文档，开一个新会话接着干，甚至丢给另一个工具接着干。
• /prototype：遇到那种说不清、必须亲眼看到的问题，先做个一次性的原型看看，看完就扔——它不允许你把原型写成半成品留在仓库里。

安装很简单

用 Claude Code 的话，一行命令：

官方插件市场里就有，不用先加什么源。这条路线是订阅式的，只读，以后作者更新我们这边自动跟上。

想自己改 skill 文件的，走另一条：

它会把 skill 文件复制进项目里，变成我们自己的文件，随便改。两条路选一个就行，都走的话每个 skill 会装两份。

装完记得跑一次 /setup-matt-pocock-skills，每个仓库跑一次就够。它会问我们几个小问题——issue 放在哪、triage 用什么标签、文档存哪个目录——跑完这一步，其他 skill 才有地方写东西。

顺带说一句，这套东西不挑模型。 README 里写明了 "work with any model"，装的时候可以选装到哪个工具上，Codex 也好，其他支持 Agent Skills 规范的客户端也好，都能用。

什么情况下值得拿出来用

说几个我自己觉得对得上号的场景：

• 接新需求的时候。需求越模糊，grill 系列的价值越大。我自己体会是，盘问那半小时看着烦，但比起写完再返工，还是划算得多。
• bug 复现不出来的时候。与其盯着代码猜，不如让 /diagnosing-bugs 逼着我们先把复现命令造出来。很多查了好几天没结果的 bug，回头看都是这一步被跳过去了。
• 老项目越改越乱的时候。隔几天跑一次 /improve-codebase-architecture，让它把值得收拾的地方列出来，我们挑着改。
• 不写代码的事。/grill-me 不看代码也能用——写方案、做决策、想产品点子，让它盘你一轮，比自己闷头想要扎实。

反过来，什么时候用不上？ 就想快速糊个 demo、写个一次性脚本，那这套东西对你就是负担，直接让 AI 写就完了。Matt 在 README 里也写得很明白：这些 skill 是他拿来做真实工程的，vibe coding 用不上这套。

我的看法

这个仓库我翻完以后，印象最深的一点是：里面其实没有什么新东西。

盘问需求、测试先行、统一语言、ADR、原型验证——全是软件工程里讲了二三十年的老规矩。这个开源项目做的事，说白了就是把这些老规矩写成 AI 能照着执行的文件。

这些做法单拎出来都不新鲜，不过我还是很认这个方向。我现在用 AI 写代码，会不会写早就不成问题了，真正头疼的是它写得太快，快到以前那些老问题全被放大了。需求没说清、代码越堆越乱，代价都比以前大不少。这种时候，反而是这些老规矩管用。

另外还有一点我觉得做得对：它不把流程做成黑盒。所有 skill 都是纯文本，摆在仓库里，你看不顺眼就 fork 一份自己改。跟那些想替你做完所有决策的框架比，这种把判断权留给人自己的做法，我非常认同。