Matt Pocock Skills 流程/用法盘点
Matt Pocock Skills
Agent Skills · 参考手册
38 个可拆装的 agent skill，四个桶，一条从想法到上线的主流程。这份文档讲清它的开发哲学、常用技能、协作机制和落地场景。
38 skills · 4 buckets · 快照 2026-10-09 · 49dd158 · 仓库 mattpocock/skills
这套东西的自我定位是「真实工程，不是氛围编程」。它刻意不去拥有你的流程——不像 GSD、BMAD、Spec-Kit 那样把整条流水线接管过去，那样做的代价是你失去控制权，而且流程本身出 bug 时很难修。它给你的是一组小、好改、可组合的工具，作者的原话是「拿它们开刀，变成你自己的」。
01 他遵循什么开发流程
作者是从四个反复出现的失败模式倒推出这套流程的。每一个模式对应一句软件工程的经典论断，再对应一组具体技能。理解这四个模式，比记住技能名字重要得多。
01 · Agent 做的不是我要的
"没有人确切知道自己要什么"
—《程序员修炼之道》
最常见的失败模式是没对齐。你以为对方懂了，看到成品才发现完全不是那回事。AI 时代这个沟通鸿沟一点没变小。
对策是拷问式访谈：让 agent 就你要做的东西，一个决策一个决策地问下去。/grill-me（不分代码）、/grill-with-docs（有仓库时用，会顺手留下文档）。作者说这是他最受欢迎的两个技能，每次想做改动前都该用。
02 · Agent 太啰嗦
"有了统一语言，开发者之间的对话和代码的表达都源自同一个领域模型"
—《领域驱动设计》
项目初期，开发者和领域专家说的根本不是一种语言。agent 更惨：它被直接丢进项目里，边干边猜行话，结果用 20 个词说 1 个词的事。
对策是统一语言：一份帮 agent 破译项目行话的文档（GLOSSARY.md）。效果是一句话的差别——「课程里的一节课被『实体化』（即在文件系统里拿到位置）时有问题」变成「物化级联有问题」。作者称这可能是整个仓库里最酷的技术，回报是复利的：命名一致、代码库更好导航、agent 思考也更省 token。
这项能力内建在 /grill-with-docs 里，访谈的同时就在建这份语言，并把难以解释的决策写进 ADR。
03 · 代码跑不起来
"永远小步前进。反馈速率就是你的速度上限。"
—《程序员修炼之道》
就算对齐了要做什么，产出还是一团糟，那要回头看反馈回路。没有代码实际运行情况的反馈，agent 就是在盲飞。
对策是老几样：静态类型、浏览器访问、自动化测试。其中红-绿-重构循环最关键——先写一个失败的测试，再让它变绿。/tdd 把这条循环连同「什么是好测试」的判断一起交给你；/diagnosing-bugs 则把调试封装成一个分阶段把关的纪律循环。
04 · 造出一坨泥球
"每天都要投资于系统的设计。" — Kent Beck
"最好的模块是深的：一个简单接口背后藏着大量功能。" —《软件设计哲学》
agent 能极大加速编码，也就以空前的速度加速软件熵增。大多数用 agent 搭出来的应用都复杂、难改。
对策是把设计当成日常投入，而不是事后补救。这条贯彻在每一层：/to-spec 建规格前先问清你动了哪些模块；/tdd 只在事先约定的接缝上写测试；/code-review 查的是仓库规范。还有专门的 /improve-codebase-architecture，勘察出「深化机会」把候选交给你——作者建议每隔几天在你的代码库上跑一次。
一句话概括
你在每个阶段问的问题不同——「我们要做的到底是什么」（对齐）、「它叫什么」（语言）、「它真的能跑吗」（反馈）、「它还能改吗」（设计）——但这四个问题贯穿始终，技能只是把这四个问题变成可重复的动作。
主流程：从想法到上线
大部分工作走这条主干。它有两个分叉点，三条从别处汇入的匝道。
主流程。第 1 到第 3 步要待在同一个未中断的上下文窗口里，中间不要 compact 或 clear，好让访谈、规格、工单建立在同一套思考上。/to-tickets 之后每个 /implement 都开新的，因为工单是自包含的。
还有三条上匝道，起点不是想法，而是别的东西，它们最终都会汇进主干：
- 别人的 bug 和需求堆积 →
/triage，把外部 issue 推过一串分诊角色，产出 agent-ready 的 issue 交给/implement。 - 东西坏了 →
/diagnosing-bugs，修完在同一个会话里跑/retro，问「什么能预防它」。 - 又大又雾的活儿 →
/wayfinder，画一张决策地图，雾散了交给/to-spec。
两条上下文纪律
这是整套东西里最容易被忽略、价值却最高的一部分。
智能区（smart zone）：模型还能保持锐利推理的窗口，作者给的量级是约 15 万 token。会话逼近它时不要硬扛，在最近的阶段边界上 compact 再继续。
阶段边界（phase boundary）：一个阶段是会话内的一段工作（访谈、实现、QA），只有两个阶段的交界处才该问「这段上下文怎么办」。阶段中段没什么可决定的——要么继续，要么把剩下的拆给子 agent。到了边界，按这个顺序考虑：
| 选项 | 什么时候选它 |
|---|---|
| 继续 | 下一阶段正需要这一段原文，或者智能区还有余量。它能让会话保持为「一手来源」，所以应该最先考虑、最先排除。 |
/clear |
后面的内容都可以抛弃。最便宜，但如果你判断错了，不可撤销。 |
/handoff |
有东西必须带走：换 harness、换目录、交接给同事、阶段中分叉出去的支线任务。 |
| 子 agent | 任务窄到可以让你离开键盘的时候跑。 |
/compact |
以上都不适用。它是默认项，排在最后，决策树通常停在这里。 |
这里有两个常见错误，所以顺序本身就是信息。/handoff 看起来像是通用的换窗口手段，其实它只给你「可携带性」这一件事。/compact 是树的最后一项，不是第一项，因为排在它前面的四个选项要么更便宜、要么更精确。
调用规则：谁能调谁
技能按「谁能唤起它」分成两类：
- 用户唤起（Claude Code 里标
disable-model-invocation: true）：只有你手打斜杠命令才会跑。它们的职责是编排。 - 模型唤起：你可以调，agent 也可以在任务合适时自己够到。它们承载的是可复用的纪律。
规则只有一条：用户唤起的技能可以调模型唤起的技能，但绝不能调另一个用户唤起的技能。所以你看到的是 /implement 内部去调 /tdd 和 /code-review，而不是让你自己把它们串起来。
一个已知副作用
Claude Code 会把带
disable-model-invocation的技能从注入给模型的技能清单里剔掉。模型读到那份清单时会当成全量，于是报告「这些技能没装」。/ask-matt的文档承认这是个已知未修的 bug——插件的 27 个技能里有 16 个带这个标记，所以这是常态而不是边角情况。它们是装好的，照打斜杠命令就行。
02 常用技能一览
官方插件只发布 engineering 和 productivity 两个桶——这是仓库自己的架构决策记录里写明的。in-progress 和 misc 要单独装，作者说前者是公开的 beta，随时会改会删。
Engineering · 日常主力
用户唤起 · 负责编排
| 技能 | 做什么 |
|---|---|
/ask-matt |
路由器。你说处境，它告诉你该打哪条命令，然后停下，不替你执行。 |
/grill-with-docs |
拷问式访谈，同时建领域模型，边聊边更新 GLOSSARY.md 和 ADR。主流程的入口。 |
/to-spec |
不再访谈，纯综合：把当前对话压成规格并发布到 issue tracker。 |
/to-tickets |
把计划、规格或对话切成 tracer bullet 工单，每个声明自己的阻塞边。 |
/implement |
按规格或工单实现，在约定接缝上调 /tdd，收尾调 /code-review，然后提交。 |
/implement-spec |
整份规格一次做完：把工单当任务图，在就绪前沿上并行跑实现子 agent，全部落到一条集成分支。 |
/wayfinder |
给一个会话装不下的活儿画决策地图，一次解一个，产出决策而不是交付物。 |
/triage |
把外来的 issue 推过分诊角色状态机，产出 agent-ready 的简报。 |
/improve-codebase-architecture |
扫描代码库找深化机会，出一份可视化 HTML 报告，你挑一个它再带你访谈进去。 |
/retro |
会话结束后回看，按严重程度建议改进 agent 的环境——导航、自动检查、编码规范、引导文件、工具链。 |
/setup-matt-pocock-skills |
每个仓库跑一次：配 issue tracker、分诊标签、领域文档位置。 |
模型唤起 · 可复用的纪律
| 技能 | 做什么 |
|---|---|
/tdd |
红-绿-重构循环。好测试的标准、测试只写在接缝上、三种反模式。一次一个竖切。 |
/code-review |
双轴评审：Standards（是否符合本仓库编码规范，外加一套 Fowler 坏味道基线）与 Spec（是否忠实实现了原始 issue）。两个轴各跑一个并行子 agent。 |
/diagnosing-bugs |
硬 bug 与性能回归的诊断循环，核心是先造出一个「这个 bug 一跑就红」的紧反馈回路。 |
/codebase-design |
深模块设计的共享词汇：模块、接口、深度、接缝、适配器、杠杆、局部性。是词典不是流程。 |
/domain-modeling |
主动打磨项目的领域模型：挑战术语、用边界场景压力测试、更新 GLOSSARY.md 和 ADR。 |
/prototype |
为回答一个设计问题做一次性原型——状态与逻辑用一个可分享的 HTML 文件，UI 用几个可切换的变体。 |
/research |
对着高可信一手来源调查一个问题，把结论写成带引用的 Markdown 落到仓库里，以后台 agent 运行。 |
/pr |
PR 正文该长什么样：用最小的可视化说清改动、改动前后它确实能跑的证据、以及合并风险的判断。 |
/wizard |
生成一个交互式 bash 向导，带你走只有人能做的步骤：provisioning、配密钥、走不熟的三方后台、一次性迁移。 |
Productivity · 不限代码
| 技能 | 做什么 | 调用 |
|---|---|---|
/grill-me |
无状态的拷问式访谈，直到设计树的每个分支都有结论。 | 用户 |
/grilling |
底层原语。把决策画成设计树，按前沿一轮一轮问，事实归它自己查，决策归你。上面所有「grill」都是它的壳。 | 模型 |
/handoff |
把当前对话压成交接文档，落在系统临时目录，含一节「建议下个 agent 调哪些技能」。 | 用户 |
/wait-what |
一句话急救键：上条消息没听懂，让它用简明技术英语重讲一遍，带上背景和你的 GLOSSARY.md 词汇。 |
用户 |
/teach |
把当前目录当成跨多次会话的教学工作区，产出课程、参考材料、学习记录。 | 用户 |
/to-questionnaire |
把你答不了的决策变成一份发给别人的问卷。它拷问的是「怎么发」，不是「问什么」。 | 用户 |
/writing-for-agents |
写 agent 读的文档：技能、AGENTS.md、CLAUDE.md，以及任何靠指针抵达的文档。 |
模型 |
In-progress · 公开 beta
不在插件里，要单独装。作者的原话是「公开是有意的：试试它们，然后告诉我哪里坏了」，它们随时会改或消失。
| 技能 | 做什么 |
|---|---|
/loop-me |
跨会话拷问，但只产出工作流规格：把你生活里反复出现的回路找出来，规格化到「实现 agent 不用再问任何问题」。 |
/writing-fragments |
写作·探索期。拷问出零散碎片，只往一个文件里追加，不做结构。 |
/writing-shape |
写作·利用期。把素材逐段塑造成文章，每一步都争论该用什么形式。 |
/writing-beats |
写作·利用期。选自己的冒险式成文：每次给你 2–3 个候选下一拍，你挑一个，只写下那一拍。 |
/claude-handoff |
/handoff 的进阶版：写完交接文档直接起一个后台 agent 接手。 |
/setup-ts-deep-modules |
给 TypeScript 仓库接 dependency-cruiser，让每个 package 必须是深模块（仅入口文件公开）。 |
/chief-of-staff |
在单个会话里靠协调子 agent 推进一个长期目标。 |
Misc · 边角料工具箱
作者自称「留着但很少用」，不随插件发布。
| 技能 | 做什么 |
|---|---|
git-guardrails-claude-code |
装一个 PreToolUse hook，在执行前拦掉危险 git 命令（push、reset --hard、clean -f、branch -D 等）。 |
setup-pre-commit |
配 Husky + lint-staged + Prettier + 类型检查 + 测试的提交钩子。 |
migrate-to-shoehorn |
把测试里的 as 断言迁到 @total-typescript/shoehorn。TypeScript 专用。 |
scaffold-exercises |
批量生成课程练习目录骨架。基本只对作者自己的课程仓库有用。 |
03 这些技能如何配合
这套设计里最关键的一句话是：它交付的是 flow（流）而不是 skill（技能）。flow 是穿过技能的一条路径。当你描述自己的处境时，它把你放到某条 flow 的某一步上——这和「按关键词匹配到一个技能」是完全不同的答案。
有人一直要一张按正确顺序排好的技能清单。作者的回答是：那样一张静态表会写 wayfinder → to-spec → to-tickets → implement → code-review → retro，而对大多数情况都是错的。真正重要的部分是那些分叉：有没有代码库？这次构建跨不跨会话？靠谈话能解决这个问题吗？
四个分叉判断
| 判断 | 结论 |
|---|---|
| 当前目录里有代码库吗？ | 有 → /grill-with-docs；没有 → /grill-me。两个跑的是同一个底层原语，有仓库时前者会留下书面痕迹。 |
| 这个问题靠谈话能解决吗？ | 不能（涉及状态、业务逻辑、必须看见的 UI）→ 走 prototype 支线，用 /handoff 进出。 |
| 这次构建跨多个会话吗？ | 跨 → /to-spec + /to-tickets；不跨 → 就地 /implement，跳过规格与工单。 |
| 这个活儿一个会话装得下吗？ | 装不下 → /wayfinder。/grill-with-docs 磨的是你一个会话能握住的想法；wayfinder 是给握不住的那个用的，更慢更密，别拿来处理范围明确的功能。 |
复用的原语
多个入口共用同一条底层纪律，所以你在不同场景里学到的是同一套东西。最典型的是 /grilling：
/grilling 是唯一被多个入口共用的访谈原语。箭头方向是真实的调用方向：这些入口去调它，而不是它去调它们。
谁在内部调用谁
| 编排者 | 内部调用 |
|---|---|
/grill-with-docs |
/grilling + /domain-modeling |
/implement |
/tdd（在约定接缝上）→ 收尾 /code-review → 提交 |
/implement-spec |
每个实现子 agent 各自驱动 /tdd，整条集成分支收尾跑一次 /code-review |
/improve-codebase-architecture |
/codebase-design（词汇）+ /grilling（挑中候选后） |
/tdd |
接口形状本身有疑问时，查 /codebase-design 的词汇 |
底下还有一层词汇层，是两个被反复引用的参考而不是流程：/codebase-design 提供深模块那一整套词汇（模块、接口、深度、接缝、适配器、杠杆、局部性）和它的原则（删除测试、「接口就是测试面」、「一个适配器是假想接缝，两个才是真接缝」）；/domain-modeling 提供 GLOSSARY.md 和 ADR 的维护规范。/tdd 明说自己去查前者，/to-spec、/to-tickets、/code-review 都要求你使用后者建立的词汇。
04 典型场景与组合方式
下面每个场景给出：你处在什么处境、按什么顺序打命令、以及这个顺序为什么是这样。
有了想法，从零开始做一个功能
流程：/grill-with-docs → /to-spec → /to-tickets → /implement → /code-review → /pr
为什么这么排：前四步要待在同一个上下文窗口里不中断，规格和工单才能建立在访谈得到的同一套思考上。/to-tickets 之后，每个 /implement 之间 /clear，因为工单是自包含的，上一个的上下文可以直接丢。收尾的 /code-review 是 /implement 自己会调的，你不用手打。
别人的 bug 和需求堆成山
流程：/triage → agent-ready issue → /implement
为什么这么排：分诊只处理不是你自己创建的 issue——bug 报告、外来需求、任何原始抵达的东西。/to-tickets 产出的工单已经是 agent-ready 的，不要再送进去分诊。分诊产出的简报会让 /implement 之后能直接接手。
线上出问题，第一眼看不出原因
流程：/diagnosing-bugs → /retro → /improve-codebase-architecture
为什么这么排：这个技能拒绝在没有紧反馈回路（一条已经会对这个 bug 变红的命令）之前开始推测。修完在同一个会话里跑 /retro，问「什么本来能预防它」。如果真正的结论是「这里根本没有好的接缝能锁住它」，那就是 /improve-codebase-architecture 的活。
绿地项目，或者一个雾蒙蒙的巨型功能
流程：/wayfinder → 逐个解决决策工单 → /to-spec → /to-tickets → /implement
为什么这么排：/wayfinder 只规划不施工，它产出的是决策而不是交付物，做完时「在有人动手之前已经没有待决定的东西了」。它交接，不构建——雾散之后并回主流程的 /to-spec，让规格把地图上互相链接的决策坍缩成可施工的计划。直接从地图跳到 /implement 会跳过这次坍缩，把链接细节全扔掉；只有发现这活儿其实很小的时候才那么做。
代码库开始腐烂
流程：/improve-codebase-architecture → 挑一个候选 → /codebase-design → /grill-with-docs
为什么这么排：它跑完给你一份带前后对比图的 HTML 报告，每个候选是一个深化机会——用删除测试判断（删掉它是把复杂度集中了，还是只是搬了个家？）。你挑一个，它带你访谈进去。挑中的那个候选会生成一个想法，再从主流程的入口进去。/codebase-design 是你设计这个候选的工作台。注意作者的提醒：它是勘察，不是救援，在一个真正老旧的代码库上它找得出真候选，但不会替你解开乱麻。
有个问题必须跑起来才知道答案
流程：/handoff → 新会话 /prototype → /handoff → 回到原线索
为什么这么排：原型活在自己的目录里，这正是 /handoff 存在的理由——把上下文搬过去，拿到结论再搬回来，并在原来的想法线索里引用这个结论。这一步用的是 handoff 的「可携带性」，而不是拿它当通用的换窗口手段。
会话太长，快撑爆上下文了
流程：走到阶段边界 → 继续？ → /clear？ → /handoff？ → 子 agent？ → /compact
为什么这么排：这个顺序本身就是信息。阶段中段不要做这个决定，要么继续，要么把剩下的拆给子 agent。到了边界按顺序问一遍，前面任一项成立就选它；四项都不成立才 compact。硬撑到智能区之外，得到的推理质量是下降的，不如在边界上主动处理。
要交接给同事，或者换个 agent / 换个目录
流程：/handoff → 文档落在系统临时目录 → 对方接手
为什么这么排：交接文档不重复规格、计划、ADR、issue、commit、diff 里已经有的内容，只给路径或 URL——避免同一份事实有两个会漂移的副本。它会脱敏，还会专门写一节「建议下个 agent 调哪些技能」。/claude-handoff 是它的进阶版，写完之后直接起一个后台 agent 接手。
有一个反复出现的个人工作流想固化下来
流程：/loop-me → workflows/*.md → 交给实现 agent
为什么这么排：/loop-me 用同一套访谈纪律，但把目标换成「你生活里反复出现的回路」——你的每周、你的早晨、某个反复做的动作。产出是工作流规格，完成的标准很硬：一个实现 agent 不用再问任何问题就能把它搭出来。它属于 in-progress，随时可能变。
闭环
每个场景都可以用
/retro收尾，尤其在一次走得不太顺的构建之后。它回看的不是代码而是agent 的环境：机械性的错误变成确定性的检查，判断题变成编码规范，下次构建从一个更好的起点开始。
05 上手前须知
安装：一个 agent 只选一条路
两条路都装会让每个技能拿到两份，所以按 agent 二选一。
| 场景 | 命令 |
|---|---|
| Claude Code 自动更新 |
claude plugin install mattpocock-skills@claude-plugins-official只含 engineering + productivity 两个桶。 |
| 其他 agent 手动更新 |
npx skills@latest add mattpocock/skills -a <agent>installer 问你要哪些技能时，务必勾上 setup-matt-pocock-skills。 |
| 单独装某个技能 in-progress 只能这样装 |
npx skills@latest add mattpocock/skills --skill=<name> |
装完跑一次 setup
在每个仓库里跑一次 /setup-matt-pocock-skills。它会问你三件事：用哪个 issue tracker（GitHub、GitLab、本地文件，或者你描述的任何东西）、你分诊时给工单打什么标签、以及创建的文档放哪。/to-spec、/to-tickets、/code-review、/wayfinder、/triage 都依赖这份配置。没配的话它们会直接让你去跑它。
改过名的技能
看老文章时容易踩到。三个改名：to-prd → /to-spec，pathfinder → /wayfinder，writing-great-skills → /writing-for-agents（没有留别名）。四个被彻底退役、吸收进别的技能：ubiquitous-language、design-an-interface、qa、request-refactor-plan。
仓库：github.com/mattpocock/skills
浙公网安备 33010602011771号