GitHub - mattpocock/skills: 真正工程师的技能。直接来自我的 .claude 目录。
真正工程师的技能
我每天使用的代理技能，用于进行真正的工程开发——而非“氛围编程”。
开发真正的应用程序很难。像 GSD、BMAD 和 Spec-Kit 这类方法试图通过掌控流程来提供帮助。但在此过程中，它们剥夺了您的控制权，并使得流程中的错误难以解决。
这些技能被设计得小巧、易于调整且可组合。它们适用于任何模型。它们基于数十年的工程经验。您可以随意修改它们，使其成为您自己的工具。尽情享受吧。
如果您想跟进这些技能的更新以及我创建的任何新技能，可以加入我新闻通讯中约 6 万名开发者的行列：
订阅新闻通讯
快速开始（30 秒设置）
-
运行
skills.sh安装程序：npx skills@latest add mattpocock/skills -
选择您想要的技能，以及要将其安装到哪些编码代理上。请确保您选择了
/setup-matt-pocock-skills。 - 在您的代理中运行
/setup-matt-pocock-skills。它将：- 询问您想使用哪个问题跟踪器（GitHub、Linear 或本地文件）
- 询问您在对问题进行分类时应用了哪些标签（
/triage会使用标签） - 询问您希望将创建的任何文档保存在哪里
- 砰——您就可以开始了。
这些技能为何存在
我构建这些技能是为了修复我在使用 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 技能，您可以将其插入任何项目。它鼓励红-绿-重构循环，并为代理提供了关于什么是好测试、什么是坏测试的充分指导。
对于调试，我还构建了一个 /diagnose 技能，它将最佳的调试实践封装成一个简单的循环。
#4：我们建了一团泥球
“每天都要在系统设计上进行投资。”
—— Kent Beck，《解析极限编程》
“最好的模块是深度的。它们允许通过一个简单的接口访问大量功能。”
—— John Ousterhout，《软件设计的哲学》
问题：大多数使用代理构建的应用程序复杂且难以更改。因为代理能极大加速编码，它们同时也加速了软件熵。代码库以空前的速度变得越来越复杂。
解决方案是一种激进的、由 AI 驱动的开发新方法：关心代码的设计。
这内置于这些技能的每一层：
/to-prd在创建 PRD（产品需求文档）之前，会询问您将要触及哪些模块。/zoom-out指示代理在整个系统的背景下解释代码。
关键是，/improve-codebase-architecture 能帮助您挽救一个已经变成“一团泥球”的代码库。我建议每隔几天就在您的代码库上运行一次它。
总结
软件工程基础比以往任何时候都更加重要。这些技能是我尽最大努力将这些基础浓缩成可重复的实践，以帮助您交付职业生涯中最出色的应用程序。尽情享受吧。
参考
工程类
我日常用于代码工作的技能。
- diagnose —— 用于疑难 bug 和性能回归的有条理的诊断循环：复现 → 最小化 → 假设 → 检测 → 修复 → 回归测试。
- grill-with-docs —— “拷问”会话，它会根据现有的领域模型挑战您的计划，完善术语，并内联更新
CONTEXT.md和 ADR。 - triage —— 通过一个具有分类角色的状态机来对问题进行分类（triage）。
- improve-codebase-architecture —— 在代码库中寻找可以深化的机会，依据
CONTEXT.md中的领域语言和docs/adr/中的决策进行。 - setup-matt-pocock-skills —— 搭建每个仓库的配置（问题跟踪器、分类标签词汇表、领域文档布局），供其他工程类技能使用。在使用
to-issues、to-prd、triage、diagnose、tdd、improve-codebase-architecture或zoom-out之前，在每个仓库中运行一次。 - tdd —— 带有红-绿-重构循环的测试驱动开发。一次一个垂直切片地构建功能或修复 bug。
- to-issues —— 将任何计划、规格说明或 PRD 按垂直切片分解成可独立领取的 GitHub issues。
- to-prd —— 将当前对话上下文转换为 PRD，并将其作为 GitHub issue 提交。无需访谈——只需综合您已经讨论过的内容。
- zoom-out —— 指示代理拉远视角，针对不熟悉的代码部分给出更广泛的背景或更高层次的视角。
- prototype —— 构建一个一次性原型来完善设计——要么是一个可运行的终端应用（用于解决状态/业务逻辑问题），要么是几个可以在一个路由下切换的、截然不同的 UI 变体。
生产力类
通用工作流工具，不特定于代码。
- caveman —— 极简沟通模式。通过去除填充词，同时保持完整的技术准确性，减少约 75% 的 token 使用量。
- grill-me —— 让代理对一个计划或设计进行无休止的追问，直到决策树的每一个分支都得到解决。
- handoff —— 将当前对话压缩成一份交接文档，以便另一个代理可以继续工作。
- write-a-skill —— 创建具有适当结构、渐进式披露和捆绑资源的新技能。
其他类
我保留但很少使用的工具。
- git-guardrails-claude-code —— 为 Claude Code 设置钩子，在执行前阻止危险的 git 命令（push、reset –hard、clean 等）。
- migrate-to-shoehorn —— 将测试文件从
as类型断言迁移到 @total-typescript/shoehorn。 - scaffold-exercises —— 创建带有章节、问题、解决方案和讲解器的练习目录结构。
- setup-pre-commit —— 使用 Husky pre-commit 钩子设置 lint-staged、Prettier、类型检查和测试。
关于
真正工程师的技能。直接来自我的 .claude 目录。
