mattpocock/skills几份Markdown 文件的合集竟然获得了github近 23K 个星标！它把AI写代码、做设计的经验拆成一个个技能插件。让AI从聊天同学升级成有流程、有套路的老程序员，核心是把高手脑子里的工作法变成AI的默认行为。
亮点：这个项目提供了DDD通用语言UL— 从当前对话中提取 DDD 风格的通用语言词汇术语表的技能：
npx skills@latest add mattpocock/skills/ubiquitous-language |
换句话说：这个mattpocock/skills项目把“怎么用AI写代码、做设计、搞需求”这一整套经验，拆成一堆可以反复用的技能插件，然后直接塞给AI用。
这个项目的核心价值在于“流程标准化”加上“技能模块化”。说白了就是让AI干活不再靠玄学，不再靠运气，而是靠一套固定的靠谱套路。
这个叫mattpocock/skills的GitHub仓库在2026年4月27号突然炸了，两天时间星星从一万八千七涨到两万八。整个仓库没有一行能跑的代码，全是markdown文件。作者Matt Pocock就是把他自己电脑上那个给AI助手用的技能文件夹直接传到网上了。这套技能火的真正原因不是技术多牛，而是它教AI按正确流程干活，不是让AI自己瞎编。五个核心技能组成了一个完整的工作链条：先让AI像面试官一样问你问题搞清楚你要做什么，然后写成产品需求文档，再拆成一个个小任务，接着用测试驱动开发的方式写代码，最后检查代码架构有没有问题。
mattpocock/skills项目到底在干嘛
Anthropic公司在2025年12月18号发布了一个开放标准叫Agent Skills。就是个文件夹里放个SKILL.md文件，文件开头用YAML格式写名字和描述，后面是具体指令。AI助手启动的时候只加载名字和描述，等你真要用这个技能的时候才把整个文件读进去。这套设计叫渐进式加载，省流量的。
Matt Pocock在2026年2月3号把他自己电脑里那个~/.claude/skills/文件夹直接推到了GitHub上。他在README里写了一句特别拽的话：这是我每天用来做真工程的技能，不是在那搞氛围式编程。
整个仓库有21个技能文件夹，按照用途分了四类：规划与设计、开发、工具配置、写作与知识。每个技能都是独立的，你想用哪个装哪个。
你可以把这个项目想象成一个“AI技能外挂商店”。就像你打游戏买个外挂，能让角色自动放技能。这个项目给AI装的外挂，就是各种干活技能。
正常AI什么状态？你问它一句话，它就开始瞎猜你到底想干嘛。比如你说“帮我写个登录功能”，它可能直接甩一堆代码出来，但根本没考虑你的数据库用什么，你的项目结构什么样。
有时候AI能猜对，有时候直接翻车，完全看运气。这个项目干了件很关键的事：给AI提前准备好一堆干活剧本。这些剧本把每个任务都拆成了清晰的步骤。
举个例子，写PRD也就是产品需求文档，以前你跟AI说“帮我写个PRD”，它可能给你两段废话。现在装了技能，AI会先问你问题，理解你的需求，再设计方案，最后才写文档。
每一个技能都是一个完整的干活剧本。还有拆任务、查bug、写测试、重构代码，每一个场景都有对应的剧本。这些剧本不是临时发挥，而是按固定流程来。
而且这些技能安装起来特别简单，就一行命令。比如你想装一个写需求的技能，直接输入：
npx skills@latest add mattpocock/skills/to-prd
这就像给AI装了一个“写需求外挂”。注意，不是教它一次，而是让它永久会这个技能。下次你再让它写需求，它就知道该按什么步骤走了。
这个项目最聪明的地方是，它把那些高手程序员脑子里的经验，变成了AI可以直接用的工具。你不需要每次都给AI讲一遍流程，装一次技能就行。
五个核心技能怎么干活
第一个技能叫grill-me，翻译过来就是拷问我。整个文件只有11行，包含了最开头那几行YAML格式的信息。这个技能让AI干一件事：一个一个问题问你，每次只问一个，把所有设计决策都问遍。每个问题AI会先给出自己的建议答案，然后让你确认。如果问题能从代码库里找到答案，AI就自己去看代码，不烦你。这个技能的精髓就是逼着你在写代码之前先想清楚。
第二个技能叫to-prd，就是把当前对话变成一份正式的产品需求文档。这个技能不问你新问题，就用你已经说过的话。它会整理出问题描述、解决方案、用户故事、实现决策、测试决策、还有哪些不做。最后通过gh命令在GitHub上创建一个issue把文档存进去。
第三个技能叫to-issues，是把产品需求文档拆成一个个独立的小任务。它的拆分方式很特别，不是按前后端或者按模块拆，而是按垂直切片拆。每个切片要从数据库到界面到测试全部贯穿。每个切片会明确标记是需要人工介入还是可以全自动跑。拆完按依赖关系排序创建issue，后面的等着前面的。
第四个技能叫tdd，就是测试驱动开发。它强制要求按照红绿重构的循环干活：先写一个会挂的测试，给你确认接口设计，写最少代码让测试通过，然后重构。这个技能明确禁止那种先把所有测试写完再写代码的做法，因为一次性写一堆测试都是在验证想象出来的行为，不是验证真实的代码行为。它还附带了一堆帮助文档讲怎么测试怎么模拟依赖怎么设计接口。
第五个技能叫improve-codebase-architecture，是用来改进代码架构的。它去找那些深度不够的模块，想办法把它们变深。这个技能还带了个语言规范文件，强制只能用特定词汇讨论架构：模块、接口、实现、深度、接缝、适配器、杠杆作用、局部性。像组件、服务、API、边界这些词统统不许用。
怎么安装和使用
每个技能单独安装，命令长这样：
npx skills@latest add mattpocock/skills/grill-me
npx skills@latest add mattpocock/skills/to-prd
npx skills@latest add mattpocock/skills/to-issues
npx skills@latest add mattpocock/skills/tdd
npx skills@latest add mattpocock/skills/improve-codebase-architecture
这个命令行工具来自vercel-labs做的skills工具。默认会装到当前项目的.claude/skills/文件夹下面，加上--global参数就装到用户目录的~/.claude/skills/下面。
完整的工作流程是这样的：
先输入/grill-me让AI开始拷问你。AI一个问题一个问题地问，你回答。AI按设计树往下走，直到所有决策都理清了，然后给你一个方案。
接着输入/to-prd。AI把你刚才和它聊天的内容整理成一份结构化的产品需求文档，然后通过gh命令在GitHub上创建一个issue存起来。你之前说了什么，文档里就是什么。
然后输入/to-issues对着那份需求文档干活。AI把它拆成独立可执行的小切片，每个切片标好是需要你管还是全自动，按依赖顺序创建好issue，依赖关系自动链接好。
接下来挑一个全自动的切片，输入/tdd。AI写一个会挂的测试，让你确认一下接口设计没问题，然后写最少代码让测试通过。重复这个循环。不会一次生成一堆测试文件。
最后输入/improve-codebase-architecture。AI会去找CONTEXT.md和docs/adr/这些文档，用语言规范文件里的词汇分析架构，找出那些深度不够的地方，然后开始拷问你选哪个来改。
为什么这个仓库火了
格式根本不是重点。Anthropic四个月前就发布了完整的规范，所有人都能用。关键是Pocock在里面写的是什么，更重要的是他没写什么。
他在写流程，不是在堆知识。grill-me不告诉AI该想什么，而是告诉AI该怎么想：走遍决策树，一次问一个问题，给出建议，能从代码里找答案就别问人。这种模式贯穿所有技能。现在的AI模型早就知道TDD是什么了，但技能强制AI按这个规矩干活，不然AI就会偷懒。
每个技能范围特别窄。没有那种号称万能的大技能包。每个技能在描述里明确写了什么时候该用，AI会根据描述自己判断该不该调用。最长的技能也就170行左右，短的只有11行。
他用了禁用自动调用的标记。这是个大多数技能作者都会忽略的设计决定。Pocock明确区分了哪些技能AI可以自己决定调用，哪些必须等人手动调用。大多数技能集合把这条线模糊掉了，让AI自己瞎猜。
这玩意就是他自己的个人工具，不是包装好的框架。直接从个人文件夹导出来的，没有重新包装。分类直接就映射了一个程序员每天的工作流程，不是什么通用的人工智能开发套件。读任何一个技能文件都能看到Pocock为自己做的具体决定，不是那种写给别人的客客气气的建议。
这里有个很多人没意识到的点：AI厉害不在模型大小，而在于流程。你让一个AI直接写代码，它确实能写出来。但你让它先分析需求，再设计架构，再拆任务，再写测试，最后才写代码，效果直接翻倍。
这个差距有多大呢？直接写的代码可能能用，但后期维护起来特别痛苦。按流程写的代码，可读性高，好修改，不容易出bug。这个项目做的事情就是：把高手脑子里的流程，变成AI的默认行为。
它不是让AI自由发挥，而是让AI每一步都按流程走。而且这些流程不是随便编的，是建立在经典软件工程思想上的。比如TDD，也就是测试驱动开发，要求你先写测试再写代码。
还有DDD领域驱动设计，要求你先理解业务再设计代码。还有深模块设计，要求你把复杂逻辑封装好，对外只暴露简单的接口。翻译成人话就是：不瞎写代码，先想清楚再动手。
很多人觉得写代码就是噼里啪啦打字，其实真正厉害的程序员大部分时间在思考。这个项目就是让AI也学会思考，而不是一上来就噼里啪啦输出代码。你想想，如果一个AI能像资深工程师一样，先想清楚再动手，那它的输出质量得提升多少。以前你可能要改好几次才能满意，现在可能一次就差不多了。
这就是为什么这个项目突然火起来的原因。因为它解决了一个核心痛点：AI输出质量不稳定。有了流程，质量就稳定了。有了技能，效率就上去了。
这个系统的局限
所有涉及到issue操作的技能都硬编码了gh命令来创建GitHub的issue。用Linear、Jira或者Beads的团队得自己fork改代码。Pocock在4月27号说了支持其他平台已经在路上了。
这套东西没有文档网站。现在你想发现这些技能就只能看README和每个技能文件开头那几行描述。他确实说了要做文档网站，但发布的时候还没上线。
没有自动更新功能。重新运行安装命令是唯一拿到更新的办法。版本锁定在那个skills工具的commit哈希级别，不是你用户能控制的。
有两个技能没法直接给别人用。obsidian-vault写死了他自己的文件夹路径。scaffold-exercises依赖他个人课程里的特定工具。想用就得自己改。
他也没给自己的技能写测试用例。他自己那个教你怎么写技能的技能里面说了要做测试，但他自己这个仓库反而没做。
极客辣评
我是在同事的推荐下开始使用这项技能的，感觉还不错，测试效果好，输出结果也令人满意。不过，它有一个不足之处，那就是无法区分验收标准和验证标准。这方面它比较薄弱。
我不太喜欢插件式的方案。shadcn 模型的优势在于我可以根据自身环境进行调整。技能之间的依赖关系我不太清楚，这方面似乎需要改进文档。
我喜欢这种原始人模式，哈哈。我们需要更多像这样富有创意（而且实用）的东西！
Markdown 文件获得了 2.3 万颗星。关键不在于编写它们，而在于如何让它们足够显眼，以便人们能够找到并使用它们。
感谢你的工作。我非常喜欢“grill-me -> to-prd -> to-issues”这个流程。不过我很好奇，架构在这个流程中处于什么位置？我没有看到系统设计文档（组件、数据流等）的明确步骤。你是单独跟踪这些内容，还是让它自然而然地形成？
我希望找到一种方法来帮助优化新项目，并预先开发合适的技术栈。我发现 Grill-Me 对现有应用程序非常有效，但对新项目的性能却不尽如人意。另外，也想了解一些 Codex 的使用技巧。
2.3 万颗星表明，发现并非瓶颈，真正的问题在于使用体验。
我用的是 /grill-me 命令，配合 /ask-other-agent（Gemini 和 Codex 的输入）和 /llm-council 命令。基本上就是想把所有争论和决定都排除掉，通常这样就能达成一个非常周全的计划。