Matt Pocock 的 Skills 线路图
Matt 把他的 Skill 排成一条主干线:从想法到上线。三条匝道从旁边汇进来,底下垫着一层共用词汇,外面还有一圈随时能用的独立站。一共 38 个:插件里 25 个,另有杂项 4 个、测试版 9 个。点图上任何一站,看它干什么、什么时候用、怎么用好。
内容整理自 mattpocock/skills(MIT License)。
现在就能做的 3 步
- 下次改代码前,先敲 /grilling,让 Agent 把你问清楚再动手。这次要新定业务名词,就换成 /grill-with-docs。
- 问完敲 /to-spec 存档。一个会话做得完,接着敲 /implement。
- 不知道该用哪个,敲 /ask-matt 问路,或者看下面的「我现在要……」。
这 3 步是我自己在用的轻量版。Matt 原版在有仓库时默认用 /grill-with-docs。
图比屏幕宽,左右滑动看全图。
- 主干线:想法到上线
- 匝道:大到一个会话装不下
- 匝道:别人报的问题
- 匝道:出 bug 了,修好即止
- 保养线:代码健康
- 地下层:共用词汇
- 起点站和虚线绕行
不在线路上的独立站
不属于哪条线,什么时候需要什么时候用。灰色圆点表示独立站。
资料和别人
- /research
后台读一手资料,留下带出处的笔记 - /to-questionnaire
答案在别人脑子里时,生成一份问卷 - /wizard
只有人能做的步骤,生成交互式向导
会话和表达
- /handoff
把会话写成能带走的交接文件 - /wait-what
没听懂时让它换个说法重讲 - /writing-for-agents
写给 Agent 看的文档怎么写 - /teach
跨好几次会话学一个新东西
代码
- /prototype
一次性原型,回答一个设计问题 - /resolving-merge-conflicts
按两边意图逐块解冲突,不放弃合并
用出效果的 8 条
从 Matt 的 README、问路 Skill 和教程页里提炼。每条下面注明出处。
动手前:先对齐
每次改东西前,先被追问一遍
Agent 一轮一轮问你,直到设计树上每个分支都有答案。能查到的事实它自己派人去查,只把决定交给你;每道题都附它推荐的答案,你按编号回。你确认双方想法一致之前,它不动手。
“Use them every time you want to make a change.”
出处:README;/grilling 原文
让 Agent 说你们的行话
/grill-with-docs 边问边把项目里的叫法写进 CONTEXT.md。有了共享语言,对话变短,变量和文件命名一致,Agent 思考花的 token 也更少。Matt 说这可能是整套里最厉害的一招。
“It might be the single coolest technique in this repo.”
出处:README 第 2 节
按活的大小选路线
一个会话做得完:追问完直接 /implement。要跨好几个会话:先 /to-spec 再 /to-tickets,每张单单独实现。大到装不下、路还看不清,才用 /wayfinder,它最重,普通功能别用。
出处:/ask-matt 主干线
动手时:给反馈、管上下文
给 Agent 反馈回路
类型检查、浏览器、自动化测试,少了它们 Agent 就是闭着眼写。/tdd 一次只做一片:先写一条会失败的测试,再让它通过。难搞的 bug 先造一条对它稳定报错的命令,再谈猜原因。
“The rate of feedback is your speed limit.”(Matt 引《程序员修炼之道》)
出处:README 第 3 节;/diagnosing-bugs 原文
追问、spec、拆单放在同一个会话
这三步中间别压缩、别清空,让后一步直接用前一步的原始推理。之后每张单开一次 /implement,单与单之间 /clear。会话快用到约 15 万 token 的「聪明区」上限时,在阶段交界处 /compact 再继续。
出处:/ask-matt 的上下文卫生一节
换不换会话,只在阶段交界处决定
按顺序问:能继续吗?上下文还有用吗?东西要带走吗?能交给子 agent 吗?都不是才 /compact。/handoff 只在换工具、换目录、交给同事或分出支线时用。详见「换不换会话」。
出处:ask-matt 的 PHASE-BOUNDARIES.md
长期:养代码
定期做一次架构体检
/improve-codebase-architecture 找出能加深的模块,出一份 HTML 报告,你挑一个接着追问。它只负责找候选,不会替你把一团乱麻理清。频率上,README 说每隔几天,文章说每周一次或开发量猛增之后。
出处:README 第 4 节;aihero.dev《5 Agent Skills I Use Every Day》
把模块做深
接口小,背后行为多,放在干净的接缝上,测试和调用方走同一个接口。Agent 写代码越快,代码变乱也越快,所以要天天在设计上下功夫。
“Invest in the design of the system every day.”(Matt 引 Kent Beck)
出处:README 第 4 节;/codebase-design 原文
我现在要……
挑一个最像你眼下情况的,右边给出该坐的路线。路线按 Matt 的问路 Skill(ask-matt)整理。
38 站索引
全部 Skill,按 Matt 仓库里的分组排列。圆圈颜色对应线路图上的线。点任意一行看详解。
换不换会话:阶段交界处的 5 个问题
一个「阶段」是会话里的一段活:追问、实现、验收。一段活做完、下一段还没开始,才是做这个决定的时候;做到一半不决定,要么继续,要么把剩下的拆给子 agent。按顺序问,第一个回答「是」的就是答案。
-
能在这个会话里继续吗?
能,就继续。
两种情况算能:下一步要直接用这一步的原始推理(追问完接着实现是标准例子),或者「聪明区」还剩够用的空间(约 15 万 token)。继续不花任何代价,也不丢任何东西,所以最先排除它。
-
这个会话里的东西,对接下来的事已经没用了?
用 /clear。
最便宜的一步,立刻拿回整个窗口,旧会话以后还能恢复。代价是单向的:清掉还有用的上下文,你会丢掉「为什么这样做」,回头看 diff 也找不回来。
-
东西要带走吗?
用 /handoff。
只有四种情况需要:换工具(比如从 Claude 换到 Codex)、换目录或仓库、交给同事、在阶段中途分出一个支线任务。它买的是「能带走」,没东西要带走就用不着。
-
这件事能不用你盯着就做完吗?
派一个子 agent。
范围收得够紧、中途不需要你掌舵的活,典型是自动审查:子 agent 在自己的窗口里读 diff、写报告,当前会话原封不动。
-
以上都不是?
用 /compact,并告诉它下一步要干什么,比如
/compact we're going to QA this area。它是兜底,不是第一选择。一上来就压缩,新会话会把被摘要抹平的决定「自信地记错」。
为什么先问「能不能继续」
除了继续,其他做法都会把原样的会话(一手资料)换成它的摘要(二手资料)。
| 资料 | 信息 | 噪音 | 腾挪空间 |
|---|---|---|---|
| 一手:继续当前会话 | 完整 | 多 | 小 |
| 二手:/compact、/handoff | 有损失 | 少 | 大 |
出处:ask-matt/PHASE-BOUNDARIES.md。Matt 也说这 5 个问题都带主观判断,同一个交界处不同的日子可能走不同的路,价值在于按顺序问。
为什么这样设计
Matt 说这些 Skill 用来修 Agent 常见的四种翻车。它们故意做得小、好改、能拼着用,不挑模型。他不认同 GSD、BMAD、Spec-Kit 这类把整个流程接过去的框架:它们拿走你的控制权,流程本身出了 bug 也难修。
Agent 没做成你想要的
你以为它懂了,做出来才发现完全没懂。解法是开工前让它追问你。
“No-one knows exactly what they want”David Thomas 和 Andrew Hunt,《程序员修炼之道》
Agent 太啰嗦
它被丢进项目,边干边猜行话,一个词能说清的事用二十个词。解法是一份共享语言文档。
“With a ubiquitous language, conversations among developers and expressions of the code are all derived from the same domain model.”Eric Evans,《领域驱动设计》
代码跑不通
需求对齐了,代码还是烂,问题出在反馈回路。它看不到代码实际怎么跑,就是在盲飞。解法是类型、浏览器和自动化测试,再加先红后绿的节奏。
“Always take small, deliberate steps. The rate of feedback is your speed limit. Never take on a task that’s too big.”《程序员修炼之道》
堆出一团烂泥
Agent 让写代码变快,也让代码变乱得更快。解法是在乎代码设计:spec 阶段就问你要动哪些模块,平时定期体检。
“The best modules are deep. They allow a lot of functionality to be accessed through a simple interface.”John Ousterhout,《软件设计的哲学》
你敲的(user-invoked):插件里 14 个
负责编排流程。只有你敲名字才会触发,Agent 不会自己用。
Agent 也会自己用的(model-invoked):插件里 11 个
装的是可复用的做事方法。任务合适时 Agent 会自己调用,你也可以手动敲。
一条硬规则:你敲的 Skill 可以调用 Agent 用的 Skill,但不能调用另一个你敲的 Skill。所以 /implement 能自己跑 /tdd 和 /code-review,/grill-with-docs 能调用 /grilling 和 /domain-modeling,但它们都不能替你敲 /to-spec。
出处:README「Reference」一节、.agents/invocation.md。
概念词典
Skill 原文里反复出现的词。先认得它们,读 Matt 的文章和 Agent 的输出会轻松很多。
对齐
- 追问grilling
- 让 Agent 一轮轮问你,直到设计树上每个分支都有答案,双方确认想法一致才动手。
- 设计树和前沿design tree / frontier
- 每个决定下面挂着依赖它的决定。前沿是前提都已定好、现在就能问的问题,一轮问完,再根据你的回答算下一轮。
- 事实归 Agent,决定归你facts vs decisions
- 能从环境里查到的事实,Agent 派子 agent 去查,不问你;决定一定交给你,等你回答。
- 共享语言ubiquitous language / CONTEXT.md
- 项目里的叫法和它们的准确含义,写进 CONTEXT.md,人和 Agent 用同一套词。
- 架构决策记录ADR
- 把难以回头的决定和当时的理由记下来,放在 docs/adr/。
拆活
- 示踪弹式切片tracer bullet / vertical slice
- 每张单是一条窄而完整的路径,穿过所有层(数据结构、接口、界面、测试),单独做完就能演示或验证,大小装得进一个新会话。反面是只做某一层的横切。
- 阻塞边blocking edges
- 每张单写明被哪些单挡着。本地文件里写成文字;真追踪器上变成原生的阻塞关系,挡它的单都完成了,它就能开工。
- 决策单decision ticket
- wayfinder 地图上的单,装的是一个待定的问题,解决它得到的是一个决定,不是一段交付。
- 需要人在场 / Agent 独立完成HITL / AFK
- 追问、原型这类单只能在和你的来回里解决;调研这类单 Agent 自己就能做完。
- 先扩后收expand–contract
- 大范围机械改动(比如改一个列名)的拆法:先让新旧写法并存,再分批迁移调用点,最后删掉旧写法,每一批都保持 CI 通过。
设计和验证
- 模块和接口module / interface
- 模块是任何有接口和实现的东西,大小不限。接口是调用方用对它必须知道的一切:类型签名,还有不变量、调用顺序、出错方式、所需配置、性能特征。
- 深模块deep module
- 小接口后面藏着大量行为。调用方学一点就能用很多(杠杆),改动和 bug 集中在一处(局部性)。反面是浅模块:接口几乎和实现一样复杂。
- 接缝seam
- 不改那处代码就能改变行为的位置,也就是接口所在的地方。只有一个适配器时接缝只是假设,有两个才是真的。
- 红→绿red-green
- 先写一条会失败的测试,再写刚好让它通过的实现。1.1.0 起重构这一步挪到了审查阶段。
- 反馈回路feedback loop
- 能快速告诉 Agent 代码到底对不对的东西:类型检查、浏览器、测试、一条能复现 bug 的命令。
会话
- 聪明区smart zone
- 模型还能想清楚的上下文长度,Matt 估计最先进的模型约 15 万 token。
- 阶段和阶段交界phase / phase boundary
- 会话里的一段活(追问、实现、验收)。两段之间是决定换不换会话的唯一时机。
- 一手和二手资料primary / secondary source
- 原样的会话是一手资料;/compact、/handoff 产出的摘要是二手的,有损失但干净。
- 你敲的和 Agent 用的user-invoked / model-invoked
- 前者只有你敲名字才触发,负责编排;后者 Agent 会自己调用,装的是做事方法。
- 引导词leading word
- 模型本来就懂的一个词,比如 grill、wait what,放在 Skill 名字或描述里,用它带出整套行为,比写一长串规则管用。
出处:grilling、codebase-design、to-tickets、domain-modeling 原文,ask-matt 与 PHASE-BOUNDARIES.md,CONTEXT.md,CHANGELOG。
Matt 公开怎么说
仓库、文章、教程页、演讲和播客里的原话。每条标了出处和核实程度:「已打开原文」是调研时真的读到了原文;「仅见于搜索摘要」是原页打不开(x.com 要付费),只看到搜索引擎给的片段。
-
“My agent skills that I use every day to do real engineering - not vibe coding.”
我每天真正做工程用的 Agent Skill,不是凭感觉写代码。
-
“These skills are designed to be small, easy to adapt, and composable. They work with any model.”
这些 Skill 故意做得小、好改、能拼着用,不挑模型。
-
“You have access to a fleet of middling to good engineers that you can deploy at any time. But these engineers have a critical flaw: they have no memory.”
你随时能调动一支中等到不错的工程师队伍,但他们有个要命的缺陷:没有记忆。
-
“AI has a natural inclination to sycophancy... it wants to produce complete solutions all at once. It doesn't stop to validate assumptions or get feedback.”
AI 天生爱讨好,总想一口气交出完整方案,不会停下来验证假设、要反馈。
-
“The principles apply harder to AI than they ever did to humans. Context window constraints make the discipline non-negotiable.”
这些工程原则放在 AI 身上比放在人身上更要紧,上下文窗口的限制让这份纪律没得商量。
-
“The glossary is the point. Domain language is the thing this skill is actually building.”
词汇表才是重点,这个 Skill 真正在建的是领域语言。
-
“No instruction makes an agent comply 100% of the time... the loop is worth running even when it is not followed strictly, because the results are still better overall.”
没有哪条指令能让 Agent 百分之百照做;就算没严格执行,这套红绿循环的整体结果仍然更好。
-
“GOOD: Ubiquitous Language / Bounded Contexts / ADR's. BAD: Entities / Value Objects / Aggregates / Domain Events”
领域驱动设计里他要共享语言、限界上下文和 ADR,不要实体、值对象、聚合、领域事件:用它记录应用,不用它规定应用长什么样。
他在不同场合推荐的顺序
| 出处 | 顺序 | 核实程度 |
|---|---|---|
| 仓库 ask-matt(最新、最权威) | 就是本页的线路图:追问 → 需要时原型绕行 → spec → 拆单 → 实现(内含 tdd 和审查) | 已核对原文 |
| 《5 Agent Skills I Use Every Day》,2026-03-16 | /grill-me → /to-spec → /to-tickets → /tdd → /improve-codebase-architecture(每周一次或开发量猛增之后)。名字按调研时页面上的写法 | 已打开原文 |
| AI Engineer 大会工作坊《Full Walkthrough: Workflow for AI Coding》,2026 年 4 月 | 人和 Agent 对谈消除产品歧义 → 组织成带依赖的垂直切片 → TDD 自动实现 → 自动审查;架构方向、产品判断和质量把关始终在人手里 | 会议官方摘要,不是逐字稿 |
| Unhandled Exception Podcast 第 88 期,2026-07-31 | /grill-me 连续追问,防止 AI 仓促动手 → /wayfinder 把大工作拆成决策单,用「迷雾」标出没定的部分 → /handoff 交给新 agent,不打断当前会话 | 仅节目简介 |
去哪看、去哪听
| 标题 | 类型 | 时间 | 核实程度 |
|---|---|---|---|
| 5 Agent Skills I Use Every Day | 文章 | 2026-03-16 | 已打开原文 |
| Tracer Bullets: Keeping AI Slop Under Control | 文章 | 2026-01-22 | 已打开原文 |
| 每个主力 Skill 的教程页(aihero.dev/skills-名字) | 教程 | 持续更新 | 和本地 docs 原文一致,本页每张卡都附了链接 |
| It Ain't Broke: Why Software Fundamentals Matter More Than Ever | 演讲,18 分钟 | 2026-04-09,AI Engineer Europe | 大会官网列出 |
| Full Walkthrough: Workflow for AI Coding | 工作坊,约 1.5 小时 | 2026 年 4 月,AI Engineer Europe | 大会官网列出 |
| Building Great Agent Skills: The Missing Manual | 演讲,21 分钟,讲怎么写 Skill | 2026 年,具体日期未核实 | 内容只看到第三方转述 |
| AI Skills with Matt Pocock(The Pragmatic Engineer) | 播客和文章 | 2026-09-17 | 标题和链接已核 |
| Unhandled Exception Podcast 第 88 期 | 播客 | 2026-07-31 | 仅节目简介 |
| Skills newsletter | 邮件订阅,Skill 更新会发在这里 | 持续 | README 自称约 6 万人订阅 |
| GitHub:mattpocock/skills | 源码 | 2026-02-03 建,最近推送 09-24 | 用 gh 查询 |
数字:GitHub 270,125 个 star、22,752 个 fork(2026-09-26 用 gh 查)。skills.sh 列出 54 个条目(含改名前的旧条目),累计安装 2470 万次,其中 grill-me 约 120 万次(调研员 09-26 打开页面所见)。网上文章里的 star 数从 5.4 万到 16 万各说各的,本页不采用。
版本和改名
Matt 改名、合并、删除得很勤。看他早期的视频和文章时,用下面的对照表把旧名字换成现在的。日期来自 GitHub 上各版本标签的提交时间。
2026-02-03 仓库建立
-
2026-06-17v1.0.0 和 v1.0.1
- 加入问路的 /ask-matt
- 新增两个共用词汇 Skill:/codebase-design、/domain-modeling,并把 /grilling 单独拿出来当可复用的内核
- diagnose 改名 diagnosing-bugs;write-a-skill 换成 writing-great-skills;删掉 caveman、zoom-out
- 分类从 Commands / Skills 改叫「你敲的 / Agent 用的」;teach 改成优先复用已有组件
-
2026-07-08v1.1.0
- to-prd 改名 /to-spec;to-plan 和 to-issues 合并成 /to-tickets
- review 转正为 /code-review,加上 Fowler 的 12 种代码坏味道做基线
- decision-mapping 改名 /wayfinder 并转正;新增 /research
- grilling 加「你确认前不动手」,并分开事实和决定;tdd 只讲红→绿,重构挪到审查
-
2026-08-05v1.2.0 和 v1.2.2
- 做成 Claude Code 插件,当天进入官方插件市场;同时补上 Codex 需要的元数据
- 新增 /wait-what;/to-questionnaire、/wizard 转正
- grilling 从一次一问改成一轮问一组;prototype 改成一个能分享的 HTML 文件,原型留在 prototype/名字 分支
- writing-great-skills 改名 /writing-for-agents;删掉 6 个旧 Skill(见下表)
-
2026-08-06v1.2.3(你装的就是这一版)
- diagnosing-bugs 要求给密钥和敏感输出打码;派子 agent 的写法不再绑定 Claude Code 的工具名;wizard 去掉时间估算
-
2026-09-17 上游新增测试版 /pr(还没发版)
2026-09-24 最近一次推送
旧名字对照
| 旧名字 | 现在 | 哪一版 |
|---|---|---|
| diagnose | /diagnosing-bugs | 1.0.0 |
| write-a-skill、writing-great-skills | /writing-for-agents | 1.0.0、1.2.0 |
| to-prd | /to-spec | 1.1.0 |
| to-plan、to-issues | /to-tickets | 1.1.0 |
| review | /code-review | 1.1.0 |
| decision-mapping | /wayfinder | 1.1.0 |
| ubiquitous-language | 并入 /domain-modeling | 1.2.0 |
| design-an-interface | 并入 /codebase-design(设计两次的方法在它的 DESIGN-IT-TWICE.md) | 1.2.0 |
| qa | 并入 /triage 和 /to-tickets | 1.2.0 |
| request-refactor-plan | 并入 /to-spec 和 /improve-codebase-architecture | 1.2.0 |
| caveman、zoom-out | 删除 | 1.0.0 |
| edit-article、obsidian-vault | 删除(Matt 自己机器上用的) | 1.2.0 |
出处:插件内 CHANGELOG.md;版本日期用 gh 查标签提交时间。
来源和说明
- 内容整理自 mattpocock/skills(MIT License),仓库地址 https://github.com/mattpocock/skills。
- Skill 原文:插件缓存 1.2.3(每个 SKILL.md、参考文件、docs 教程页、CHANGELOG、ADR),加上 GitHub main(09-26 用 gh 查:版本号同为 1.2.3,最近推送 09-24,比插件多一个测试版 pr)。
- 讲解卡:按原文逐条翻译整理,每张卡底部列出读过的文件。docs 教程页和 SKILL.md 说法不一致时以 SKILL.md 为准,卡里另有注明。
- 公开发言:见「Matt 公开怎么说」的核实程度一栏。没核实到的:X 推文原文(x.com 要付费)、演讲逐字稿、第三方文章里互相矛盾的 star 数。
- 本页整理于 2026-09-26,个人信息已脱敏,欢迎转发。