现在 GitHub 上的 Agent Skills 越来越多。
有些 Skill 教 AI 怎么画图、做 PPT、剪视频；有些把一套工具接口包装起来，让 Agent 能直接操作某个服务。
Matt Pocock 的这个 Skills 仓库不太一样。
它不增加某项具体功能，而是试图把需求澄清、领域建模、写规格、拆任务、TDD、调试、代码审查和架构改进这些传统软件工程方法，变成 AI 编程 Agent 可以重复执行的流程。
仓库首页写得很直接：
Skills for Real Engineers. Not vibe coding.
写稿时，这个项目已经获得约 17.8 万个 GitHub Star。稳定目录中包含 17 个工程类 Skill 和 5 个通用效率 Skill，另外还有试验中、已弃用、个人使用和杂项目录。
它解决的不是“AI 不会写代码”
现在的 Codex、Claude Code 已经会写不少代码。真正麻烦的是，代码写得越快，返工、误解和架构腐化也可能发生得越快。
Matt Pocock 总结了几类常见问题：
- 用户自己还没有想清楚，Agent 就开始动手；
- Agent 不理解项目里的领域术语，解释和命名越来越啰嗦；
- 代码能生成，但缺少可靠的测试和反馈循环；
- 功能不断增加，代码库慢慢变成难以修改的“大泥球”；
- 一次任务太大，超过一个 Agent 会话能够稳定处理的范围。
这套 Skills 的核心思路不是让 Agent“更聪明一点”，而是给它一套更稳定的工作纪律。
先别急着写：Grill 系列负责把问题问透
仓库里最有代表性的 Skill 是 /grill-me 和 /grill-with-docs。
/grill-me 会针对一个计划或设计不断追问，直到决策树上的重要分支都得到回答。它不是礼貌地问三四个问题，然后自行补全剩余部分，而是要求把模糊表述、隐含假设和边界条件真正说清楚。
/grill-with-docs 在追问之外，还会结合 /domain-modeling，把讨论中形成的术语和决定写进项目文档。
例如，一个团队把“将课程内容真正写入文件系统”称为“materialization”。如果项目里已经形成这个共同语言，Agent 就不必每次都用二十个词重新解释。变量、函数、文件和文档也更容易使用同一套表达。
这部分会维护两类文档：
CONTEXT.md：记录项目中的领域语言和概念；- ADR：记录重要架构决定以及当时为什么这样选。
它把“和 AI 多聊一会儿”变成了一套有产物的需求澄清过程。
从对话到规格：to-spec
当需求已经讨论清楚，可以使用 /to-spec。
这个 Skill 不会再重新采访用户，而是根据现有对话和代码库，把信息整理成一份规格文档，并发布到项目配置的 Issue Tracker。
规格中会包含：
- 用户遇到的问题；
- 准备提供的解决方案；
- 完整的用户故事；
- 实现层面的关键决定；
- 测试边界和测试策略；
- 明确不做的内容。
它有一个挺实用的要求：规格中尽量不写具体文件路径和代码片段，因为这些细节很容易随着实现变化而过期。规格更关注行为、模块接口和已经确认的决定。
拆成真正能交付的任务：to-tickets
很多 Agent 在拆任务时，喜欢按照技术层级来拆：
- 先改数据库；
- 再写后端；
- 然后写前端；
- 最后补测试。
/to-tickets 反对这种横向拆分，要求使用“Tracer Bullet”式的垂直切片。
每张 Ticket 都要完成一条从数据、接口到用户界面和测试的窄路径。完成以后必须能够独立演示或验证，而且工作量要适合一个全新的 Agent 上下文窗口。
它还会明确 Ticket 之间的阻塞关系。没有依赖的任务进入当前 frontier，可以立即开始；被其他任务阻塞的，则等前置任务完成以后再处理。
这样拆出来的任务，不只是给人看的计划，也是可以直接交给多个 Agent 并行领取的执行图。
真正实现时，使用 implement 和 TDD
/implement 是一个很薄的编排 Skill。
它要求 Agent 按规格或 Ticket 实现功能，在事先确认的测试接缝上调用 /tdd，持续运行类型检查和单个测试，完成后再执行完整测试套件和 /code-review，最后提交代码。
/tdd 则把红—绿循环写得非常严格：
- 先确认要测试的公共接缝；
- 先看到测试失败，再写最少的实现；
- 一次只做一个垂直切片；
- 测试外部行为，不绑定内部实现；
- 预期结果必须来自独立事实，不能用同一套算法重新算一遍；
- 不要一口气写完所有测试，再批量实现。
这套规则不是为了追求测试数量，而是为了给 Agent 建立足够快、足够确定的反馈循环。
遇到 Bug，先制造一个会变红的反馈循环
/diagnosing-bugs 是我觉得这套仓库里写得最扎实的 Skill 之一。
它要求 Agent 在提出原因猜测之前，先找到一条能够稳定捕获用户实际问题的命令。可以是失败测试、curl 脚本、命令行夹具、Playwright、请求重放、差分测试或者自动化二分。
只有当这个循环足够快、可重复，而且能在 Bug 出现时变红，才允许进入下一步。
后续流程是：
- 复现并缩小问题；
- 提出三到五个可以被证伪的假设；
- 针对假设增加调试器或定向日志；
- 先写回归测试，再修复；
- 重新执行原始复现；
- 删除临时日志并完成复盘。
它特意阻止 Agent 一看到报错就修改最可疑的那一行。这种“先修再说”的方式偶尔很快，但也最容易把真正原因藏起来。
Code Review 分成两个互不干扰的方向
/code-review 不把所有问题混在一张“严重程度排行榜”里，而是分成两个轴：
- Standards：代码是否符合仓库规范和基本设计原则；
- Spec：实现是否真正完成了原始 Issue 或规格要求。
两个审查由不同子 Agent 并行完成，避免一个方向的上下文影响另一个方向。
因为代码可能写得很漂亮，却实现错了需求；也可能功能完全正确，却破坏了代码库规范。把两类问题分开报告，比最后只给一个“总体评分”更有用。
代码库已经变成大泥球怎么办
/codebase-design 和 /improve-codebase-architecture 负责架构问题。
它们使用“深模块”“接缝”“局部性”“杠杆率”等概念，寻找那些接口和实现一样复杂、理解一个功能要来回跳十几个文件、很难从公共边界测试的浅模块。
架构扫描后，Agent 会生成一份可视化 HTML 报告。每个候选改造项都会列出涉及文件、当前问题、建议方案、收益、推荐强度，以及改造前后的结构图。
它不会直接开始大规模重构，而是先让用户选择最值得讨论的方向，再通过 grilling 继续确认模块边界和测试接缝。
这种流程比“帮我把代码重构得更优雅”要可控得多。
超大任务交给 Wayfinder
有些任务太大，一个会话根本装不下。例如系统迁移、重新设计权限模型或者规划一条长期产品路线。
/wayfinder 不急着把整个工程拆成施工任务，而是先建立一张“决策地图”。
地图中记录最终目的地、已经作出的决定、当前能够回答的问题，以及暂时还在“战争迷雾”里的内容。每次 Agent 会话只解决一个决策 Ticket，解决后再根据新信息扩展下一层 frontier。
研究类 Ticket 可以并行交给子 Agent；需要人判断的问题则保留 Human-in-the-Loop，不允许 Agent 自己提问、自己回答。
它适合那些连“应该怎样做”都还没有看清的任务，而不是普通的功能开发。
还有一组通用效率 Skills
除了工程流程，仓库还提供几个通用工具：
/handoff：把当前对话整理成可交接文档，让另一个 Agent 继续；/teach：把目录当成长期学习空间，跨会话安排学习任务和记录进度；/writing-great-skills：讲解如何编写更可靠的 Skill；/grilling：为其他 Skill 提供可复用的深度追问循环；/ask-matt：不知道该用哪个流程时，充当 Skill 路由器。
/writing-great-skills 里有一个观点很值得记住：
Skill 的价值，是从随机系统中榨出流程上的可预测性。
它不要求 Agent 每次生成完全相同的答案，而是希望 Agent 每次都遵守同一套可靠步骤。
如何安装
使用 Agent Skills 标准的客户端，可以执行：
npx skills@latest add mattpocock/skills安装时选择需要的 Skill，并确保包含 /setup-matt-pocock-skills。第一次在项目中运行 setup，它会询问：
- 使用 GitHub、Linear 还是本地文件管理 Issue；
- Ticket 使用哪些标签；
- 项目文档保存在哪里。
Claude Code 还可以通过插件市场安装。skills.sh 方式会把文件复制到项目中，适合自行修改；Claude Code 插件则是只读托管版本，会跟随作者更新。
Codex 和其他兼容 Agent Skills 标准的工具，目前主要使用 skills.sh 安装。原生 Codex 插件还在路线图中。
它不是一套自动驾驶开发框架
这套 Skills 很有价值，但也非常有作者个人风格。
它强调 Issue Tracker、领域语言、ADR、测试接缝、垂直切片和频繁的人机确认。如果只是写一个临时脚本，完整走一遍流程可能显得太重。某些 Skill 还依赖子 Agent、浏览器或特定 Issue Tracker 能力，不同 Coding Agent 的实际效果会有差异。
最好的使用方式不是一次性把所有 Skill 都装上，然后期待项目质量自动提高。
可以先从三个开始：
/grill-with-docs：需求还模糊时使用；/diagnosing-bugs：遇到难复现的问题时使用；/code-review：功能完成后检查是否既符合规范，又符合原始需求。
适应以后，再把 /to-spec、/to-tickets、/implement 和 /wayfinder 串成完整流程。
AI 编程让写代码变得越来越快，但软件工程并没有因此消失。相反，需求理解、反馈循环、模块设计和任务拆分，可能比以前更重要。
Matt Pocock 的这套 Skills 做的，就是把这些老派但有效的方法，重新包装成 Agent 能够执行的工作习惯。
