项目简介
这是用来做真正工程工作的 Agent Skills——不是 vibe coding。
不断用vibe coding的一定知道，开发真正的应用很难。GSD、BMAD、Spec-Kit 这类方法试图通过接管整个流程来帮忙，但这样做会夺走你的控制权，并且让流程中的问题变得难以解决。
这些技能被设计成小巧、易于适配、可组合。它们适用于任何模型，基于数十年的工程经验。可以随意改造它们，把它们变成你自己的。
安装（30 秒搞定）
插件会自动更新。skills.sh 会把可编辑的文件复制到你的项目里，你需要手动更新。每个 Agent 只选一种安装方式，因为同时安装两种会导致每个技能出现两份。
1. 获取技能
Claude Code
claude plugin install mattpocock-skills@claude-plugins-official
默认自动更新。
Codex
codex plugin marketplace add mattpocock/skills
codex plugin add mattpocock-skills@mattpocock
启动时自动更新。GitHub Copilot（CLI 和 VS Code）
copilot plugin marketplace add mattpocock/skills
copilot plugin install mattpocock-skills@mattpocock
然后一次性添加到 ~/.copilot/settings.json：
{
"extraKnownMarketplaces":{
"mattpocock":{
"source":{
"source":"github",
"repo":"mattpocock/skills"
},
"autoUpdate":true
}
}
}
在 VS Code 中，运行 Chat: Install Plugin From Source，输入 https://github.com/mattpocock/skills。它会每天更新。
Gemini CLI（手动更新）
gemini skills install https://github.com/mattpocock/skills.git --path skills/engineering
gemini skills install https://github.com/mattpocock/skills.git --path skills/productivity
重新运行这两条命令即可更新。
其他 Agent，或需要可编辑文件（手动更新）
npx skills@latest add mattpocock/skills -a <agent> # cursor, opencode, devin, windsurf, amp, pi; 省略 -a 则交互选择
安装程序询问要安装哪些技能时，务必包含 setup-matt-pocock-skills。更新时运行 npx skills@latest update，并重新运行 add 来获取新技能。
2. 运行 /setup-matt-pocock-skills
在你的 Agent 中，每个仓库运行一次。它会：
询问你想使用哪个 Issue Tracker（GitHub、GitLab、本地文件，或其他你描述的系统） 询问你在 triage（分类）工单时使用的标签（ /triage会使用这些标签）询问你希望把我们创建的文档保存到哪里
为什么会有这些技能
构建这些技能，是为了修复我在 Claude Code、Codex 和其他编码 Agent 上常见的失败模式。
#1：Agent 没有按我的意思做
“没有人确切知道自己想要什么”
David Thomas & Andrew Hunt，《The Pragmatic Programmer》
问题。软件开发中最常见的失败模式是错位（misalignment）。你以为开发者知道你想要什么，结果看到他们做出来的东西——你才发现它完全没理解你。
AI 时代也是一样。你和 Agent 之间存在沟通鸿沟。解决方法是进行一次 grilling session（拷问会话）——让 Agent 详细询问你正在构建的内容。
解决方法是使用：
/grill-me—— 用于非代码场景/grill-with-docs—— 与/grill-me相同，但增加了更多内容（见下文）
这些是我最受欢迎的技能。它们帮助你在开始之前与 Agent 对齐，并深入思考你正在做的改动。每次想做改动时都使用它们。
#2：Agent 太啰嗦了
有了统一语言（ubiquitous language），开发者之间的对话以及代码中的表达都来自同一个领域模型。
Eric Evans，《Domain-Driven Design》
问题：项目初期，开发者和软件的使用者（领域专家）通常说着不同的语言。
我和我的 Agent 也有同样的张力。Agent 通常被丢进一个项目，然后被要求边做边搞清楚术语。所以它们用 20 个词才能表达 1 个词能说清楚的意思。
解决方法是建立共享语言。这是一份帮助 Agent 解码项目中术语的文档。
示例这是一个来自我的 course-video-manager 仓库的术语表示例（在那个固定 commit 时还叫 CONTEXT.md，后来技能把约定改名了）。哪个更容易读？
之前：“当课程某个 section 里的 lesson 被‘真实化’时有问题（即被赋予了文件系统中的位置）” 之后：“materialization cascade 有问题”
这种简洁在一次又一次会话中都会带来收益。
这被内置在 /grill-with-docs 中。它是一次 grilling 会话，但会帮助你与 AI 建立共享语言，并把难以解释的决策记录在 ADR 中。
很难用语言形容它有多强大。这可能是这个仓库里最酷的技术。试试看。
[!TIP] 共享语言除了减少啰嗦之外，还有很多其他好处：
变量、函数和文件命名保持一致，使用共享语言 结果是，代码库对 Agent 更容易导航 Agent 也花费更少的 token 在思考上，因为它拥有更简洁的语言
#3：代码不能工作
“总是采取小而谨慎的步骤。反馈速率就是你的速度上限。永远不要承担太大的任务。”
David Thomas & Andrew Hunt，《The Pragmatic Programmer》
问题：假设你和 Agent 已经对齐了要构建什么。当 Agent 仍然产出垃圾时怎么办？
是时候看看你的反馈循环了。没有关于它产出的代码实际如何运行的反馈，Agent 就是在盲目飞行。
解决方法：你需要通常的那一套反馈循环：静态类型、浏览器访问、以及自动化测试。
对于自动化测试，红-绿-重构（red-green-refactor）循环至关重要。这是指 Agent 先写一个失败的测试，然后修复测试。这能给 Agent 提供一致的反馈水平，从而产生更好的代码。
我构建了一个 /tdd 技能，可以插入任何项目。它鼓励红-绿-重构，并给 Agent 大量关于什么是好测试、什么是坏测试的指导。
对于调试，我还构建了一个 /diagnosing-bugs 技能，它把最佳调试实践包装成一个有纪律的循环，按阶段把关。
#4：我们建成了一坨泥巴（Ball of Mud）
“每天都投资于系统的设计。”
Kent Beck，《Extreme Programming Explained》
“最好的模块是深的。它们允许通过简单接口访问大量功能。”
John Ousterhout，《A Philosophy of Software Design》
问题：大多数用 Agent 构建的应用都很复杂且难以变更。因为 Agent 能极大加速编码，它们也加速了软件熵。代码库以空前的速度变得更复杂。
解决方法是对 AI 驱动开发采取一种全新的激进方法：关心代码的设计。
这被内置到这些技能的每一层：
/to-spec在创建规范之前会询问你正在触及哪些模块
更关键的是，/improve-codebase-architecture 会扫描代码库寻找“加深”（deepening）机会，并把候选方案交给你。我建议每几天在你的代码库上运行一次。它是一次调查，不是救援：在真正老旧的代码库上它会找到真实的候选，但不会替你解开泥巴。
项目地址
https://github.com/mattpocock/skills