真正工程师的技能
我每天用来做真正工程（而非“氛围编程”）的智能体技能。开发真正的应用是困难的。像 GSD、BMAD 和 Spec-Kit 这类方法试图通过掌控流程来提供帮助。但这样做，它们剥夺了你的控制权，并使流程中的缺陷难以解决。
这些技能被设计得小巧、易于调整且可组合。它们适用于任何模型。它们基于数十年的工程经验。随意修改它们，让它们成为你自己的。祝愉快。
如果你想随时了解这些技能的更新，以及我创建的任何新技能，你可以加入我的通讯，与约 6 万名开发者一起：订阅通讯
安装（30 秒设置）
两种方式，两种理念。Claude Code 插件将整套技能作为受管理的只读捆绑包安装，当我发布更新时会自动更新——你是订阅而非分叉。skills.sh 会将可编辑的技能文件复制到你的项目中，这样你就可以修改它们并使其成为你自己的。选择其一——如果同时安装两者，每个技能都会出现两次。
1. 获取技能
Claude Code
claude plugins install mattpocock-skills或者，在会话内部：
/plugin install mattpocock-skills它位于 Claude Code 的官方市场中，因此无需预先添加任何内容，更新会自动到达。
Codex 及其他智能体
npx skills@latest add mattpocock/skills选择你想要的技能，以及要安装到哪些编码智能体上。安装程序会让你选择要获取哪些技能——确保 setup-matt-pocock-skills 是其中之一。原生 Codex 插件已在路线图中——参见 .agents/adr/0002-ship-as-a-claude-code-plugin.md。
对于喜欢动手修改的用户
在任何智能体上使用相同的安装程序——包括 Claude Code：
npx skills@latest add mattpocock/skills它会将技能作为普通文件写入你的仓库，这些文件归你所有且可编辑。不会有任何东西在你不知情的情况下更新；当你想要我的最新更改时，运行 npx skills update 即可。
2. 运行 /setup-matt-pocock-skills
在你的智能体中，每个仓库运行一次。它会：
- 询问你想使用哪个问题跟踪器（GitHub、Linear 或本地文件）
- 询问你在分类工单时应用哪些标签（
/triage使用标签） - 询问你想将我们创建的任何文档保存到哪里
3. 搞定——你可以开始使用了。
这些技能为何存在
我构建这些技能是为了修复我在 Claude Code、Codex 和其他编码智能体中常见的失败模式。
#1：智能体没有做我想做的事
“没有人确切知道自己想要什么”——David Thomas & Andrew Hunt，《程序员修炼之道》
问题：软件开发中最常见的失败模式是错位。你以为开发者知道你想要什么。然后你看到他们构建的东西——你意识到它根本没有理解你。在 AI 时代也是如此。你和智能体之间存在沟通鸿沟。解决这个问题的方法是进行一场“拷问式会话”——让智能体就你正在构建的内容向你提出详细问题。
解决方案是使用：
/grill-me- 用于非代码用途/grill-with-docs- 与/grill-me相同，但增加了更多功能（见下文）
这些是我最受欢迎的技能。它们帮助你在开始之前与智能体对齐，并深入思考你正在进行的更改。每次你想要做出更改时都使用它们。
#2：智能体过于啰嗦
“通过一种无处不在的语言，开发者之间的对话和代码的表达都源自同一个领域模型。”——Eric Evans，《领域驱动设计》
问题：在项目开始时，开发者和他们为其构建软件的人（领域专家）通常说着不同的语言。我对我的智能体也有同样的感受。智能体通常被投入到项目中，并要求在过程中自行理解行话。所以它们用 20 个词来表达 1 个词就能说清的事情。
解决方案是共享语言。这是一份帮助智能体解码项目中使用的行话的文档。
示例
以下是一个来自我的 course-video-manager 仓库的 CONTEXT.md 示例。哪一个更容易阅读？
之前：“当课程某个部分中的一课被设为‘真实’（即在文件系统中获得一个位置）时，存在一个问题”
之后：“物化级联存在问题”
这种简洁性在一次次会话中不断带来回报。这已内置于 /grill-with-docs 中。它是一场拷问式会话，但帮助你和 AI 建立共享语言，并将难以解释的决策记录在 ADR 中。
很难解释这有多强大。它可能是这个仓库中最酷的技术。试试看吧。
提示
共享语言除了减少啰嗦之外还有许多其他好处：
- 变量、函数和文件使用共享语言一致地命名
- 因此，智能体更容易导航代码库
- 智能体在思考上花费的 token 也更少，因为它可以访问更简洁的语言
#3：代码不工作
“始终采取小而谨慎的步骤。反馈的速度就是你的速度极限。永远不要承担太大的任务。”——David Thomas & Andrew Hunt，《程序员修炼之道》
问题：假设你和智能体在构建什么上达成了一致。当智能体仍然产出糟糕的代码时会发生什么？是时候审视你的反馈循环了。如果智能体无法获得关于其生成的代码实际运行情况的反馈，它就是在盲飞。
解决方案：你需要通常的一系列反馈循环：静态类型、浏览器访问和自动化测试。对于自动化测试，红-绿-重构循环至关重要。这就是智能体先编写一个失败的测试，然后修复该测试。这有助于给智能体提供一致的反馈水平，从而产生更好的代码。
我构建了一个 /tdd 技能，你可以将其插入任何项目。它鼓励红-绿-重构，并为智能体提供大量关于什么是好测试和坏测试的指导。对于调试，我还构建了一个 /diagnosing-bugs 技能，将最佳调试实践封装到一个有纪律的循环中，逐阶段把关。
#4：我们构建了一个泥球
“每天投资于系统的设计。”——Kent Beck，《解析极限编程》
“最好的模块