@mattpocockuk: 重新措辞 /grill-me，使其现在真正可以在任何地方使用——不仅仅是工程领域。"设计树" -> "决策树" "每…

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