强烈推荐 TypeScript 大神 Matt Pocock 的 AI 编程技能！

Superpowers 大概是最早接触的Skill了，后来也介绍过另外一个系列：比 Superpowers 更贴近AI编程工程实践的51 个 Agent 和 35 个技能

今天推荐大神 Matt Pocock 直接从他本机的 .claude 目录倒出来的技能仓库： 50 个技能，累计安装量 610 万次。

README 里的第一句话开宗明义：Skills for Real Engineers。

代表他的核心主张：Agent 是工具，你才是司机。

跟 GSD、BMAD、Spec-Kit 这些试图替你控制流程的方法论不同，Matt 的技能小巧、可适配、可组合、模型无关。

每个 SKILL.md 文件只有几百行，改几行就能适配任何项目。

可以只装 grill-me 加 tdd，也不绑定任何特定模型。

安装只需一行命令：npx skills add mattpocock/skills。

首次运行 /setup-matt-pocock-skills 选择你的问题跟踪器和文档偏好，每个仓库配置一次。

四类AI编程中的问题

AI 编程的问题大概有以下四类。

一、Agent 没按你想的做。

它的解决方案是 grill-me 和 grill-with-docs，在动手之前先穷追不舍地质问你：

这个需求到底想解决什么？有没有更简单的方案？边界条件考虑了吗？有没有你没想到的风险？

二、啰嗦。

解决办法是构建共享语言，通过 CONTEXT.md 定义一套项目专属的领域词汇，让 Agent 的每一次交互都基于这套词汇展开，大幅减少废话。

三、代码不工作。

Agent 生成的代码跑不起来，最关键的问题是缺少反馈循环。

解决方案是 tdd（严格的红-绿-重构）和 diagnosing-bugs（复现、最小化、假设、插桩、修复、回归测试的规范化调试流程）。

四、AI 帮你加速编码，也在加速软件熵增。

解决这个问题的是一组设计导向的技能：to-prd 先写清楚要做什么，improve-codebase-architecture 定期扫描架构腐化点，code-review 双轴审查代码。

常用技能

grill-with-docs，追问引擎加纸面痕迹。

在输入 /grill-with-docs 后，有点类似 /ce-brain-storm 技能 ，先问你关于任务的问题。

一次只问一个问题，每个问题都附带一个推荐答案，等你反馈后才继续。

如果问题的答案能从代码库里找到，它会直接去翻代码，而不是问你。

比如："如果这个 API 在并发场景下被调用 100 次，你期望的行为是什么"。

而且在每个问题得到肯定答复后，写到 CONTEXT.md 词汇表；你和Agent 对话形成的的决策，记录为 ADR。

词汇表只管纯词汇，不存实现细节。

ADR 非常克制，只在决策难以逆转、缺乏上下文会令人惊讶、且经过了实际权衡时才会创建。

大多数会话的结果是更精准的词汇表和零到少量 ADR。

tdd，一条红-绿-重构流水线。

很多 AI 编程方法论都提 TDD，但只是建议一句"你应该写测试"。

Matt 的 tdd 技能则帮助你强制执行测试。

一、不一次性写完所有测试。

tdd 使用的是垂直切片：一次一个行为，先写一个失败测试，用最少代码让它通过，然后下一个。

每个循环都被上一个循环教会了什么，不是凭空猜下一个。

二、第一个循环是一个指明道路"曳光弹"：一条从端到端全部打通的路径，证明整个链路活着，然后从这条路径向外扩展。

三、测试只针对公开接口。

确保了重命名内部函数永远不会破坏测试。

四、预期值必须来自独立的真相来源。

比如规格书里的固定数字、手工计算的结果。

绝不能用和代码相同的逻辑再算一遍，那叫"同义反复测试"，它一定通过，但什么都验证不了。

五、重构只在测试全部变绿后进行，红色期间不动结构。

这条流水线被 implement 技能内部驱动，是整套构建流程里的发动机。

code-review，两个代理同时审，各审各的，互不干扰。

普通代码审查只检查代码风格和潜在 bug，Matt 的多做了一步。

这个技能通过 git diff <起点>...HEAD（三点语法，对比合并基）确定变更范围，然后同时启动两个子代理并行工作。

为什么要并行？

防止两边的上下文互相污染。

检查列表：代码有没有遵守项目的编码规范，是否存在 Fowler 的 12 种经典坏味道（神秘命名、重复代码、依恋情结、数据泥团、基本类型偏执等）。

另一个检查列表：代码是否忠实实现了原始 Issue 或 PRD 中的需求，有没有漏掉的功能，有没有没被要求却偷偷加进去的东西。

两套结论分开汇报，不合并，不交叉打分。

原因很简单：一段代码可以完全符合规范却实现了错的东西（标准过、规格挂），也可以完美兑现需求却违反项目约定（规格过、标准挂）。

这一步是确认Agent写出来的东西真的是我想要的吗？

ask-matt，技能导航器。

面对 50 个技能，新手很难知道从哪个开始。

ask-matt 就是一个路由器：你描述当前的情况和想做的事，它推荐最适合的技能或流程。

本质上就是一个技能体系的交互式索引。

推荐流程

Matt 设计了一条串联起来的推荐流程：

grill-with-docs → to-prd → to-issues → implement → code-review

追问对齐先搞清楚你到底要什么，自动产出 CONTEXT.md 词汇表和 ADR 作为纸面痕迹。

然后基于对齐结果产出一份产品需求文档，再拆成可独立实现的小块任务，编码实施，最后双轴审查代码。

其中 implement 阶段内部驱动 tdd 的红-绿-重构循环，code-review 并行启动两个子代理分别审查标准和规格。

to-issues 的拆分逻辑不是按技术层（前端、后端、数据库）横向切，而是按垂直切片拆，每个 Issue 都是一个从用户可见行为到底层实现的完整功能单元。

一条更轻量的路线：domain-model → to-prd → to-issues → tdd。

如果你只需要快速追问不需要文档产物，可以用 grill-me；如果需要把词汇和决策沉淀到代码库里，用 grill-with-docs。

启发

大神的技能有几个设计值得借鉴。

一、共享词汇表。

CONTEXT.md 项目里所有代理都读同一份词汇定义，比如"问题跟踪器"这个词到底指 GitHub Issues 还是 Linear 还是本地文件，一次定义，全员共识。

而且它是懒加载创建的，第一个术语被澄清之前文件不存在，不需要预先搭架子。

二、技能路由器。

当技能数量超过 10 个时，一个导航型技能能大幅降低认知负担。

用户不需要记住每个技能的名字和用途，描述需求就行。

三、双Agent审查。

内容创作也可以用类似的思路：风格检查是否符合排版规范和去 AI 味的约定，事实检查数据和引用是否准确。

两条线并行跑，比一个人逐行检查效率高得多。

四、技能文档的完整度。

每个技能除了 SKILL.md，还有对应的 docs 页面和 README 索引。

技能一多，光靠文件名根本记不住，必须有一套可检索的文档体系。

有了文档系统可以帮助人来阅读，但是 Agent 怎么用哪个，可以参考这篇文章：装了300个Skill，AI 智能体怎么知道该用哪个？

仓库地址：https://github.com/mattpocock/skills

安装方式：npx skills add mattpocock/skills

你用过mattpocock的技能吗？欢迎评论区留言。