@mattpocockuk: 将 Martin Fowler 的《重构》中的一组代码异味添加到我的 /review 技能中：Mysterious Name, Duplicated Code, Fe…

将一组 Martin Fowler 的《重构》中的代码坏味道加入我的 /review 技能：神秘命名、重复代码、依恋情结、数据泥团、基本类型偏执、重复的 switch、霰弹式修改、发散式变化……这些东西对 LLM 来说简直像猫薄荷一样上瘾。https://t.co/g0fpl9x09Q — # mattpocock/skills 来源：https://github.com/mattpocock/skills # 真正的工程师技能 skills.sh (https://skills.sh/mattpocock/skills) 我日常用来进行真正工程开发的 agent 技能——而不是“氛围编码“。开发真正的应用程序很难。像 GSD、BMAD 和 Spec-Kit 这类方法试图通过掌控流程来提供帮助，但这样做却剥夺了你的控制权，并使流程中的 bug 难以解决。这些技能旨在小巧、易于调整且可组合。它们适用于任何模型，基于数十年的工程经验。你可以随意改造它们，让它们成为你自己的。享受吧。如果你想跟进这些技能的更新以及我创建的任何新技能，可以加入约 6 万名开发者订阅我的新闻通讯：订阅通讯 (https://www.aihero.dev/s/skills-newsletter)

快速开始（30 秒设置）

1. 运行 skills.sh 安装程序：bash npx skills@latest add mattpocock/skills
2. 选择你想要的技能，以及你想将它们安装到哪些编码 agent 上。请确保选中 /setup-matt-pocock-skills。
3. 在你的 agent 中运行 /setup-matt-pocock-skills。它会：
   • 询问你想使用哪个问题追踪器（GitHub、Linear 或本地文件）
   • 询问你在分类时应用到工单上的标签（/triage 使用标签）
   • 询问你想将我们创建的任何文档保存到哪里
4. 搞定——可以开始了。

为什么会有这些技能

我构建这些技能是为了解决我在使用 Claude Code、Codex 和其他编码 agent 时常见的故障模式。

#1：Agent 没有做我想做的事

“没有人确切知道他们想要什么”

David Thomas & Andrew Hunt，《程序员修炼之道》(https://www.amazon.co.uk/Pragmatic-Programmer-Anniversary-Journey-Mastery/dp/B0833F1T3V)

问题。软件开发中最常见的故障模式就是“目标错位“。你以为开发者知道你想要什么，然后你看到他们构建的东西——才意识到它根本没理解你。在 AI 时代也是如此。你和 agent 之间存在沟通鸿沟。解决方法是深度盘问会话——让 agent 就你正在构建的内容向你提出详细问题。

解决方法是使用：

• /grill-me —— 用于非代码用途
• /grill-with-docs —— 与 /grill-me 相同，但增加了更多功能（见下文）

这些是我最受欢迎的技能。它们帮助你在开始之前与 agent 对齐，并深入思考你正在进行的变更。每次你想进行变更时都要使用它们。

#2：Agent 过于啰嗦

“有了通用语言，开发人员之间的对话以及代码的表达都来自同一个领域模型。”

Eric Evans，《领域驱动设计》(https://www.amazon.co.uk/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215)

问题：在项目开始时，开发人员和软件的构建对象（领域专家）通常使用不同的语言。我与我的 agent 也感受到了同样的紧张。agent 通常被丢进一个项目，并要求边做边搞清楚行话。结果它们用 20 个词来表达本可以用 1 个词说清的事情。

解决方法是共享语言。这是一份帮助 agent 解码项目中使用的行话的文档。

示例：这是我的 course-video-manager 仓库中的一个 CONTEXT.md (https://github.com/mattpocock/course-video-manager/blob/076a5a7a182db0fe1e62971dd7a68bcadf010f1c/CONTEXT.md) 示例。

哪一段更容易阅读？

• 之前：“当课程中某个部分里的课程被设为’真实’（即在文件系统中给定一个位置）时，会出现一个问题。”
• 之后：“物化级联出现了问题。”

这种简洁会在每一次会话中带来回报。这内置于 /grill-with-docs 中。这是一个盘问会话，但能帮助你与 AI 建立共享语言，并以 ADR 的形式记录难以解释的决策。很难解释这有多么强大。它可能是这个仓库中最酷的技巧。试试看吧。

共享语言除了减少啰嗦之外还有许多其他好处：

• 变量、函数和文件命名一致，使用共享语言
• 因此，代码库更易于 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 技能，你可以将其插入任何项目。它鼓励红绿重构，并为 agent 提供关于什么构成好测试和坏测试的大量指导。

对于调试，我还构建了一个 /diagnosing-bugs 技能，它将最佳调试实践包装成一个简单的循环。

#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)

问题：大多数用 agent 构建的应用都很复杂且难以修改。因为 agent 可以极大地加速编码，它们也加速了软件熵。代码库以前所未有的速度变得复杂。

解决方法是对 AI 驱动的开发采取一种全新的方法：关心代码的设计。这内置于这些技能的每一层：

• /to-prd 在创建 PRD 之前询问你正在接触哪些模块
• 关键是，/improve-codebase-architecture 帮助你拯救一个已经变成泥球的代码库。我建议每隔几天在你的代码库上运行一次。

总结

软件工程基础比以往任何时候都更重要。这些技能是我将这些基础浓缩成可重复实践的最佳努力，帮助你在职业生涯中交付最好的应用程序。享受吧。

参考

这些技能按调用方划分为两个轴。

用户调用的技能只有当你输入它们时才能访问（例如 /grill-me）；它们的作用是编排。 模型调用的技能可以由你调用，或者在任务适合时由 agent 自动引用；它们持有可重复的规范。用户调用的技能可能调用模型调用的技能，但绝不会调用另一个用户调用的技能。

工程技能

我日常用于代码工作。

用户调用

• ask-matt — 询问哪种技能或流程适合你的情况。作为本仓库中用户调用技能的路由器。
• grill-with-docs — 盘问会话，同时建立项目的领域模型，完善术语并内联更新 CONTEXT.md 和 ADR。
• triage — 通过一个状态机移动问题，执行分类角色。
• improve-codebase-architecture — 扫描代码库寻找深化的机会，以可视化的 HTML 报告呈现，然后对你选择的任何一个机会进行盘问。
• setup-matt-pocock-skills — 为工程技能配置此仓库（问题追踪器、分类标签、领域文档布局）。在使用其他工程技能之前，每个仓库运行一次。
• to-issues — 将任何计划、规范或 PRD 通过垂直切片分解成独立可取的工单。
• to-prd — 将当前对话转换为 PRD 并发布到问题追踪器。没有面试——只是综合你已经讨论过的内容。

模型调用

• prototype — 构建一个一次性原型来回答设计问题——一个可运行的终端应用程序用于状态/逻辑问题，或者几个截然不同的 UI 变体，可以从一个路由切换。
• diagnosing-bugs — 针对棘手 bug 和性能回归的有纪律的诊断循环：复现 → 最小化 → 假设 → 检测 → 修复 → 回归测试。
• tdd — 测试驱动开发，采用红绿重构循环。每次构建一个垂直切片来开发功能或修复 bug。
• domain-modeling — 积极构建和完善项目的领域模型——根据词汇表挑战术语，用边缘情况场景进行压力测试，并内联更新 CONTEXT.md 和 ADR。
• codebase-design — 共享的规范和词汇表，用于设计深模块：通过一个小接口暴露大量行为，放置在清晰的接缝处，通过该接口可测试。

生产效率

通用的工作流工具，不是特定于代码的。

用户调用

• grill-me — 就计划或设计接受无休止的面试，直到决策树的每个分支都解决。
• handoff — 将当前对话压缩成一份交接文档，以便另一个 agent 可以继续工作。
• teach — 在多次会话中教授用户一项新技能或概念，使用当前目录作为有状态的教学工作区。
• writing-great-skills — 编写和编辑技能的参考：使技能可预测的词汇和原则。

模型调用

• grilling — 就计划或设计对用户进行无休止的面试，直到决策树的每个分支都解决。grill-me 和 grill-with-docs 背后的可重用循环。

杂项

我保留但很少使用的工具。

• git-guardrails-claude-code — 设置 Claude Code 钩子，在执行之前阻止危险的 git 命令（push, reset –hard, clean 等）。
• migrate-to-shoehorn — 将测试文件从 as 类型断言迁移到 @total-typescript/shoehorn。
• scaffold-exercises — 创建带有章节、问题、解决方案和解释器的练习目录结构。
• setup-pre-commit — 使用 lint-staged、Prettier、类型检查和测试设置 Husky 的 pre-commit 钩子。