@mattpocockuk：感谢大家的200k stars

感谢各位的 20 万 star https://t.co/UtVMpTx9cZ — # mattpocock/skills 来源：https://github.com/mattpocock/skills # 真正工程师使用的 Skills skills.sh (https://skills.sh/mattpocock/skills) 我每天用来做真正工程开发的 agent skills——不是 vibe coding。开发真正的应用程序很难。像 GSD、BMAD 和 Spec-Kit 这类方法试图通过掌控整个流程来提供帮助。但这样做会夺走你的控制权，并且让流程中的 bug 难以解决。这些 skills 被设计为小巧、易于修改、可组合。它们适用于任何模型。它们基于数十年的工程经验。随便改，把它们变成你自己的。享受吧。如果你想了解这些 skills 的变更以及我创建的任何新 skills，可以加入我的 newsletter，和大约 6 万名开发者一起：订阅 Newsletter (https://www.aihero.dev/s/skills-newsletter) ## 安装（30 秒搞定）两种安装方式，两种理念。Claude Code 插件 (https://code.claude.com/docs/en/plugins) 将整套 skills 作为受管、只读的捆绑包安装，当我发布更新时它会自动更新——你是订阅而不是 fork。skills.sh (https://skills.sh/mattpocock/skills) 会将可编辑的 skill 文件复制到你的项目中，这样你就可以修改它们，把它们变成你自己的。二选一——如果两个都装，每个 skill 都会出现两份。 ### 1. 获取 skills Claude Code bash claude plugins install mattpocock-skills 或者在会话内运行：/plugin install mattpocock-skills 它在 Claude Code 的官方市场中，所以无需预先添加任何东西，更新会自动到达。 Codex 和其他 agents bash npx skills@latest add mattpocock/skills 选择你想要的 skills，以及要安装到哪些编码 agent 上。安装器会让你选择要安装哪些 skills——确保 setup-matt-pocock-skills 是其中之一。 原生 Codex 插件已在路线图上——参见 .agents/adr/0002-ship-as-a-claude-code-plugin.md。 喜欢折腾的人 在任意 agent 上使用同一个安装器——包括 Claude Code：bash npx skills@latest add mattpocock/skills 它会将 skills 作为你拥有且可编辑的普通文件写入你的仓库。不会有任何东西在背后自动更新；想更新时用 npx skills update 拉取我的最新更改即可。 ### 2. 运行 /setup-matt-pocock-skills 在你的 agent 中，每个仓库运行一次。它会：- 询问你想使用哪个问题跟踪器（GitHub、Linear 或本地文件）- 询问你在分流（triage）工单时应用哪些标签（/triage 使用标签）- 询问你想把创建的文档保存在哪里 ### 3. 搞定——你可以开始使用了。 ## 这些 Skills 为什么存在我构建这些 skills 是为了修复我在 Claude Code、Codex 和其他编码 agent 身上看到的常见失败模式。 ### #1：Agent 没有做我想做的事 > “没有人确切知道他们想要什么” > > David Thomas & Andrew Hunt，《程序员修炼之道》(https://www.amazon.co.uk/Pragmatic-Programmer-Anniversary-Journey-Mastery/dp/B0833F1T3V) 问题。软件开发中最常见的失败模式是认知不一致。你以为开发人员知道你想要什么。然后你看到他们构建的东西——你意识到它根本没理解你。在 AI 时代也是如此。你和 agent 之间存在沟通鸿沟。解决办法是盘问环节（grilling session）——让 agent 就你要构建的内容向你提出详细问题。解决方案是使用：- /grill-me - 用于非代码场景 - /grill-with-docs - 与 /grill-me 相同，但增加了更多功能（见下文）这些是我最受欢迎的 skills。它们帮助你在开始之前与 agent 对齐，并深入思考你要做的变更。每次想做变更时都要使用它们。 ### #2：Agent 太啰嗦了 > 有了统一语言，开发者之间的对话和代码的表达都源自同一个领域模型。> > Eric Evans，《领域驱动设计》(https://www.amazon.co.uk/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215) 问题：在项目开始时，开发人员和软件的构建对象（领域专家）通常说着不同的语言。我对我的 agents 也有同样的感受。Agents 通常被丢进一个项目，让它们边做边弄清楚行话。所以它们用 20 个词来表达 1 个词就能说清的事。解决方案是建立一种共享语言。这是一份帮助 agent 解码项目中行话的文档。示例这是我 course-video-manager 仓库中的一个 CONTEXT.md (https://github.com/mattpocock/course-video-manager/blob/076a5a7a182db0fe1e62971dd7a68bcadf010f1c/CONTEXT.md) 示例。哪个更容易读？- 之前：“当课程某个章节中的一课变成‘真实’（即在文件系统中有了一个位置）时，会出现一个问题”- 之后：“物化级联（materialization cascade）存在问题”这种简洁性让每一次会话都受益。这已内置到 /grill-with-docs 中。它是一次盘问环节，但会帮助你与 AI 建立共享语言，并将难以解释的决策记录到 ADR 中。很难解释这有多么强大。它可能是这个仓库中最酷的技巧。试试看就知道了。> [!TIP] > 共享语言除了减少冗长之外还有很多其他好处：> > - 变量、函数和文件命名一致，使用共享语言 > - 因此，agent 更容易浏览代码库 > - agent 在思考上花费更少的 token，因为它可以使用更简洁的语言 ### #3：代码不工作 > “始终采取小而谨慎的步骤。反馈的速度就是你的速度上限。永远不要接手太大的任务。”> > David Thomas & Andrew Hunt，《程序员修炼之道》(https://www.amazon.co.uk/Pragmatic-Programmer-Anniversary-Journey-Mastery/dp/B0833F1T3V) 问题：假设你和 agent 已经对齐了要构建的内容。当 agent 仍然产出垃圾代码时怎么办？是时候审视你的反馈循环了。如果对其产出的代码实际运行情况没有反馈，agent 就是在盲飞。解决方案：你需要一整套常见的反馈循环：静态类型、浏览器访问和自动化测试。对于自动化测试，红-绿-重构循环至关重要。也就是 agent 先写一个失败的测试，然后修复这个测试。这有助于给 agent 提供一致的反馈水平，从而产出更好的代码。我构建了一个 /tdd skill，你可以将其插入任何项目。它鼓励红-绿-重构，并给 agent 提供大量关于好测试和坏测试的指导。对于调试，我还构建了一个 /diagnosing-bugs skill，将最佳调试实践封装成一个简单的循环。 ### #4：我们构建了一个大泥球 > “_每天_都投资于系统的设计。”> > Kent Beck，《解析极限编程》(https://www.amazon.co.uk/Extreme-Programming-Explained-Embrace-Change/dp/0321278658) > “最好的模块是深模块。它们通过一个简单的接口暴露大量功能。”> > John Ousterhout，《软件设计的哲学》(https://www.amazon.co.uk/Philosophy-Software-Design-2nd/dp/173210221X) 问题：大多数用 agents 构建的应用都很复杂且难以修改。因为 agents 可以极大地加速编码，它们也加速了软件熵。代码库以空前的速度变得更加复杂。解决方案是一种激进的全新 AI 驱动开发方法：关心代码的设计。这已内置到这些 skills 的每一层中：- /to-spec 在创建 spec 之前先询问你正在触及哪些模块而且至关重要的是，/improve-codebase-architecture 帮助你拯救一个已经变成大泥球的代码库。我建议每隔几天在你的代码库上运行一次。 ### 总结软件工程基本功比以往任何时候都更重要。这些 skills 是我将这些基本功浓缩为可重复实践的最佳尝试，帮助你发布职业生涯中最好的应用。享受吧。 ## 参考这些 skills 按照一个维度划分——谁能调用它们。**用户调用（User-invoked）**的 skills 只有在你输入它们时才能触发（例如 /grill-me）；它们的工作是编排。**模型调用（Model-invoked）**的 skills 可以由你调用，_或者_当任务匹配时由 agent 自动调用；它们承载着可复用的纪律。用户调用的 skill 可以调用模型调用的 skills，但绝不能调用另一个用户调用的 skill。 ### 工程 Skills我每天用于代码工作。用户调用- ask-matt — 询问哪个 skill 或流程适合你的情况。一个针对本仓库中用户调用 skills 的路由器。- grill-with-docs — 盘问环节，同时构建你项目的领域模型，锐化术语并即时更新 CONTEXT.md 和 ADR。- triage — 让工单穿过分流角色的状态机。- improve-codebase-architecture — 扫描代码库寻找深化机会，以可视化的 HTML 报告呈现，然后针对你选择的那一项进行盘问。- setup-matt-pocock-skills — 为本仓库配置工程 skills（问题跟踪器、分流标签、领域文档布局）。在使用其他工程 skills 之前，每个仓库运行一次。- to-spec — 将当前对话转换为 spec 并发布到问题跟踪器。无需访谈——只是综合你们已经讨论过的内容。- to-tickets — 将任何计划、spec 或对话拆解为一组曳光弹（tracer-bullet）工单，每个工单声明其阻塞边界——以本地文件中的文本形式写入，或作为真实跟踪器上的原生阻塞链接。- implement — 构建 spec 或一组工单所描述的工作，在预先约定的接缝处驱动 /tdd，并在提交前以 /code-review 收尾。- wayfinder — 规划一大块工作（超过单个 agent 会话能承载的量），作为问题跟踪器上的一张调查工单共享地图——逐个解决，直到通往目的地的道路清晰为止。模型调用- prototype — 构建一个一次性原型来回答设计问题——对于状态/逻辑问题是一个可运行的终端应用，或者是从一个路由可切换的多个完全不同的 UI 变体。- diagnosing-bugs — 针对疑难 bug 和性能回退的纪律化诊断循环：复现 → 最小化 → 假设 → 插桩 → 修复 → 回归测试。- research — 针对高可信度的一手来源调查一个问题，并将发现以带引用的 Markdown 文件形式保存在仓库中，作为后台 agent 运行。- tdd — 带红-绿-重构循环的测试驱动开发。一次一个垂直切片地构建功能或修复 bug。- domain-modeling — 主动构建和打磨项目的领域模型——对照术语表挑战术语，用边界场景进行压力测试，并即时更新 CONTEXT.md 和 ADR。- codebase-design — 用于设计深模块的共享纪律和词汇：大量行为隐藏在小型接口之后，放在干净的接缝处，可通过该接口进行测试。- code-review — 对自某个固定点以来的 diff 进行双轴审查：标准（Standards）（是否遵循仓库的编码标准，加上 Fowler 坏味道基线？）和 Spec（是否忠实地实现了源头的 issue/PRD？），以并行子 agent 方式运行，避免两者相互污染。- resolving-merge-conflicts — 逐个 hunk 地处理进行中的 git merge 或 rebase 冲突，根据每一边的一手来源追踪意图来解决冲突，然后完成操作——绝不 --abort。 ### 生产力通用工作流工具，不特定于代码。用户调用- grill-me — 被 relentlessly 地盘问一个计划或设计，直到决策树的每个分支都被解决。- handoff — 将当前对话压缩成一份交接文档，以便另一个 agent 可以继续这项工作。- teach — 跨多个会话教用户一项新技能或概念，使用当前目录作为有状态的教学工作区。- writing-great-skills — 关于如何写好和编辑 skills 的参考：使 skill 可预测的词汇和原则。模型调用- grilling — relentlessly 地盘问用户关于一个计划、决策或想法，直到决策树的每个分支都被解决。它是 grill-me 和 grill-with-docs 背后的可复用循环。