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输出质量不稳定。有了流程，质量就稳定了。有了技能，效率就上去了。
技能是怎么设计出来的
重点来了，这个项目不是简单脚本，而是结构化技能。每个技能里面都有一个核心文件叫SKILL.md。这个文件干啥呢？就是写清楚：遇到什么情况，用什么步骤干活。
这个SKILL.md文件就像一个说明书。你打开它，就能看到这个技能到底怎么工作的。比如遇到写PRD的任务，它会告诉你第一步干什么，第二步干什么，一直到最后一步。
举个例子，写PRD这个技能，它的技能名叫write-a-prd。这个技能的完整流程是：先问用户一系列问题，再理解用户的真实需求，再设计方案，再写文档，最后发成GitHub issue。
这就像什么？就是把一个产品经理的脑子复制给AI用。产品经理写需求的时候，是不是要先问清楚用户要什么，再分析业务逻辑，再写文档？这个技能完全模仿了这个过程。
而且每个技能都设计得特别细。它不是那种“你猜我要什么”的风格，而是每一步都有明确产出。比如问用户问题这一步，它会提前准备好要问哪些问题，不会漏掉关键信息。
理解需求这一步，它会用自己的话复述一遍，确认没理解错。设计方案这一步，它会列出几个方案让你选。写文档这一步，它有固定的模板。最后发GitHub issue，它连标题和标签都帮你填好。
这种设计方式的好处是，AI不会跑偏。以前你跟AI说“写个PRD”，它可能给你写出一份完全不相关的东西。现在有了这个技能，AI每一步都按剧本走，最后出来的东西质量有保障。
这个SKILL.md文件还可以被修改。你觉得某个步骤不好，可以自己改。你觉得某个步骤应该加个检查点，也可以自己加。这就让技能变得可定制，可进化。
规划与设计能力
这一类技能解决一个核心问题：“我到底要做啥？”很多程序员拿到需求就开始写代码，写着写着发现理解错了，然后推倒重来。这类技能就是为了避免这种情况。
典型技能有哪些呢？第一个是to-prd，用来生成需求文档。这个技能会把你的想法转成标准的产品需求文档。第二个是to-issues，用来拆任务。有了需求文档之后，这个技能会把大任务拆成一个个小任务。
第三个是grill-me，这个比较狠。它会像面试官一样疯狂拷问你的方案。你觉得自己想清楚了？它一问你，你就发现一堆漏洞。它问的问题特别刁钻，比如“你这个设计考虑过异常情况吗？”
而且它会一直问，一直问，问到你崩溃为止。但这恰恰是好事。因为在实际开发中，这些问题迟早会暴露出来。与其上线后被用户发现bug，不如提前被这个技能问出来。
这个grill-me技能特别适合用在方案设计阶段。你把自己的方案告诉它，它就开始拷问你。你回答不上来，说明方案有漏洞。你都能回答上来，说明方案靠谱。
这种拷问式设计，本质上是在帮你补脑子里的漏洞。人脑有个毛病，就是会自动忽略一些细节。但这个技能不会，它会把你忽略的所有细节都翻出来。
用这类技能的最大好处是，你不会在错误的方向上浪费太多时间。以前你可能花一周写代码，然后发现需求理解错了，全部重来。现在你在动手之前，先用这些技能把方案想清楚。
这就是所谓的“思而后行”。在软件工程里，前期多花一小时思考，后期能省十小时改bug。这个项目把这种思想变成了AI的默认行为。
编码与调试能力
这一类解决的核心问题是：“代码怎么写？”有了需求和任务之后，就到了真正写代码的阶段。这类技能就是为了让写代码的过程更规范，bug更少。
核心技能有几个。第一个是tdd，也就是测试驱动开发。这个技能强制你按这个流程走：先写测试，这时候测试肯定是失败的，因为你还没写代码。然后再写代码，让测试通过。最后重构代码，让它更好看。
重点来了，这个技能是一个一个小步骤推进的，不是一口气写完。每写一小段代码，就跑一次测试，确保没出问题。这就好比盖房子，你不是一口气盖完三层，而是盖一层检查一层。
这样做的好处是，你永远知道自己有没有跑偏。写了几行代码就跑测试，测试过了说明方向对。测试没过，马上就能发现，改起来也容易。不会出现写了三天代码才发现第一行就错了的情况。
第二个技能是triage-issue，用来查bug。这个技能会把bug报告读一遍，然后告诉你大概是什么原因，怎么修。它不会让你从零开始排查，而是给你一个排查方向。
第三个技能是improve-codebase-architecture，用来优化架构。代码写完了，但结构可能不好，这个技能会帮你分析哪里可以改进，然后给你具体的改法。
这类技能的核心思想是：不要一顿乱写，要边写边验证。很多初学者写代码，写完才开始想对不对。这种做法效率特别低，因为错误积累起来之后，找起来特别费劲。
TDD这个技能强制你改变习惯。你还没写代码，先写测试。这意味着你在一开始就得想清楚，这个函数到底要干什么，输入是什么，输出是什么。这本身就是一个很好的设计过程。
而且这些技能不是孤立的。你可以先用to-prd写需求，再用to-issues拆任务，再用tdd写代码，再用improve-codebase-architecture优化。这就是一个完整的开发流程。
工具与工程能力
这一块解决的是：“工程环境怎么不翻车？”很多人代码写得不错，但环境配置一塌糊涂，或者一不小心把重要东西删了。这类技能就是为了防止这些问题。
典型技能有几个。第一个是setup-pre-commit，它会帮你配置提交前的自动检查。什么意思呢？就是你每次提交代码之前，它会自动跑一遍检查，比如代码格式对不对，有没有明显的语法错误。
如果检查没通过，代码就提交不上去。这就保证了你仓库里的代码永远是干净的。不会出现那种格式乱七八糟，或者有明显bug的代码被提交上去。
第二个是git-guardrails，这个特别实用。它会防止你手滑删库。git是一个版本控制工具，功能很强大，但破坏力也很大。一不小心执行了强制删除命令，代码就没了。
这个git-guardrails技能会在你执行危险命令的时候拦住你，问你“你确定要这么做吗？”有些命令它干脆就不让你执行，除非你明确说“我知道我在做什么”。
这个技能特别真实。很多程序员不是不会写代码，而是不小心把代码删了。你想想，写了一周的代码，一个命令全没了，那种感觉想不想哭？这个技能就是给你装个后悔药防护罩。
还有一类技能是管理项目结构的。比如你新建一个项目，它会帮你生成标准的目录结构，配置文件，开发环境。你不用每次都从头搭环境，一条命令全搞定。
这类技能的价值在于，它让你专注于写代码本身，而不是在环境配置上浪费时间。配置pre-commit可能只需要五分钟，但很多人懒得配。这个技能帮你一键配好。
而且这些工具技能可以和前面的技能组合。比如你先用tdd写代码，然后用setup-pre-commit确保每次提交都检查，然后用git-guardrails防止意外删除。整个开发流程就安全了很多。
写作与知识管理能力
这一类解决的是：“怎么把知识变成资产？”很多人会写代码，但不会写文档。或者学了很多东西，但转头就忘了。这类技能就是来解决这些问题的。
技能包括几个。第一个是edit-article，用来优化文章。你写了一篇技术文章，它可以帮你润色，调整结构，改语法错误。而且它不是乱改，它会保持你的原意，只优化表达方式。
第二个是write-a-skill，这是用来写新技能的。你学会了某个工作流程，想把它变成AI可以用的技能，就用这个。它会引导你一步一步把流程写进SKILL.md文件。
第三个是obsidian-vault，用来管理笔记。Obsidian是一个笔记软件，这个技能会把你的知识整理成结构化的笔记库。你可以随时查询以前学过的东西，不会忘。
这类技能的本质是把零散信息变成结构化知识。很多人学东西的时候觉得都会了，过两周再看，全忘了。为什么？因为没有记下来，没有整理，没有形成知识网络。
用了这类技能，你学完一个东西，就可以把它写成一个技能。下次再用的时候，直接调用这个技能就行，不需要重新学一遍。你的知识就变成了可复用的资产。
不让你学完就忘，这是这类技能最大的价值。你想，如果你学过的每个东西都能被记录下来，并且能被AI直接使用，那你的学习效率得提高多少倍。
而且这类技能还有一个隐藏好处：它逼着你把模糊的理解变成清晰的表述。你脑子里觉得懂了，但写出来的时候就会发现有些地方其实没想通。这个写的过程本身就是一个深度思考的过程。
最牛的一点：技能可以组合
这个项目最骚的地方不是单个技能有多厉害，而是技能可以串起来用。就像乐高积木，单个积木没什么，但拼在一起就能搭出复杂的东西。
一个典型的完整流程是这样的：第一步，你用write-a-prd写需求文档。你告诉AI你想要什么，它会问你一堆问题，最后生成一份标准的需求文档。
第二步，你用to-issues把需求拆成小任务。需求文档里面有很多功能点，这个技能会把这些功能点拆成一个个独立的开发任务，每个任务都清晰明确。
第三步，你用tdd来写代码。从第一个任务开始，先写测试，再写代码，再重构。一个任务完成之后，再接着做下一个任务。
第四步，你用improve-codebase-architecture来优化架构。所有任务都做完了，代码也都能跑通了，但这个技能会检查一下代码结构是否合理，有没有可以优化的地方。
这就形成了一个完整的链路：从想法到计划，再到实现，再到优化。每一步都有对应的技能，每一步都有明确的产出。你不需要在每个阶段都重新教AI一遍，因为它已经知道该怎么做。
这种组合能力是这个项目真正的杀手锏。单个技能可能别人也能做，但能把这么多技能无缝串起来，形成一个完整的开发工作流，这才是厉害的地方。
你可以根据自己的需要，选择不同的技能组合。做前端项目用一套，做后端项目用另一套。做个人项目用轻量级组合，做团队项目用重量级组合。完全灵活。
而且这些技能之间是有依赖关系的。比如写代码的技能可能会用到查bug的技能，优化架构的技能可能会用到写测试的技能。这个项目已经考虑到了这些依赖，你不用手动处理。
这个系统的局限
所有涉及到issue操作的技能都硬编码了gh命令来创建GitHub的issue。用Linear、Jira或者Beads的团队得自己fork改代码。Pocock在4月27号说了支持其他平台已经在路上了。
这套东西没有文档网站。现在你想发现这些技能就只能看README和每个技能文件开头那几行描述。他确实说了要做文档网站，但发布的时候还没上线。
没有自动更新功能。重新运行安装命令是唯一拿到更新的办法。版本锁定在那个skills工具的commit哈希级别，不是你用户能控制的。
有两个技能没法直接给别人用。obsidian-vault写死了他自己的文件夹路径。scaffold-exercises依赖他个人课程里的特定工具。想用就得自己改。
他也没给自己的技能写测试用例。他自己那个教你怎么写技能的技能里面说了要做测试，但他自己这个仓库反而没做。
谁该用谁不该用
适合在真实项目上跑Claude Code的工程师，特别想要可重复的设计评审流程、测试驱动开发的纪律、还有结构化从需求到任务的转换。团队已经在用GitHub Issues的话最好，能把聊天记录变成永久文档。
不适合用Linear、Jira或Beads的团队，得等多平台支持出来。也不适合用那些还没支持SKILL.md规范的AI助手的工程师。更不适合找那种什么都能干的自动编程技能的人，因为Pocock这个仓库故意做的正好相反。
这事的真正启示
星星数两万八这个事容易让人误会，以为这仓库搞了什么新技术。并没有。它就是在人家四个月前发布的标准上面做了一套精心设计的工作流程。2026年这个时间点，真正让人意外的是品味和窄范围比功能多和框架大更能传播得远。
给技能作者们的启示不是去抄Pocock的具体技能，而是抄他的纪律：写一个11行只干一件事的技能，然后停手。
极客辣评
我是在同事的推荐下开始使用这项技能的，感觉还不错，测试效果好，输出结果也令人满意。不过，它有一个不足之处，那就是无法区分验收标准和验证标准。这方面它比较薄弱。
我不太喜欢插件式的方案。shadcn 模型的优势在于我可以根据自身环境进行调整。技能之间的依赖关系我不太清楚，这方面似乎需要改进文档。
我喜欢这种原始人模式，哈哈。我们需要更多像这样富有创意（而且实用）的东西！
Markdown 文件获得了 2.3 万颗星。关键不在于编写它们，而在于如何让它们足够显眼，以便人们能够找到并使用它们。
感谢你的工作。我非常喜欢“grill-me -> to-prd -> to-issues”这个流程。不过我很好奇，架构在这个流程中处于什么位置？我没有看到系统设计文档（组件、数据流等）的明确步骤。你是单独跟踪这些内容，还是让它自然而然地形成？
我希望找到一种方法来帮助优化新项目，并预先开发合适的技术栈。我发现 Grill-Me 对现有应用程序非常有效，但对新项目的性能却不尽如人意。另外，也想了解一些 Codex 的使用技巧。
2.3 万颗星表明，发现并非瓶颈，真正的问题在于使用体验。
我用的是 /grill-me 命令，配合 /ask-other-agent（Gemini 和 Codex 的输入）和 /llm-council 命令。基本上就是想把所有争论和决定都排除掉，通常这样就能达成一个非常周全的计划。