Matt Pocock Skills 都是干什么的？怎么调用？
我第一次打开 Matt Pocock 的 Skills 仓库时，看到一大堆 grill-with-docs、wayfinder、to-spec、handoff，也是一头雾水。名字能看懂一半，真到自己的项目里，还是不知道该先用哪个。
我花了不少时间把这些 Skill 过了一遍，后来发现它们就像一套开发工具箱。有的专门帮你把需求问清楚，有的负责拆任务，还有的管测试、排查 Bug 和代码评审。遇到什么问题，就拿对应的工具出来用，没必要每次把整套流程都跑一遍。
这篇我先带小伙伴看看每个 Skill 到底是干什么的，后面再给出几组我自己会用的调用方式和现成提示词。
官方仓库地址：mattpocock/skills。
这套 Skills 能帮我们解决哪些问题
我在项目里用 AI 写代码，最怕的几件事是：需求还没聊明白，它已经哐哩啪啦改了一堆文件；遇到 Bug 就开始猜，这里试一下，那里加个判断；项目做到一半换了会话，之前定下来的东西又要重新讲。
Matt Pocock 这套 Skills 主要在处理下面四类问题：
- 先把需求问清楚，把容易漏掉的情况、业务规则和未决定的问题找出来。
- 把重要结论写进项目，比如共同语言、ADR、规格、任务依赖和交接记录。
- 让 Agent 能看到对错。测试失败了就继续改，复现不了 Bug 就先别急着下结论。
- 在写代码的同时管住复杂度，尽量让模块职责清楚，接口好用，测试也能跟得上。
安装完以后，AI 会自己调用吗
要看 Skill 属于哪一类。官方把它们分成了两种，我按照日常使用习惯翻译一下。
| 类型 | 怎么启动 | 我是怎么理解的 |
|---|---|---|
| 需要主动调用 | 你得把 Skill 名写出来 | 这类 Skill 会带着 Agent 走完一段流程，比如追问需求、整理规格、规划大项目。Claude Code 一般写 /skill-name，Codex 一般写 $skill-name。 |
| AI 可以按需调用 | AI 觉得任务匹配时可能会自己用，你也可以主动使用 | 这类 Skill 更像一种做事方法，比如 TDD、调研、领域建模和代码评审。我如果很在意这次必须按某种方式做，还是会主动写出 Skill 名。 |
举个例子，grill-with-docs 在追问需求时，会用到 grilling 和 domain-modeling。implement 开始写代码后，会把 tdd 和 code-review 串起来。小伙伴只需要选好入口，内部的工作可以交给 Skill 去组织。
正式发布的 25 个 Skill
我按官方 v1.2.3 Release 里的 README 核对了一遍，到 2026 年 8 月 27 日为止，里面正式列出了 25 个 Skill。下面只讲这 25 个。main 分支里还在开发的内容、.out-of-scope 目录以及作者自己用的 Skill，我都没有放进来。
工程类：需要主动调用
这一组基本都是入口型 Skill。你想让 AI 开始追问、整理规格或者做大型项目规划，需要自己点名。
| Skill | 它能帮你做什么 | 我一般会在什么时候用 |
|---|---|---|
ask-matt | 不知道该用哪个 Skill 时，可以先问它。它会根据你手头的任务推荐入口或者组合流程。 | 刚安装完这套 Skills，还记不住这些名字的时候。熟悉以后可以不装。 |
grill-with-docs | AI 会围着一个功能连续问你问题，把边界、异常情况和业务规则聊清楚。聊过程中碰到的共同语言和架构决定，还会更新到 CONTEXT.md 和 ADR 里。 | 我准备开发新功能、改旧功能，或者自己也没把需求想透时，会先用它聊一轮。 |
triage | 它会按项目里配好的角色、标签和状态处理 Issue，帮团队统一任务怎么分类、怎么往下流转。 | 项目已经在用 GitHub、Linear 或本地 Issue 文件，而且大家经常搞不清一张票现在该归谁、该放什么状态时。 |
improve-codebase-architecture | 它会先扫一遍代码库，找出那些模块太碎、接口太大、职责散得太开的地方，再生成一份 HTML 报告。你从中选一个候选项，它再跟你继续聊怎么调整。 | 我会把它当代码库体检用。跑一次可以找到值得改的地方，但它不会一次性帮你收拾完所有历史问题。 |
setup-matt-pocock-skills | 第一次在项目里用这套 Skills 时，它会询问你用什么 Issue Tracker、任务标签怎么设，领域文档放在哪里。 | 每个项目开头跑一次就够了。它可能会改 AGENTS.md、CLAUDE.md 和文档目录，运行前我会先看清它准备写哪些文件。 |
to-spec | 它把已经聊清楚的内容整理成一份正式规格，包括要做的行为、技术决定、测试方式和这次明确不做的内容。 | 需求和关键决定都定下来以后，我会用它把聊天结论变成可实现、可评审的文档。 |
to-tickets | 一份规格太大时，它会拆成多张可以单独完成和验收的任务票。每张票都会写清楚要交付什么，还有它被哪些前置任务卡着。 | 大功能需要分好几个会话做，或者准备让多个 Agent 分工时，先用它把顺序和依赖理清楚。 |
implement | 它会拿着已经确认的规格或任务票开始实现，中间调用 tdd，完成后调用 code-review，最后创建 Git 提交。 | 任务已经审批，而且你愿意让 Agent 改代码、跑测试和提交时再用。我如果不希望它自动 commit，会直接换成 $tdd 加 $code-review。 |
wayfinder | 超大项目一次聊不完，它会先做一张“决策地图”，把还没想清楚的问题和它们之间的依赖画出来，后面一次解决一张决策票。 | 从 0 到 1 做大项目、跨模块重构、长周期迁移，这些任务一开始往往有太多事情还没定，这时候用它比较合适。 |
工程类：AI 可以按需调用
这一组管的都是具体做法。AI 有可能根据任务自己用，可我如果明确要求“这次一定要先写失败测试”，就会直接写 $tdd，不跟概率较劲。
| Skill | 它能帮你做什么 | 我一般会在什么时候用 |
|---|---|---|
prototype | 它会快速做一个用完就可以丢掉的原型。如果要验证状态和逻辑，可以产出一个 HTML；如果是 UI 方向，可以在一个页面上切换几种差异大一点的方案。 | 交互、状态流转或界面方向还没定，我想先花小成本看看哪个思路靠谱时。 |
diagnosing-bugs | 它会先想办法稳定复现问题，然后缩小范围、提出假设、加观测、定位原因，修好以后再补上回归测试。 | 遇到偶发 Bug、性能突然变差，或者日志看了一堆仍然没头绪时。 |
research | 它会围绕一个具体问题去找可靠的一手资料，把结论、证据和来源整理成 Markdown 文档。 | 要查 API 到底怎么用、某个框架支不支持一项能力，或者做技术选型需要留下出处时。 |
tdd | 按照“先写失败测试、再做最小实现、最后整理代码”的节奏开发，一次只往前推一小块完整功能。 | 方案已经确认，准备写功能或修 Bug，而且希望每次修改都能马上从测试里得到反馈时。 |
domain-modeling | 它会检查项目里的业务词语是不是说的同一回事，再用边界场景去试这些定义经不经得住。发现问题后，它会同步更新 CONTEXT.md 和 ADR。 | 业务和开发各说各的，或者代码里同一个概念出现了几种名字时。 |
codebase-design | 它关注模块怎么分、接口怎么开、复杂逻辑该藏在哪里，还会看模块之间有没有好测试的分界点（seam）。 | 新设计一个模块、调整接口职责，或者现有代码牵一发动全身时。 |
code-review | 它会分两条线审查代码。一条看代码规范和代码异味，另一条对照原始 Issue 或规格，看这次实现有没有跑偏。 | 功能写完以后，我想同时查“代码质量怎么样”和“需求到底实现对了没有”时。 |
resolving-merge-conflicts | 仓库已经出现 merge 或 rebase 冲突时，它会一块一块查两边的原始意图，根据业务需要保留正确的内容，然后完成当前 Git 操作。 | 两个分支碰巧改了同一段业务逻辑，你没法简单地选 ours 或 theirs 时。 |
wizard | 有些步骤必须由人来做，比如登录后台、创建密钥、填 CI Secret 或做一次性迁移。它会生成一个交互式 Bash 向导，带你一步步做完。 | 任务碰到登录态、密钥、审批权限或陌生的第三方控制台时。 |
效率类：需要主动调用
这几个 Skill 不一定和写代码有关。讨论一个想法、学一门新技术、给同事发问卷，都能用得上。
| Skill | 它能帮你做什么 | 我一般会在什么时候用 |
|---|---|---|
grill-me | 你给出一个想法或计划，它会一直追问，直到重要分支都聊清楚。它不会帮你维护仓库里的 CONTEXT.md 和 ADR。 | 聊产品想法、写作计划或非代码设计时。如果是仓库内的功能设计，我会换成 grill-with-docs。 |
handoff | 对话很长时，它会把已经确认的结论、做到哪了、相关文件、还有哪些问题和下一步整理成交接文档。 | 准备换会话、换 Agent、换工作目录，或者当前上下文已经太长时。 |
teach | 它会把当前目录当成学习空间，把一门技术拆成多次会话来讲，学到哪里也会保存下来。 | 想系统学习某项技术，一次对话讲不完，后面还要接着练时。 |
to-questionnaire | 有个决定必须找产品、客户、法务或领域专家确认，它会帮你整理成一份 Markdown 问卷。对方可以异步填，也可以开会时一起填。 | 关键答案在别人手里，我想一次把背景和问题讲明白，少来回几轮沟通时。 |
wait-what | 看不懂 Agent 刚才的解释，就可以马上用它。它会结合项目 CONTEXT.md 里的词汇补齐背景，然后换一种更容易听懂的说法。 | Agent 一段话说得太绕，或者它默认你已经知道某些业务背景时。 |
效率类：AI 可以按需调用
这一组只有两个，平时多数由其他 Skill 带起来。
| Skill | 它能帮你做什么 | 我一般会在什么时候用 |
|---|---|---|
grilling | 它就是“连续追问”这项能力。grill-me、grill-with-docs、triage 和 wayfinder 都会在内部用它，把模糊的说法一点点问具体。 | 我平时很少单独调它，直接从上面几个入口 Skill 开始就行。 |
writing-for-agents | 它专门管写给 Agent 看的文档，比如 Skill、AGENTS.md、CLAUDE.md 和按需加载的规则文件。它会检查规则好不好找、能不能执行、有没有重复。 | 要新写 Skill，或者项目里的 Agent 规则已经散得到处都是时。 |
几组常用的搭配
这 25 个 Skill 没有必要全装，更不用每次全调。我一般先看任务有多大、还有多少事没想清楚，再选一组够用的。
| 任务 | 我会怎么搭配 | 为什么这样用 |
|---|---|---|
| 一个范围比较清楚的小功能 | grill-with-docs → tdd → code-review | 先聊一轮把边界对齐，然后写测试、做实现，最后对照需求检查一遍。 |
| 需要留下正式记录的中型功能 | grill-with-docs → to-spec → tdd → code-review | 聊完后多一步 to-spec，后面换人或回头查起来都更方便。 |
| 要跨好几个会话的大项目 | wayfinder → to-spec → to-tickets → implement | 先一张票一张票解决未知问题，等路线清楚了，再定规格、拆实现任务。 |
| 很难复现的 Bug 或性能问题 | diagnosing-bugs → tdd → code-review | 将问题用证据把原因找出来，修好后再留一个回归测试。 |
| 任务没做完，但要换会话 | handoff | 它会把当前进度和下一步整理好，新会话可以接着往下做。 |
这里最容易混的是 wayfinder、to-tickets 和 handoff。我的记法很简单：
wayfinder管的是还没想清楚的问题，它画出决策地图。to-tickets管的是已经想清楚的事该按什么顺序做，它拆出实现任务。handoff管的是这次聊到了哪里，方便下一个 Agent 接着做。
我自己是怎么用的
下面以我实际配置过的项目为例。当时我一共安装了 17 个 Skill，其中 16 个来自 Matt Pocock Skills，另外还装了一个独立的 shadcn Skill。implement 我没有装，因为它会管到 Git 提交，我更喜欢自己确认后再提交。实现阶段我用 $tdd，做完再跑 code-review。
如果小伙伴也想保留这种控制感，可以先记住四件事：
- 新功能或者修改旧功能，先用
$grill-with-docs把需求聊清楚。 - 方案确认后，再用
$tdd开始写测试和代码。 - 碰到难查的问题就用
$diagnosing-bugs，准备换会话就用$handoff。 - 对这次工作特别重要的 Skill，我会直接点名，不等 AI 自己去猜。
可以直接复制的提示词
新项目或新功能，先聊清楚再动代码
$grill-with-docs
我要做……。
请先读取现有项目，跟我确认目标、范围、关键流程、模块边界、风险和测试方式。
这一轮先不要修改文件，也不要提交 Git 或调用外部系统，等我确认方案后再继续。
如果项目很大，现在连整体路线都没有定下来，我会换成 wayfinder：
$wayfinder
我要从 0 到 1 做……。
请先帮我建立决策地图，把目标、还没想清楚的问题、依赖关系和决策顺序列出来。
现在先不写功能代码，也不要创建外部 Issue。如果要把记录写进项目，先跟我确认文件位置。
修改现有项目，先看会影响哪些地方
$grill-with-docs
我需要把……改成……。
请先根据源码告诉我：现在的行为是什么，会影响哪些模块和数据，有哪些兼容风险，测试可以从哪里切入，以及怎么验收。
先给我方案，等我确认后再改代码。
这次修改要是还涉及模块职责或接口设计，我会再单独发：
$codebase-design
请根据上面的方案，比较几种可行的模块划分和接口设计。
把每种方案的测试切入点、局部修改难度和后续维护影响讲清楚。
这一轮只出设计结论，不要改代码。
决定已经聊清楚，整理规格和任务
我会先用 to-spec 把已经确认的内容定下来：
$to-spec
请把当前已经确认的讨论整理成正式规格。
里面要包含要解决的问题、用户能看到的行为、实现决定、测试方式和这次不做的内容。
先告诉我你准备写到哪里，不要修改业务代码，也不要提交 Git。
规格比较大，需要分好几步做，再用 to-tickets：
$to-tickets
请把已经确认的规格拆成多张可以单独交付的任务票。
每张票都要写清楚完成后用户能看到什么、怎么验收，以及 Blocked by 依赖关系。
先把任务粒度和依赖给我确认，不要直接发布外部 Issue，也不要改业务代码。
方案确认了，用测试带着往下做
$tdd
上面的方案已经确认，现在可以修改代码实现……。
请先针对用户能看到的行为写一个失败测试，然后做最小实现，只改本次方案涉及的文件。
不要自动提交 Git。做完后把改了哪些文件、跑了哪些测试、还有什么风险告诉我。
代码做完以后，我会再单独跑一次评审：
$code-review main
请审查从 main 到当前 HEAD 的改动。
分别检查这些代码有没有违反项目规范，以及有没有漏掉或曲解已确认的方案。
这一轮只报告问题，不要修改代码。
碰到难查的 Bug，先复现再修
$diagnosing-bugs
请排查……。
第一阶段先读日志、配置、调用链和现有测试，告诉我怎么稳定复现这个问题。
在我明确确认前，不要改代码、加临时埋点、访问生产环境或执行外部操作。
等复现方法和调查边界都确认后，再让它继续补回归测试和修复。
查官方文档或外部事实
$research
请调研……。
优先看官方文档、源码和第一方 API，每个结论都要带上对应来源。
先告诉我调研结果准备写到哪个文件。如果我只想在聊天中看，就不要改仓库文件。
换会话前留一份交接
$handoff
下一个会话要继续处理……。
请整理已经确认的结论、当前进度、还没解决的问题、相关文件或 Issue，以及下一步建议调用哪个 Skill。
已经有规格、ADR 和日志的内容只给出位置，不要整段复制，敏感信息也要脱敏。
需要自己登录后台或填密钥
$wizard
请为……生成一份人工操作向导。
先列出所有步骤、需要我提供的值、这些值会写到哪里，还有哪些操作无法撤销。
等我确认后再生成脚本，不要自行打开后台、写入密钥、修改 `.env` 或 GitHub Secret。
给项目加上授权边界
有些 Skill 会写文档、创建 Issue，implement 还会修代码和提交 Git。如果你也习惯先看方案，然后自己决定要不要继续，可以在项目 AGENTS.md 里加上下面这段：
## 协作授权边界
任务涉及代码、配置、文档、Issue、密钥、Git 提交、发布或外部系统写操作时，
先完成只读调查并给出方案。等用户明确确认后，再开始修改。
用户还没授权时，只可以读取、分析、提供选项和说明风险。
不得创建或修改文件、执行 Git commit/push、创建外部 Issue、写入密钥或访问生产环境。
项目里如果已经有 AGENTS.md 或 CLAUDE.md，先看一下现有规则，不要把相同的内容写重复了。也可以用 $writing-for-agents 帮忙合并，再根据自己项目的目录和测试命令做调整。
实在记不住，就看这张表
新功能还没聊清楚 → $grill-with-docs
项目很大，整体路线也没定 → $wayfinder
要查官方文档和外部资料 → $research
业务词语和领域边界有点乱 → $domain-modeling
讨论结果已经确认 → $to-spec
一份规格需要拆成多张任务 → $to-tickets
方案确认了，准备写代码 → $tdd
碰到难复现的 Bug 或性能问题 → $diagnosing-bugs
前端要用 shadcn/ui → $shadcn
准备换会话或换 Agent → $handoff
有些后台操作只能由人完成 → $wizard
要改 Skill、AGENTS.md 或 CLAUDE.md → $writing-for-agents
我不建议在同一条提示词里一口气启动好几个入口型 Skill。普通功能从 $grill-with-docs 开始，超大且路线还很模糊的项目用 $wayfinder，不涉及代码仓库的想法可以用 $grill-me。选一个入口就够了，里面需要的其他 Skill 会再按流程带起来。