mattpocock 为什么能火
mattpocock/skills 不是团队产品，是 Matt Pocock（Total TypeScript 创始人，前 Vercel 和 Stately.ai 的核心开发者）自己 .claude 目录的公开版本。他在客户项目里天天用这套东西，稍微改改就发出来了，标语写得也直白：”Skills for Real Engineers. Straight from my .claude directory.”
它跟大多数技能库的差别，一眼就能看出来。市面上大部分”agent skill”其实是把一篇博客文章塞进 YAML frontmatter，挂个斜杠命令就发布了，模型读完是更客气了，代码该怎么写还怎么写。Matt Pocock 的技能读起来不一样，你能感觉到里面写的是踩过坑之后才知道的细节：diagnose 技能对”复现”这件事偏执到近乎神经质，tdd 技能花在”警告不要横切”上的篇幅比讲红绿重构本身还多。这种细节，看博客是看不出来的，得自己摔一次才写得出来。
1 | npx skills@latest add mattpocock/skills |
七个技能怎么串起来干活
Matt Pocock 的技能不是一堆孤立的斜杠命令，而是一条完整的开发路径。按实际使用顺序捋一遍，会看得更清楚。
setup-matt-pocock-skills：打地基。 这是运行整套体系的前置门禁。它会扫描 .git/config、pnpm-workspace.yaml、项目根目录的 CLAUDE.md 之类的标识文件，然后跟你确认三件事：用哪个问题追踪工具（GitHub Issues、GitLab Issues，还是本地 .scratch/ 目录）、分拣标签怎么定义、领域文档是单一术语表还是多上下文映射。跑完这一步，后面的技能才知道该往哪写、往哪查。
grill-with-docs：拷问需求，而不是接需求就写。 这是 Matt Pocock 自己点名”可能是仓库里最强”的技能。它的前身是不依赖代码库的 grill-me，纯粹在逻辑链上一路追问；grill-with-docs 把这套追问机制和项目的通用语言（Ubiquitous Language）绑在了一起。激活之后，agent 被禁止写代码，唯一的工作是顺着设计树一次问一个问题，每个问题带上它自己推荐的答案，等你回答完再问下一个。答案不是攒到最后打包写文档，而是当场增量写进根目录的 CONTEXT.md 和 docs/adr/ 下的架构决策记录。下一次开新会话，agent 直接读 CONTEXT.md，不用重新跟你解释一遍”取消订单”在这个项目里到底是什么意思。
batch-grill-me：把简答题换成选择题。 在 VS Code 侧边栏这种富交互界面里，让你打一长串架构构想太累。这个变体会把问题整理成结构化选项，比如”通信通道选 1. WebSocket（双向）2. SSE（单向，推荐：通知场景不需要上行）3. HTTP 长轮询”，附带简短的取舍说明和一个自定义输入框。选择代替敲字，摩擦小了一大截，brief 里点名的降输入摩擦，说的就是这个。
prototype：验证完就扔的沙盒。 有些东西文字讨论不清楚，比如某个状态机会不会死锁，某个组件的视觉效果对不对。prototype 提供一条即用即弃的通道：非视觉逻辑走 LOGIC.md，在关联模块边上搭一个终端交互小工具，状态全在内存里，验证完直接扔；前端页面走 UI.md，同一路由下生成几个差异明显的版本，配一个浮动切换条来回看。全程不写单元测试、不做过度抽象、不留持久化状态。这一步的价值是快速试错，不是产出正式代码。
to-spec：只合成，不追问。 拷问和验证都做完之后，轮到 to-spec 把共识落成规格文档。它的红线很硬：合成阶段绝不能再向人类提新问题，只负责把长会话里已经达成一致的事实提炼出来。落笔前，它会先扫描代码库里已有的测试模式，找一个足够高层的公共 API 作为”测试接缝”，绝不针对私有函数设计测试，这样后面 TDD 阶段测试能拦住接口退化，底层代码怎么重构都不怕。生成的 Spec 会直接提交到问题追踪器，打上”可执行”标签，交给下一步。
tdd：红绿重构，一次一片。 这个技能开门见山一句话：”测试应该通过公共接口验证行为，而不是验证实现细节。”听着是常识，agent 天生做不到，放任不管，它会去 mock 数据库、spy 私有方法、断言中间数据结构的形状，测试全绿，你重构一个内部函数名字，四十个测试跟着报错，行为其实压根没变。tdd 技能给了一句可以直接背下来的判断标准：如果重构没改变行为，测试却挂了，说明这测试测的是实现，不是行为。
diagnose：调试当成状态机来跑。 agent 默认的调试方式很折磨人：看一眼代码，猜一个原因，改一处，跑测试，绿了就说搞定，红了就换个猜法，来回五六轮，你已经搞不清楚到底是哪一步真正修好的。diagnose 把这套流程换成明确的状态机：复现、最小化、假设、插桩、修复、回归测试。核心规则只有一句：只要能拿到一个快速、确定、agent 能自己跑的通过/失败信号，你就一定能找到病根；找不到这个信号，怎么盯着代码看都没用，该在这一步花大力气。在拿到稳定复现之前，agent 不允许碰任何生产代码。
七个技能串起来，其实是同一条主线：规划阶段（setup → grill-with-docs → to-spec）尽量留在同一个会话窗口里，靠大模型在低 token 量级下的高精度推理把决策做扎实；一旦进入 tdd 或 diagnose 这种执行阶段，就彻底清屏、开新会话，只带着当前任务和 CONTEXT.md 进场，避免规划阶段的长对话噪音拖慢执行阶段的注意力。
和 Superpowers 区别
两者的差别不在功能多寡，在控制权分配。Matt Pocock 的技能是一组小技能，靠斜杠命令手动触发，每个 SKILL.md 通常只有几十行，人一直在决策链上；Superpowers 是一套完整的工程流水线：苏格拉底式脑暴、Git 工作树物理隔离、多子智能体并行分发、强制红绿 TDD、代码审查卡点，一路自动跑到收尾，人类只在脑暴和计划审批时插一脚。
选哪个，看你更在意什么。如果你的 token 预算有限、习惯自己把控每一步、项目规模是个人或小团队，mattpocock/skills 的轻量和低损耗更合适，一个 SKILL.md 几分钟就能读完，装三个、晾着十六个都没关系。如果你愿意为并行开发的加速比付 token 成本、团队已经有能力管理多个子智能体沙箱、想要更强的流程刚性，Superpowers 的重型流水线会更划算。这不是谁更先进的问题，是控制权和预算怎么分配的问题。
总结
我自己 ~/.agents/skills 目录里挂着 grill-me、batch-grill-me、tdd、diagnosing-bugs 这几个，用下来最直接的感受是：拷问阶段变长了，但返工变少了。以前是写完发现方向错了再推倒重来，现在是在写之前多花十分钟被追问，写完基本就是对的。