原文标题： mattpocock skills
真正工程师的技能
我每天用来做真正工程（而非“氛围编码”）的智能体技能。开发真正的应用程序是困难的。像 GSD、BMAD 和 Spec-Kit 这类方法试图通过掌控流程来提供帮助，但这样做却剥夺了你的控制权，并使流程中的 bug 难以解决。
这些技能的设计理念是：小巧、易于调整、可组合。它们适用于任何模型。它们基于数十年的工程经验。你可以随意摆弄它们，让它们成为你自己的。尽情享受吧。
如果你想了解这些技能的更新以及我创建的任何新技能，可以加入我的通讯，已有约 60,000 名开发者订阅： [订阅通讯](Sign Up To The Newsletter)
快速开始（30 秒设置）
运行 skills.sh 安装器：
npx skills@latest add mattpocock/skills选择你想要的技能，以及你想将它们安装到哪些编码智能体上。确保你选择了 /setup-matt-pocock-skills。
在你的智能体中运行 /setup-matt-pocock-skills。它会：
- 询问你想使用哪个问题跟踪器（GitHub、Linear 或本地文件）
- 询问你在分类工单时应用哪些标签（
/triage使用标签） - 询问你想将我们创建的任何文档保存在哪里
搞定——你已经准备好开始使用了。
作为 Claude Code 插件安装
更喜欢即插即用、无需手动维护的安装方式？这些技能也作为原生 Claude Code 插件提供。
插件不是将可编辑文件复制到你的仓库中，而是将整套技能作为一个托管包安装，当我发布新版本时会自动更新——你订阅而非分叉。
在 Claude Code 内部：
/plugin marketplace add mattpocock/skills
/plugin install mattpocock-skills@mattpocock或者从你的终端：
claude plugin marketplace add mattpocock/skills
claude plugin install mattpocock-skills@mattpocock然后每个仓库运行一次 /setup-matt-pocock-skills，与上面的快速开始完全一样。
两种安装方式，两种理念：
- skills.sh 将技能复制到你的项目中，这样你可以修改它们，让它们成为你自己的。
- 插件 将它们作为只读、始终最新的包保留，你不进行编辑——当你只想使用我的这套技能并跟随其演变时，这是最佳选择。
使用 Codex 或其他智能体？
skills.sh 安装器目前已经可以将这些技能安装到 Codex 和其他遵循 Agent-Skills 标准的框架中。原生 Codex 插件已在路线图中——参见 .agents/adr/0002-ship-as-a-claude-code-plugin.md。
为什么存在这些技能
我构建这些技能是为了修复我在 Claude Code、Codex 和其他编码智能体中常见的失败模式。
#1：智能体没有按我的意愿行事
“没有人确切知道他们想要什么。”
—— David Thomas & Andrew Hunt，《程序员修炼之道》
问题：软件开发中最常见的失败模式是错位。你认为开发者知道你想要什么。然后你看到他们构建的东西——你意识到它根本没有理解你。这在人工智能时代也是如此。你和智能体之间存在沟通鸿沟。
修复方法是进行一次“拷问会话”——让智能体就你正在构建的内容向你提出详细问题。
使用以下技能：
/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：我们构建了一团泥球
“投资于…