我最喜欢用 AI“编写需求”的方法

1. /grill-me by @mattpocockuk https://github.com/mattpocock/skills…
2. /shaping by @rjs https://github.com/rjs/shaping-skills…

还有一个强有力的竞争者——我基于手头一堆硬核业务分析师文献编写的新技能。旧材料中有一半过于繁琐，但有些好的部分在我们变得马虎/敏捷的过程中被遗忘得差不多了：
https://github.com/gnurio/nurijanian-skills/tree/main/skills/make-requirements-great…

mattpocock/skills

来源：https://github.com/mattpocock/skills

Skills For Real Engineers

skills.sh (https://skills.sh/mattpocock/skills)

我每天都在用的智能体技能——用来做真正的工程，而非“氛围编码”。
开发真实应用是困难的。像 GSD、BMAD 和 Spec-Kit 这类方法试图通过掌控流程来帮忙，但这样做却剥夺了你的控制权，且让流程中的 bug 难以解决。
这些技能设计得小巧、易于调整且可组合。它们适用于任何模型。它们基于数十年工程经验。随便改，变成你自己的。享受吧。

如果你想随时了解这些技能的改动以及我创建的新技能，可以加入约 60,000 名开发者的邮件列表：
注册新闻通讯 (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 或本地文件）
   • 询问你在分类 tick 时使用什么标签（/triage 使用标签）
   • 询问你希望将创建的任何文档保存在哪里
4. 搞定——你可以开始了。

为什么存在这些技能

我构建这些技能是为了修复我在 Claude Code、Codex 及其他编码智能体身上看到的常见故障模式。

#1：智能体没按我的意愿行事

“没人确切知道自己想要什么”
——David Thomas 和 Andrew Hunt，《程序员修炼之道》(https://www.amazon.co.uk/Pragmatic-Programmer-Anniversary-Journey-Mastery/dp/B0833F1T3V)

问题。软件开发中最常见的故障模式是错位。你认为开发者知道你想要什么。然后你看到他们构建的东西——才意识到它根本没理解你。在 AI 时代也是如此。你和智能体之间存在沟通鸿沟。修复方法是进行一次 “拷问 session”——让智能体就你正在构建的内容向你提出详细问题。

解决方案是使用：

• /grill-me —— 用于非代码场景
• /grill-with-docs —— 类似 /grill-me，但增加了更多好东西（见下文）

这些是我最受欢迎的技能。它们帮助你在开始之前与智能体对齐，并深入思考你要做出的改动。每次你想做出改动时都使用它们。

#2：智能体过于啰嗦

使用统一语言，开发人员之间的对话和代码的表达都源自同一个领域模型。
——Eric Evans，《领域驱动设计》(https://www.amazon.co.uk/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215)

问题：在项目开始时，开发人员和为他们构建软件的人（领域专家）通常说不同的语言。我在我的智能体上也感受到了同样的紧张感。智能体通常被直接丢进一个项目，要求它们边干边学行话。结果它们用了 20 个词，其实 1 个就够了。

解决方案是共享语言。这是一份帮助智能体解码项目中行话的文档。
示例 这是来自我的 course-video-manager 仓库的一个 CONTEXT.md 示例 (https://github.com/mattpocock/course-video-manager/blob/076a5a7a182db0fe1e62971dd7a68bcadf010f1c/CONTEXT.md)。哪个更容易阅读？

• 之前：“当课程某一节中的一个课程被设为‘真实’（即在文件系统中分配了一个位置）时，存在一个问题”
• 之后：“存在物化级联问题”

这种简洁性在每次 session 中都见效。这内置于 /grill-with-docs 中。它是一次拷问 session，但同时帮助你与 AI 构建共享语言，并将难以解释的决策记录到 ADR 中。很难解释这有多强大。它可能是这个仓库中最酷的技巧。试试看。

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

• 变量、函数和文件使用共享语言进行一致命名
• 因此，智能体更容易导航代码库
• 智能体在思考上消耗更少的 token，因为它能使用更简洁的语言

#3：代码不工作

“始终采取小而谨慎的步骤。反馈速度是你的极限。永远不要接手太大的任务。”
——David Thomas 和 Andrew Hunt，《程序员修炼之道》(https://www.amazon.co.uk/Pragmatic-Programmer-Anniversary-Journey-Mastery/dp/B0833F1T3V)

问题：假设你和智能体就构建什么达成一致。当智能体仍然产生糟糕代码时该怎么办？是时候审视你的反馈循环了。如果没有关于代码实际运行情况的反馈，智能体将盲目飞行。

解决方案：你需要通常的反馈循环：静态类型、浏览器访问和自动化测试。对于自动化测试，红-绿-重构循环至关重要。这就是智能体先编写失败的测试，然后修复测试。这有助于给智能体提供一致的反馈水平，从而产生更好的代码。我构建了一个 /tdd 技能，可以插入任何项目。它鼓励红-绿-重构，并为智能体提供关于什么是好测试和坏测试的大量指导。
对于调试，我还构建了一个 /diagnose 技能，将最佳调试实践包装成一个简单循环。

#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-prd 在创建 PRD 之前询问你正在触及哪些模块
• /zoom-out 告诉智能体在整体系统上下文中解释代码

而且至关重要的是，/improve-codebase-architecture 帮助你拯救一个已经变成泥球的代码库。我建议每隔几天在代码库上运行一次。

总结

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

参考

工程技能

我日常用于代码工作。

• diagnose——针对硬 bug 和性能回归的有纪律的诊断循环：重现→最小化→假设→检测→修复→回归测试。
• grill-with-docs——拷问 session，针对现有领域模型挑战你的计划，打磨术语，并内联更新 CONTEXT.md 和 ADR。
• 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 Issue，使用垂直切片。
• to-prd——将当前对话上下文转换为 PRD 并作为 GitHub Issue 提交。无面试——仅合成你已经讨论过的内容。
• zoom-out——告诉智能体缩放视角，对不熟悉的代码部分提供更广泛的上下文或更高层次的视角。
• prototype——构建一个一次性原型来完善设计——要么是一个用于状态/业务逻辑问题的可运行终端应用，要么是几种完全不同的 UI 变体，可通过一条路由切换。

生产力

通用工作流工具，非代码专用。

• caveman——超压缩沟通模式。通过去掉填充词将 token 使用量减少约 75%，同时保持完整的技术准确性。
• 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——使用 lint-staged、Prettier、类型检查和测试设置 Husky pre-commit 钩子。