很多人用 Claude Code 的方式，从根本上就错了。
不是说他们不会用提示词，也不是说他们的代码质量不好——而是他们把一个能自主工作的 AI agent 当成了一个高级补全工具：你说想要什么功能，它就写什么功能，你说改哪里，它就改哪里。这套工作流在小需求上跑得挺顺，需求稍微复杂一点，就开始出现那种熟悉的循环：代码越来越长，逻辑越来越乱，每次修改都引发新的错误，最后花在让 AI "读懂上下文"上的时间，已经比自己动手还多。
问题的根源其实很清楚。AI agent 在没有规范约束的情况下，会把所有问题都当成一次性的代码生成任务；它不会主动问你"这个功能边界在哪里"，不会拒绝一个模糊的需求，也不会告诉你这个方案三周后维护起来有多痛苦，它只会根据你说的话，立刻写出一个可以跑起来的版本——这就是大家管它叫"vibe coding"的地方，听起来很舒服，但生产代码里那种味道，只有你自己清楚。
mattpocock/skills 这个项目想解决的，是这个工作方式的底层缺陷。
Matt Pocock 是 TypeScript 领域颇有名气的工程师和教育者，他把自己实际放在 .claude 目录下、每天真正在用的 agent skills 开源了出来，分成四个大类：规划设计类、代码开发类、工具配置类、写作知识管理类，总共二十多个。它不是一套教程，也不是一套 prompt 模板；它是一组"给 agent 加装的工作规范"，每一个 skill 都规定了这个 agent 在被激活后应该以什么姿态介入你的工作。
具体来说能做什么，可以从几个典型 skill 感受一下。grill-me 会在你有任何设计方案时，用逼问的方式把所有决策分支都逼出来，直到决策树上没有悬而未决的分叉，它才罢手——相当于给你强行安排了一次 design review，而且是那种不给你留面子的。to-prd 会把你和 agent 已经讨论过的内容直接综合成一份 PRD，提交成 GitHub issue，不需要重新采访你、不需要让你再填一遍需求表，它只是把已有的对话上下文整理成规范格式。tdd 则是强制按 red-green-refactor 的循环走，一次只做一个垂直切片，把功能边界和测试用例绑在一起，而不是写完一大块代码再回头补测试。git-guardrails-claude-code 则更实际：给 Claude Code 设置 hooks，在执行 git push --force、reset --hard、clean 这类高风险命令之前自动拦截，防止 AI agent 在某个误判时把本地工作直接冲掉。
这些 skills 背后的逻辑是一致的——让 AI agent 在写代码之前先做工程师该做的事。
人类工程师里有一种很常见的毛病：只要需求一到手，立刻就开始写代码，假装自己已经把问题想清楚了，其实是在边写边想；等发现方向不对，已经写了三百行，删起来太可惜，就开始把错误的方向硬撑下去。AI agent 在没有约束的情况下，会把这个毛病放大十倍——它的执行速度太快，快到你来不及叫停；它的代码看起来又太像回事，快到你不好意思质疑。skills 项目想建立的，是一套让 agent 慢下来的机制，在规划阶段充分展开不确定性，在开发阶段严格限定步长，在工具配置阶段建立安全边界，归根结底是把那些资深工程师才有的工作直觉，写成了 agent 能跑的规范。
当然，你可以说这些 skills 本身不复杂，自己也能写。但"自己也能写"和"有一套已经在真实工作中跑通的版本摆在那里"之间，隔着的不是技术门槛，而是那种愿意把自己的工作方式整理清楚、然后公开出来的劲头，而这件事，大部分工程师从来没做过。
https://github.com/mattpocock/skills
