视频拆解 Matt Pocock Skills 日常使用工作流：从模糊想法到可工作代码的端到端方法论

录这期视频的时候，mattpocock/skills 已经有 16.2 万 star、750 万次下载。

截到 2026-08-03，我查了下，已经逼近 20 万 star（199,820）。forks 17,235，还在涨。

太多人问：这些 skill 按什么顺序用？怎么装？怎么配？Matt 干脆录了 17 分钟，把主线流程从头走了一遍。不讲高级功能。不讲实验性内容。只讲一条主线：每天打开 AI Coding 工具，该走的那条。

---

安装：一条命令，41 个 skill

前提：装好 Node.js。

 npx skills@latest add mattpocock/skills

这条命令会跑 Vercel 的 skills.sh CLI 安装器。把整个仓库拉下来，然后带你走交互式配置。

一共 41 个 skill。视频录制时是 38 个，后来有新增。仓库按 6 个功能目录组织：engineering（18 个主力 skill，含 grill-with-docs、implement、to-spec 等）、productivity、misc、personal、deprecated、in-progress。视频里的 CLI 安装器，把它简化成两组展示：官方发布的 「mattpocock skills」，和实验中 「other skills」。Matt 建议全选官方 skill。空格选中，回车确认。不过他也吐槽：Vercel 这个 CLI 交互有点烂。以后可能自己写一个换掉。

---

配置：选 Agent，定范围

先选 Agent。Claude Code、Cursor、Codex 都支持。Matt 选 Claude Code。这个要多配一步。其他通用 Agent，开箱即用。

再定安装范围。团队用项目级。装在当前目录，大家用同一套 skill，一起维护。独立开发者，全局装就行。安装方式选 Symlink。简单省事，不用纠结。

装完按 /，就能看到一堆 skill：grill-me、grilling、Wayfinder、grill-with-docs……全装完，加起来只占 660 tokens。

Matt 的做法：skill 默认不注入系统 prompt。调用了才加载。描述短而精确。不给上下文添负担。

---

Setup：跑一次就不用再管

在 agent 里输入：

 /setup-mattpocock-skills

三步配置：

Issue Tracker。存 spec 和 ticket 的地方。GitHub Issues、本地 Markdown、Jira、Linear，都行。Skill 读本地配置来适配，不绑平台。Matt 这次选本地 Markdown。

   经常有人问：怎么让 My Skills 对接 Jira？对接 Linear？它本来就能。你只要跑 setup-mattpocock，告诉它配 Jira 就行。 

Triage Labels。标记 ticket 状态用的。不太重要，用默认值。

Domain Documentation。99% 的人选 single context。巨型 monorepo，要多个 bounded context 才选 multi-context。

Setup 跑完，自动往 CLAUDE.md 写三个链接：issue tracker 文档、triage labels、domain docs。所有 issue 和 spec，存在 docs/agents/domain/issue-tracker 下的 scratch 文件里。

---

主线流程：四步从想法到提交

这套流程的骨架，就四个环节：

 grill-with-docs → to-spec → to-tickets → implement（含 code-review）

Matt 管它叫 「idea to ship」。从一个模糊想法开始，一路走到能提交的代码。

Grill-with-docs：把模糊想法问清楚

给一个想法。多模糊都行。

Matt 演示时，给的想法就两句话：

   我想把 CLI 上大部分内部工具删掉，只保留对外功能。这里有很多 cruft，我想让这个仓库轻量一点。 

grill-with-docs 干两件事。第一，自动探索代码库，理解项目结构。第二，提一连串问题，直到你们达成共识。

它发现 internal namespace 下面有 11 个子命令。就逐一追问：这个删不删？那个怎么处理？6 个问题后，产出一个清楚计划：删 10 个命令文件，加 3 个测试，重连共享模块。

Matt 说，通常会被问 20 个左右。6 个算少的。全程没开 Plan Mode。Claude Code 默认的 auto mode 就够了。

讨论结果，写进 context.md 和 ADR。这两个文件跨会话持久化。新开 agent，能读到之前所有决策。

分叉决策：Smart Zone

Matt 有个很实用的概念：Smart Zone。

Claude Code 用下来的实际体验：context window 前面大概 140k tokens，是模型的聪明区间。超过这个数，注意力衰减，幻觉变多。

所以做完 grill，走一个分叉：

• 任务小

  ，一个会话干得完：直接 /implement

• 任务大

  ，需要多个会话：走 to-spec → to-tickets → implement

Matt 这次的任务，删 10 个命令，只剩 100k 预算。其实一个会话就干得完。但为了演示完整流程，他假装要跨多个 context window。

Spec：把讨论压缩为文档

/to-spec 把刚才 46.1k tokens 的讨论，压成一份结构化文档。

里面有 problem statement、solution overview、user stories、implementation decisions、testing decisions。Matt 强调，这份 spec 是「最终目标状态」。描述做完之后，所有东西长什么样。tickets 描述的，是「怎么到那里」。

打开 spec 看一眼：信息量很大。后面所有实现，都要对照这份文档做验收。

Tickets：拆成单会话切片

同一会话里，接着跑 /to-tickets。把 spec 拆成能执行的 ticket。每个 ticket，刚好一个 smart zone 的尺寸。

这次任务给了 3 个 ticket。Matt 觉得切太碎了。「do it in one slice instead」，对话里调整，合并成 1 个。

他还展示了一个真实案例。一个删除功能的 spec 下面，挂着 11 个 sub-issues。每个 ticket 极短。只写「这个会话要做什么」。验收标准全在主 spec 里。这就是怎么把一大块工作，拆成 agent 能逐个处理的小块。

Implement：逐片实现

Clear context，开新会话，/implement this。跑完一个 ticket，clear context，下一个。

关键规则：一次只做一个 ticket。不是把所有 ticket 都做了。是一个一个来。每个 ticket 之间，清空上下文。目标是把每个会话，都保持在 smart zone 里。

implement skill 自动跑 type check、build、verification。

---

Code Review：双轴审查，子 Agent 执行

Implement 跑完，code-review skill 自动触发。

Matt 坚持用子 agent 做审查。不在主 agent 里跑。理由很直白：

   Agent 写了代码就不会觉得自己写得有问题。它写的东西它天然觉得「挺好的啊，没问题」。但 spawn 一些独立 agent，它们有干净的 context window，审查质量完全不一样。 

审查分两条线：

对照 spec。逐条查 acceptance criteria，确保每个 ticket 没漏。大任务里，agent 可能在 ticket 里漏东西。或者 ticket 本身不够具体。这遍能把关。

对照 coding standards。仓库自己写了编码规范，就用。检测不到，就 fallback 到 Martin Fowler 的经典标准。查 code smells，找不良代码。

两条线都过，commit，结束。

---

两条隐形规则

这套流程里有两条规则。Matt 没单独列章节讲。但贯穿全程：

User-invoked > auto-injected。Matt 的所有 skill，不自动注入系统 prompt。调用了才加载。41 个 skill，总共只占 660 tokens。对上下文几乎零负担。

单会话单 ticket，之间 clear context。每个 ticket，从干净 context 开始。上个会话的所有状态，全在 spec 和 ADR 里。不用靠记忆跨会话传信息。每个会话都卡在 smart zone 内。不会越跑越蠢。

---

小结

这套工作流，在做三件事：

1. 把 context window 当硬约束，不指望它够用。Smart Zone 是决策锚点。单会话还是多会话、切几个 ticket，全围着 140k 这个数转。

2. 把软件工程的基本功，搬进 AI coding。需求访谈、方案设计、任务拆分、逐片实现、对照验收、独立审查。工具换了，流程没变。

3. 让 agent 做擅长的，让结构管住它不擅长的。agent 擅长在下限内执行。那就拆 ticket、清 context、用 spec 对齐。agent 不擅长自我审查。那就 spawn 子 agent 做 code-review。

不用装 Matt 的 skill，也能落地这些原则。每次新会话前，想清楚「这次只做一件事」。做完，把关键决策写进 CLAUDE.md。审查用独立会话。够了。