mattpocock/skills的安装使用
codex中的使用
1、安装命令
正常使用该命令以下命令安装;
npx skills@latest add mattpocock/skills目前还没有codex的agents安装方式,所以采用全局安装方式来使用这些skill;
npx skills@latest add mattpocock/skills --agent codex --global
通过以下命令检查是否安装成功;
npx skills@latest list --global --agent codex
2、选择skill
一些skill是项目级,一些skill是全局级的;
这里展示的只是其中一部分,想要其它的skill可再进入该仓库mattpocock/skills查看;
1、/setup-matt-pocock-skills
这个初始化 Skill,装完后在 AI 编程工具里运行一次:
AI 会问你几个问题来适配你的项目。比如用什么工具来管理 Issue、项目文档保存在哪个目录。
2、/grill-me 需求拷问
它的作用是让 AI 反过来对你进行「灵魂拷问」,帮你在让 AI 写代码之前把需求和设计想清楚。
它的核心内容加起来竟然只有 3 句话!
- 针对我的计划或设计,一个问题一个问题地追问我,直到我们达成共识。沿着决策树的每个分支走下去,逐个解决分支之间的依赖关系。每个问题要给出你的推荐答案。
- 每次只问一个问题,等我回答完再问下一个。一次抛出一堆问题会让人不知所措。
- 能通过查看环境(文件系统、工具等)找到的事实,直接去查,不用问我。但决策是我来做的,每个决策都要等我拍板。
3、/tdd 测试驱动开发
当你要求 AI 用测试驱动的方式来开发时,它会一口气先把所有测试写完,然后再写所有代码。
这种方式看起来效率很高,但实际上有个很坑的问题。AI 在写测试的时候,代码还不存在,所以它只能靠想象来设计测试的结构。等真正开始写代码的时候,实际的 API 可能跟它想象的完全不一样,结果就是一堆测试要推倒重写。
/tdd 这个 Skill 就是来解决这个问题的。它强制 AI 用「垂直切片」的方式来工作,也就是先写一个测试让它失败 ❌,然后只写刚好能让这个测试通过的代码 ✅,通过之后再写下一个测试。这就是经典的 Red-Green-Refactor 循环,一次只走一小步,每一步都是实打实验证过的。
除了循环本身,这个 Skill 里还有几条值得注意的规则。
比如它要求 只在预先商定的接缝处测试。所谓接缝(Seam)就是代码的公开接口,比如一个函数的入参和返回值。在写任何测试之前,AI 会先跟你确认在哪些接缝处写测试,而不是到处乱写,这样测试的覆盖重点才能落在真正重要的地方。
另外这个 Skill 还列出了几种 AI 写测试时容易犯的反模式,相当于给 AI 定了规矩,一旦发现自己写出了这类测试就必须改掉。
对于团队项目来说,让 AI 按照 TDD 的方式来写代码,代码质量会有明显的提升。
4、/diagnosing-bugs Bug 诊断
遇到 Bug 的时候,很多人的第一反应都是先看代码,猜一个可能的原因然后试着改。AI 也是这样的,大家应该有过这种经历,让 AI 修 Bug,结果它改了半天越改越乱。
Matt Pocock 认为问题的根源在于 AI 跳过了最关键的一步,就是先建立一个 能稳定重现 Bug 的反馈循环。
什么叫反馈循环呢?
简单来说就是一条能稳定重现 Bug 的命令。可以是一个会失败的测试用例、一个 curl 请求、甚至一个 Playwright 浏览器自动化脚本,只要能一键运行并且明确告诉你 Bug 到底有没有触发就好。
/diagnosing-bugs 这个 Skill 把 Debug 过程拆成了 6 个阶段,其中「建立反馈循环」是第一步,也是整个流程的核心。
在这步完成之前,AI 不允许跳到「猜原因」的阶段。如果 AI 在还没有一条能重现 Bug 的命令的时候就开始分析代码,Skill 会直接打断它。
等有了一条稳定重现的命令之后,接下来的步骤就比较常规了。最小化重现场景、提出假设并逐一验证、修复并写回归测试。
这个思路跟 Cursor 内置的 Debug 模式有点异曲同工。Cursor 的 Debug 模式也是先通过自动检测和分析错误来定位问题,而不是让 AI 上来就瞎猜和乱改。
不过 /diagnosing-bugs 更偏向于流程规范,它用一套严格的分阶段方法来约束 AI 的调试行为。先让 AI 建一个靠谱的重现方式,后面的修复效率反而会高很多。
5、/teach AI 辅助学习
前面几个 Skill 都跟写代码有关,但这个仓库里还有一些通用的生产力工具。比如 /teach 技能,作用是让 AI 变成你的私人教师。
这个技能不只是让 AI 给你讲个知识那么简单,它背后有一套相当完整的教学方法论。
当你运行 /teach 并告诉 AI 你想学什么之后,AI 会先问你为什么想学这个东西?
然后 AI 会把你的学习目标记录到一个叫 MISSION.md 的文件里。
接着它会去搜索高质量的学习资源,整理成 RESOURCES.md 资源文件。
最后基于收集到的资源给你设计课程,每堂课是一个精美的 HTML 文件,保存在 lessons/ 目录下。
值得一提的是,AI 会区分「流畅度」和「存储强度」这两种学习效果。流畅度就是你当场能回忆起来的感觉,但这不代表你真的记住了。存储强度才是真正的长期记忆。所以它会刻意设计有一定难度的练习,用间隔重复和交错练习等方法来帮你加深记忆,而不是让你产生「我已经学会了」的错觉。
还有个很妙的设计是「最近发展区」,这是教育学里的经典理论。AI 会根据你之前的学习记录来判断你现在的水平,然后设计刚好超出你能力一点点的课程内容,不会太简单让你感到无聊,也不会太难让你放弃。
而且你的所有学习过程都被保存在当前目录下,下次打开同一个目录继续学的时候,AI 就能接着上次的进度来,有种 AI 时代的个性化教育的感觉。
6、/wayfinder 大项目规划
这个 Skill 专门解决一个问题:当项目大到一个 AI 对话装不下的时候,该怎么办?
用过 AI 编程的同学应该都有感受,如果你强行在一个很长的对话里完成所有事情,AI 的思考质量会随着上下文变长而明显下降。Matt Pocock 把 AI 表现最好的上下文范围叫做「智能区间」,大概在 120K tokens 以内。
/wayfinder 的做法是把一个大需求拆成一张「决策地图」。当你面对一个大而模糊的需求时,AI 会先跟你一起把最终目标定义清楚,然后在 Issue 管理工具里创建一张地图,上面列出需要做的一系列决策,每个决策是一个独立的 Issue。
这些决策之间有依赖关系,所以它会自动标注哪些可以先做、哪些要等前置决策完成才能开始。
每次你打开一个新的 AI 对话来处理一个决策的时候,上下文都是干净的,不会被之前的内容污染。
这个思路其实跟企业开发中的「模块化」很像,把一个大项目拆成多个模块分给不同的开发者,每个人只需要关注自己负责的部分。
这里面还有一个很有趣的设计叫「战争迷雾」,就像游戏里没探索过的地图区域一样。你现在能看到的决策只是一部分,随着前面的决策逐步完成,后面的决策才会逐渐清晰起来。这样可以避免一开始就过度规划那些还想不清楚的事情。
不过这个 Skill 的门槛相对比较高,更适合有一定工程经验的开发者来使用。如果你的项目规模不大,前面提到的 /grill-me 就够用了。
7、/improve-codebase-architecture 代码架构改进
除了日常的开发流程,Matt Pocock 还建议每隔几天就跑一次 /improve-codebase-architecture 技能,相当于定期给代码做一次体检。它会深度扫描你的代码库,找出那些结构上可以优化的地方。
代码扫描完成后,AI 会生成一个可视化的 HTML 报告,而不是枯燥的文字。报告里用 Tailwind 美化样式、用 Mermaid 画架构图,每个优化建议都是一张卡片,上面写着涉及的文件、当前的问题、建议的改进方案,还有改进前后的对比图。
每个建议还会标注推荐程度,有些是强烈推荐的,有些是值得探索的,有些只是试探性的。你选一个感兴趣的之后,它就会启动一轮新的 grilling 对话来跟你讨论具体怎么改。
这个 Skill 背后的核心理念来自《A Philosophy of Software Design》这本书。打个比方,一个好的模块就像微波炉,你只需要按几个按钮就能加热食物,内部的电磁波原理完全不用管。这种叫做「深」模块,接口简单,实现复杂。
但如果一个模块用起来跟自己写一个差不多费劲,那就是「浅」模块了。这个 Skill 要找的就是代码库里那些「浅」模块,帮你把它们变成「深」模块。
8、/handoff 上下文交接
大家用 AI 编程的时候应该都遇到过这个问题:在一个对话里讨论了很多内容,积累了大量上下文,但是要开一个新对话的时候,之前的所有讨论就全丢了。
虽然可以手动复制粘贴,但是比较麻烦,还容易遗漏关键信息。
/handoff 技能就是来解决这个问题的。在你当前对话结束前,它会让 AI 把整个对话的核心内容压缩成一份交接文档,保存成一个 Markdown 文件。
下次开新对话的时候,只要让 AI 读一下这个文件,它就能接着上次的进度继续工作。
这个交接文档还会标注建议在新对话中使用哪些 Skill,并且会自动去除敏感信息,比如 API 密钥之类的。
这样一来,多轮对话之间可以无缝协作了。
9、planning-with-files-zh
按计划行事,并且可防止会话突然中断,后续仍然可以继续完成任务。