Matt Pocock Skills 线路图
目录
  1. 线路图
  2. 用出效果的 8 条
  3. 我现在要……
  4. 38 站索引
  5. 换不换会话
  6. 为什么这样设计
  7. 概念词典
  8. Matt 公开怎么说
  9. 版本和改名
  10. 来源

Matt Pocock 的 Skills 线路图

Matt 把他的 Skill 排成一条主干线:从想法到上线。三条匝道从旁边汇进来,底下垫着一层共用词汇,外面还有一圈随时能用的独立站。一共 38 个:插件里 25 个,另有杂项 4 个、测试版 9 个。点图上任何一站,看它干什么、什么时候用、怎么用好。

内容整理自 mattpocock/skills(MIT License)。

现在就能做的 3 步

  1. 下次改代码前,先敲 /grilling,让 Agent 把你问清楚再动手。这次要新定业务名词,就换成 /grill-with-docs。
  2. 问完敲 /to-spec 存档。一个会话做得完,接着敲 /implement。
  3. 不知道该用哪个,敲 /ask-matt 问路,或者看下面的「我现在要……」。

这 3 步是我自己在用的轻量版。Matt 原版在有仓库时默认用 /grill-with-docs。

图比屏幕宽,左右滑动看全图。

  • 主干线:想法到上线
  • 匝道:大到一个会话装不下
  • 匝道:别人报的问题
  • 匝道:出 bug 了,修好即止
  • 保养线:代码健康
  • 地下层:共用词汇
  • 起点站和虚线绕行

不在线路上的独立站

不属于哪条线,什么时候需要什么时候用。灰色圆点表示独立站。

问路和追问

  • /ask-matt
    按你的情况指到该用的 Skill 或路线
  • /grill-me
    没有代码仓库时的追问,不存文件
  • /grilling
    追问的内核,好几个 Skill 都在调用它

资料和别人

  • /research
    后台读一手资料,留下带出处的笔记
  • /to-questionnaire
    答案在别人脑子里时,生成一份问卷
  • /wizard
    只有人能做的步骤,生成交互式向导

会话和表达

代码

用出效果的 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。按顺序问,第一个回答「是」的就是答案。

  1. 能在这个会话里继续吗?

    能,就继续。

    两种情况算能:下一步要直接用这一步的原始推理(追问完接着实现是标准例子),或者「聪明区」还剩够用的空间(约 15 万 token)。继续不花任何代价,也不丢任何东西,所以最先排除它。

  2. 这个会话里的东西,对接下来的事已经没用了?

    用 /clear。

    最便宜的一步,立刻拿回整个窗口,旧会话以后还能恢复。代价是单向的:清掉还有用的上下文,你会丢掉「为什么这样做」,回头看 diff 也找不回来。

  3. 东西要带走吗?

    用 /handoff。

    只有四种情况需要:换工具(比如从 Claude 换到 Codex)、换目录或仓库、交给同事、在阶段中途分出一个支线任务。它买的是「能带走」,没东西要带走就用不着。

  4. 这件事能不用你盯着就做完吗?

    派一个子 agent。

    范围收得够紧、中途不需要你掌舵的活,典型是自动审查:子 agent 在自己的窗口里读 diff、写报告,当前会话原封不动。

  5. 以上都不是?

    用 /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,《程序员修炼之道》

/grill-me /grill-with-docs /grilling

Agent 太啰嗦

它被丢进项目,边干边猜行话,一个词能说清的事用二十个词。解法是一份共享语言文档。

“With a ubiquitous language, conversations among developers and expressions of the code are all derived from the same domain model.”Eric Evans,《领域驱动设计》

/grill-with-docs /domain-modeling /wait-what

代码跑不通

需求对齐了,代码还是烂,问题出在反馈回路。它看不到代码实际怎么跑,就是在盲飞。解法是类型、浏览器和自动化测试,再加先红后绿的节奏。

“Always take small, deliberate steps. The rate of feedback is your speed limit. Never take on a task that’s too big.”《程序员修炼之道》

/tdd /diagnosing-bugs

堆出一团烂泥

Agent 让写代码变快,也让代码变乱得更快。解法是在乎代码设计:spec 阶段就问你要动哪些模块,平时定期体检。

“The best modules are deep. They allow a lot of functionality to be accessed through a simple interface.”John Ousterhout,《软件设计的哲学》

/to-spec /improve-codebase-architecture /codebase-design

你敲的(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,不是凭感觉写代码。

    仓库 README,已核对原文

  • “These skills are designed to be small, easy to adapt, and composable. They work with any model.”

    这些 Skill 故意做得小、好改、能拼着用,不挑模型。

    仓库 README,已核对原文

  • “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.”

    你随时能调动一支中等到不错的工程师队伍,但他们有个要命的缺陷:没有记忆。

    《5 Agent Skills I Use Every Day》,2026-03-16,已打开原文

  • “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 天生爱讨好,总想一口气交出完整方案,不会停下来验证假设、要反馈。

    《Tracer Bullets: Keeping AI Slop Under Control》,2026-01-22,已打开原文

  • “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 真正在建的是领域语言。

    grill-with-docs 教程页,与本地 docs 原文一致

  • “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 百分之百照做;就算没严格执行,这套红绿循环的整体结果仍然更好。

    tdd 教程页,与本地 docs 原文一致

  • “GOOD: Ubiquitous Language / Bounded Contexts / ADR's. BAD: Entities / Value Objects / Aggregates / Domain Events”

    领域驱动设计里他要共享语言、限界上下文和 ADR,不要实体、值对象、聚合、领域事件:用它记录应用,不用它规定应用长什么样。

    X @mattpocockuk,仅见于搜索摘要

他在不同场合推荐的顺序

出处顺序核实程度
仓库 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 分钟,讲怎么写 Skill2026 年,具体日期未核实内容只看到第三方转述
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 上各版本标签的提交时间。

  1. 2026-02-03 仓库建立

  2. 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 改成优先复用已有组件
  3. 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 只讲红→绿,重构挪到审查
  4. 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(见下表)
  5. 2026-08-06v1.2.3(你装的就是这一版)

    • diagnosing-bugs 要求给密钥和敏感输出打码;派子 agent 的写法不再绑定 Claude Code 的工具名;wizard 去掉时间估算
  6. 2026-09-17 上游新增测试版 /pr(还没发版)

  7. 2026-09-24 最近一次推送

旧名字对照

旧名字现在哪一版
diagnose/diagnosing-bugs1.0.0
write-a-skill、writing-great-skills/writing-for-agents1.0.0、1.2.0
to-prd/to-spec1.1.0
to-plan、to-issues/to-tickets1.1.0
review/code-review1.1.0
decision-mapping/wayfinder1.1.0
ubiquitous-language并入 /domain-modeling1.2.0
design-an-interface并入 /codebase-design(设计两次的方法在它的 DESIGN-IT-TWICE.md)1.2.0
qa并入 /triage 和 /to-tickets1.2.0
request-refactor-plan并入 /to-spec 和 /improve-codebase-architecture1.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,个人信息已脱敏,欢迎转发。