面向真实工程师的技能
我每天用来做真实工程——而非 vibe coding——的 agent 技能。
开发真实应用很难。GSD、BMAD 和 Spec-Kit 这类方法试图通过接管流程来提供帮助。但这样做时，它们剥夺了你的控制权，并让流程中的 bug 难以解决。
这些技能被设计得小巧、易于调整、可组合。它们适用于任何模型。它们基于数十年的工程经验。
尽管拿去折腾。把它们变成你自己的。玩得开心。
如果你想跟上这些技能的变化，以及我创建的任何新技能，可以加入我的 newsletter，和其他约 60,000 名开发者一起：订阅 Newsletter
安装（30 秒设置）
两种方式，两种理念。
Claude Code 插件会把整套技能作为一个受管理的只读包安装，并在我发布时更新，所以你是在订阅，而不是 fork。skills.sh 则会把可编辑的技能文件复制到你的项目中，这样你就可以折腾它们，把它们变成你自己的。
选一个：两个都装会让你每个技能都有两份。
1. 获取技能
Claude Code
claude plugins install mattpocock-skills或者，在会话中执行：
/plugin install mattpocock-skills它在 Claude Code 的官方 marketplace 中，所以不需要先添加任何东西，更新也会自动到达。
Codex 和其他 agents
npx skills@latest add mattpocock/skills选择你想要的技能，以及要把它们安装到哪些 coding agents 上。安装器会让你选择要采用哪些技能，所以确保 setup-matt-pocock-skills 是其中之一。
原生 Codex 插件已在路线图中（见 .agents/adr/0002-ship-as-a-claude-code-plugin.md）。
给爱折腾的人
在任意 agent 上使用同一个安装器，包括 Claude Code：
npx skills@latest add mattpocock/skills它会把技能作为普通文件写入你的 repo，这些文件归你所有，也可以编辑。不会有任何东西在你背后更新；当你想要我的最新改动时，用 npx skills update 拉取即可。
2. 运行 /setup-matt-pocock-skills
在你的 agent 中，每个 repo 运行一次。它会：
- 询问你想使用哪个 issue tracker（GitHub、Linear 或本地文件）
- 询问你在 triage tickets 时会应用哪些 labels（
/triage会使用 labels） - 询问你希望把我们创建的任何文档保存在哪里
3. 砰——你准备好了。
为什么会有这些技能
我构建这些技能，是为了修复我在 Claude Code、Codex 和其他 coding agents 中看到的常见失败模式。
#1：Agent 没有做我想要的事
“没有人确切知道自己想要什么”
David Thomas & Andrew Hunt，《The Pragmatic Programmer》
问题。软件开发中最常见的失败模式是错位。你以为 dev 知道你想要什么。然后你看到他们构建的东西——你意识到它完全没理解你。
在 AI 时代也是一样。你和 agent 之间存在沟通鸿沟。
对此的修复方式是一次 grilling session——让 agent 就你正在构建的东西向你提出详细问题。
修复方式是使用：
/grill-me- 用于非代码用途/grill-with-docs- 与/grill-me相同，但增加了更多好东西（见下文）
这些是我最受欢迎的技能。它们帮助你在开始前与 agent 对齐，并深入思考你正在做的变更。每次你想做变更时都使用它们。
#2：Agent 太啰嗦了
有了无处不在的语言，开发者之间的对话和代码表达都源自同一个领域模型。
Eric Evans，Domain-Driven-Design
问题：在项目开始时，devs 和他们正在为其构建软件的人（领域专家）通常说着不同的语言。
我和我的 agents 也有同样的紧张关系。Agents 通常被丢进一个项目，然后被要求边做边弄懂术语。所以它们会用 20 个词来表达 1 个词就能表达的内容。
修复方式是共享语言。它是一份文档，帮助 agents 解码项目中使用的术语。
示例
这里有一个示例词汇表（在那个 pinned commit 中仍名为 CONTEXT.md，那时这些技能还没有重命名这个约定），来自我的 course-video-manager repo。
哪一个更容易读？
之前：“当课程某个 section 里的 lesson 被‘real’化（也就是在文件系统中获得一个位置）时，会出现一个问题”
之后：“materialization cascade 会出现一个问题”
这种简洁性会在一个又一个 session 中带来回报。
这已内置于 /grill-with-docs。它是一次 grilling session，但会帮助你与 AI 构建共享语言，并把难以解释的决策记录到 ADR 中。
很难解释这有多强大。它可能是这个 repo 里最酷的技术。试试看吧。
提示
共享语言除了减少啰嗦之外还有很多其他好处：
- 变量、函数和文件都使用共享语言进行一致命名
- 因此，codebase 对 agent 来说更容易导航
- agent 也会在思考上花费更少 tokens，因为它可以使用更简洁的语言
#3：代码不工作
“始终采取小而审慎的步骤。反馈速度就是你的速度上限。永远不要承担过大的任务。”
David Thomas & Andrew Hunt，《The Pragmatic Programmer》
问题：假设你和 agent 已经就构建什么达成一致。如果 agent 仍然产出垃圾怎么办？
是时候看看你的反馈循环了。如果对代码实际运行情况没有反馈，agent 就会盲飞。
修复方式：你需要常见的那一套反馈循环：静态类型、浏览器访问和自动化测试。
对于自动化测试，red-green-refactor 循环至关重要。也就是 agent 先写一个失败测试，然后修复测试。这有助于给 agent 提供一致水平的反馈，从而产生好得多的代码。
我构建了一个 /tdd 技能，你可以把它接入任何项目。它鼓励 red-green-refactor，并就什么算好测试、什么算坏测试给 agent 提供大量指导。
对于调试，我还构建了一个 /diagnosing-bugs 技能，它把最佳调试实践包装成一个有纪律的循环，并逐阶段设 gate。
#4：我们造出了一团泥球
“投资于 t