前面五个框架都想接管从需求到代码的完整流程。Matt Pocock 的 Skills 反过来：每个 Skill 只管一小段，流程由你自己用斜杠命令串起来。
Spec-Kit 这类接管流程的框架，接管的同时也拿走了你的控制权；流程本身出了问题，也很难修。Matt Pocock 由此定的方向是：Skill 要小、好改、能组合。
Matt Pocock 是 TypeScript 圈很有名的讲师（Total TypeScript 的作者），现在在 AI Hero 讲 AI 编程。仓库 2026 年 2 月建立，GitHub 上将近 30 万 Star，MIT 许可。这些 Skill 是他每天工作里在用的。
他不反对 AI 写代码，反对的是让 AI 不管代码质量一路写下去。
作者认为 Agent 写代码最容易犯四类问题，每一类他都对上了一本书，也各配了 Skill：
| 问题 | 他引用的书 | 对应的 Skill |
|---|---|---|
| Agent 做的不是你想要的 | 《程序员修炼之道》：没人确切知道自己想要什么 | /grill-me、/grill-with-docs |
| Agent 太啰嗦 | 《领域驱动设计》：统一语言 | /grill-with-docs 顺手建的 GLOSSARY.md |
| 代码跑不通 | 《程序员修炼之道》：反馈的速度就是你的速度上限 | /tdd、/diagnosing-bugs |
| 越写越乱，成了一团泥 | 《解析极限编程》《软件设计的哲学》 | /improve-codebase-architecture |
一、安装
Claude Code 里，它已经上架官方插件市场。在终端运行：
claude plugin install mattpocock-skills@claude-plugins-official想要一份能直接改的副本，用 skills.sh：
npx skills@latest add mattpocock/skills它把 Skill 文件复制进你的项目，你想怎么改都行，代价是更新要自己来（npx skills@latest update）。安装时它会问装哪些 Skill，把 setup-matt-pocock-skills 选上。
README 提醒：两种方式只选一种。都装的话，每个 Skill 会出现两遍。
Codex、Copilot、Gemini CLI，以及 Cursor、OpenCode 等工具也都支持，命令见 README。
💡 社区有一个第三方维护的简体中文版
vinvcn/mattpocock-skills-zh-CN，只翻译说明文字，Skill 名和命令不变，写作时同步到了 1.3.1。它不是官方仓库，同步会有滞后；和原版二选一就好，别两个都装。
装好之后：每个仓库跑一次 setup
/setup-matt-pocock-skills它先看一眼你的仓库：有没有 git remote、有没有 CLAUDE.md、有没有 GLOSSARY.md、是不是 monorepo。然后一节一节地问，每节都先给推荐答案，你回一个字就能接受：
| 问什么 | 选项 | 写到哪 |
|---|---|---|
| Issue tracker：spec 和任务放在哪 | GitHub（默认）、GitLab、本地 Markdown、其他（你用一段话描述） | docs/agents/issue-tracker.md |
| Triage 标签 | 默认五个：needs-triage、needs-info、ready-for-agent、ready-for-human、wontfix |
docs/agents/triage-labels.md |
| 领域文档放哪 | 默认根目录一个 GLOSSARY.md 加 docs/adr/；monorepo 才会问要不要分多个 |
docs/agents/domain.md |
最后它在 CLAUDE.md（没有就 AGENTS.md，两个都没有就问你建哪个）里加一段 ## Agent skills，每项只有一行，指向上面这几个文件。
本地 Markdown 的约定，就写在 setup 自带的模板里：
二、Matt Pocock Skill 设计
Matt Pocock 一共有 27 个 Skill，只按一个维度分成两类：谁能调用它。
| 只能你调用（user-invoked） | 模型也能调用（model-invoked） | |
|---|---|---|
| 怎么标 | frontmatter 里写 disable-model-invocation: true |
不写 |
| 数量 | 16 个 | 11 个 |
| 负责 | 编排：串流程，决定下一步做什么 | 纪律：一件事怎么做才对 |
| 例子 | /grill-with-docs、/to-spec、/to-tickets、/implement、/retro |
grilling、domain-modeling、tdd、code-review、diagnosing-bugs |
仓库里数出来是这样：
组合
最常用的两个命令，正文几乎只有一句调用：
/grill-me：调用grilling/grill-with-docs：调用grilling和domain-modeling两个
提问方法写在 grilling 里，维护词汇表的方法写在 domain-modeling 里，两个命令只是入口。
grilling 还被 /triage、/wayfinder、/improve-codebase-architecture 拿去用。提问的方法只写一次，哪里需要就调用哪里。
💡 写 Skill 时可以借鉴一个细节：调用别的 Skill，统一写成
Call the Skill tool with "grilling"，不在正文里随手写一句/grilling。更新日志里讲了原因：只在文字里提一句
/xxx，模型不一定真去加载；直接点名 Skill 工具，命中率更高。而且不带/，换到别的 Agent 工具里也通用。
三、/ask-matt 介绍
Skill 多到记不住用哪个，先问 /ask-matt。它按当前情境给出该用哪个 Skill、走哪条流程，相当于所有 Skill 的路由器。
四、精读 grilling：一轮问完一整层
Matt Pocock 说，grill 是他最受欢迎的 Skill，每次要改东西都该用。
1. 设计树和前沿
grilling 把要讨论的事看成一棵设计树：每个决定下面，挂着依赖它的那些决定。
每一轮只问树上的前沿（frontier）：前提都已经定下来的那些决定，现在就能问，不用猜答案。
- 一轮把整个前沿问完，每个问题编号，并给出它的推荐答案
- 然后等你回答
- 你的回答定下了一些决定，前沿往外推，再算下一轮
- 一个问题如果依赖本轮另一个还没答的问题，就留到下一轮
拿订单导出举例，第一轮大概是这样（示意）：
❓ **Q1** - **超过上限怎么办**：筛选结果超过 10 万行时，直接拒绝导出，
并提示用户缩小范围，行吗？另一种做法是只导出前 10 万行。
➡️ 行。截断的文件看起来是完整的，运营很容易拿它对错账。
---
❓ **Q2** - **谁能导出**：导出权限直接沿用订单列表的查看权限，行吗？
➡️ 行，不新增权限点。