一、开场：等了很久的一份"说明书"
Matt Pocock（@mattpocockuk）是 TypeScript 圈的知名教育者，个人站 aihero.dev。他的 skills 仓库到录这期视频（2026 年 7 月 9 日）时，已经攒到 162,000 star、750 万次下载，可他自己一直没做过一份正经教程。
"At the time of recording, this repo is up to 162,000 stars, we have 7.5 million downloads, and I've never made a tutorial for it."
「录这期时，仓库已经 16.2 万 star、750 万下载，我却从没给它做过教程。」
收到最多的问题永远是那三个：这些 skill 该按什么顺序用、怎么装、怎么配。所以这支 17 分钟视频只干一件事——把主流程从头到尾走一遍，不碰进阶功能、不碰新玩具，只讲上手真正需要的东西。演示用的是他自己的工作仓库 ai-hero-cli（驱动他课程练习的命令行工具），而且他此前从没在这个仓库配过 skills，正好当一次"全新项目从零接入"的样板——绿地、棕地都一个装法。
二、安装：一行命令搞定
装这套东西只要一行命令：
npx skills@latest add mattpocock/skills
前提是本机装了 Node.js（npx 来自 Node），它会跑 skills.sh 的安装器，把 mattpocock/skills 这个 GitHub 仓库拉下来。安装器扫出 38 个 skill，分两组：Matt 亲自"开过光"、认为够格公开的官方 skill，和他自己还在试验、随时可能删的实验品。建议全选官方那批（空格全选、回车确认）。
skills 会配成对任何 agent 都能用：Cursor、Codex、Cline 这些"通用"harness 开箱即支持；而像 Claude Code 这种走 Claude skills 机制的，需要单独勾一下。安装范围可选当前目录或全局——团队协作选 project skills（大家用同一套、能一起贡献），单干选 global 也行。最后一步选 symlink，别纠结：
"Symlink is just the nice easy way to do it, so I wouldn't even make a decision here — just choose symlink."
「symlink 就是最省事的方式，这一步都不用想，直接选它。」
npx skills@latest add 拉下 38 个 skill装完还得跑一次 setup mattpocock skills 做仓库级配置，三件事：① 选一个 issue tracker（存 spec 和 ticket 用，可选 GitHub / 本地 markdown / Jira / Linear——想用哪个直接告诉 agent，它会去配，演示里选的是本地 markdown）；② triage 标签（默认即可）；③ domain 文档（context.md + ADR，99% 的人选 single context 就够，multi-context 是给大 monorepo 留的）。
三、五步主流程概览
Matt 先用一个"我作为 skill"的彩蛋引出全流程——ask matt skill。它把 Matt 本人对这套 skills 的理解装了进去，你可以直接问它该怎么开始：
"This ask matt skill is essentially me as a skill — it knows everything that is needed about the skills repo and what you should do first."
「ask matt 这个 skill 基本就是'我'本人——它知道关于这个 skills 仓库该知道的一切，以及你第一步该干嘛。」
它给出的主流程一句话就是：从顶上开始一路往下走，而且尽量在一个不中断的上下文窗口里走完。
"Start at the top of the main flow and walk down it in one unbroken context window."
「从主流程顶端起步，在一个不中断的上下文窗口里一路走到底。」
完整的五步是：
grill-with-docs → to-spec → to-tickets → implement → code-review
grill-with-docs 负责把"我想改 X"这种模糊念头逼问成一个清晰、站得住脚的计划（Matt 顺嘴吐槽："defensible is such an LLM phrase honestly"）。谈完之后有个岔路口：活儿小、一个上下文窗口就能干完的，直接 implement；活儿大、要跨多个会话的，就先 to-spec、再 to-tickets 把它拆开。
四、Grill With Docs：把模糊想法烤成共识
演示环节，Matt 给 grill-with-docs 扔了一个非常随意的想法：
"I would like to remove most of the internal tooling on this CLI to make it just only public-facing. There's a lot of cruft here, I want to just take this repo down a notch."
「我想把这个 CLI 上大部分内部工具砍掉，只留对外公开的部分。这里一堆废料，我想给仓库瘦个身。」
就这么随意——因为重活是 grill 来挑：它会疯狂追问、疯狂读代码。
"It really can be as vague as this — grill with docs is going to do the heavy lifting by asking you a bunch of follow-up questions."
「真就可以这么模糊——grill with docs 会用一连串追问把重活扛下来。」
一个容易被忽略的细节：Matt 此时用的是 Claude Code + Opus 4.8 + medium effort，但"你完全不用跟我一样"，这套 skills 被各种 harness、各种模型、各种 effort 级别的人在用。还有个反直觉的点——他没开 plan mode：
"Notice here I wasn't using plan mode for this — I was actually in auto mode in Claude Code, which is kind of like the default mode."
「注意我没用 plan mode，我用的是 Claude Code 的 auto mode，也就是默认模式。」
这轮 grilling 问了大概 6 个问题（他说通常会到 20 个左右，取决于规模），最后收敛成一个像样的计划：删 10 个命令文件、删 3 个测试、重接共享模块。判断"谈完了"的标准很朴素——
"We've walked the whole tree, we've reached a shared understanding, let me lay out the plan."
「我们把整棵树都走了一遍，达成了共识，让我把计划摆出来。」
五、To-Spec + To-Tickets：目的地与路线图
到岔路口，Matt 为了演示，假装这活儿大到要跨多个会话，于是不走 implement，改叫 to-spec。to-spec 会把刚才那一整段讨论（46.1k tokens）压缩成一份文档，写进 issue tracker（这里就是本地 markdown）。这份 spec 的定位很关键：
"This spec is going to be the destination that we're heading to... and then the tickets is the description of how we're going to get there."
「spec 是我们要抵达的终点——长什么样、最后是什么结果；ticket 则是怎么走到那里的描述。」
spec 里有问题陈述、解决方案、user story、实现决策、测试决策——足够细，好处是收尾时能拿它逐条对账，确认实现和 spec 对得上。
接着在同一个会话里叫 to-tickets，把 spec 拆成执行计划。关键约束是每张 ticket 的粒度：
"Each one of these tickets is supposed to just be the size of a single context window, or a single smart zone."
「每张 ticket 的体量，应该正好是一个上下文窗口、或者说一个 smart zone 能装下的量。」
演示里它拆了 3 张，Matt 觉得多了，直接让它并成 1 张。他还翻出一个真实例子：几天前的一份 spec 底下挂了 11 张 ticket，每张就是一个会话该干的活，验收标准大多已经写在主 spec 里，ticket 本身只回答"这个会话你要造什么"。
真正干活时是一张一张来：clear 掉上下文，然后 implement this @tickets。因为 spec 定了去哪、ticket 定了怎么去，agent 手上就齐了。Matt 的手动节奏是——做完一张看看有没有撞到 smart zone，没撞到也许再塞一张，但通常每张之间都会 clear。
六、Implement + Code Review：执行与双轴审查
implement 跑完会自动接上 code review（code review 是 implement 脚本的一部分）：先跑类型检查、跑构建、做验证，再加载 code review skill。这个 review 走两根轴：
"First it compares the work done against the original spec... and then it also checks against the standard documentation that you've got in your own repo."
「第一轴：拿完成的活对照原始 spec；第二轴：对照你自己仓库里的标准文档。」
第一轴在你干了一大坨活、agent 可能"忘了某些事"或 ticket 没写全时特别有用——最后一遍能把东西钉死。第二轴如果仓库里没有成文的编码规范，它就退回用一套经典的（Martin Fowler 那套）查 code smell。
而整段最重要的一句，是关于为什么要用 sub-agent 而不是主 agent 来 review：
"If you do it in the main agent, the main agent already wrote the code — agents are often really bad at editing or improving code they've just written, because they wrote it, so they just think 'okay that's fantastic, that's fine.' Whereas if you spawn some agents, they have a clear context window and do a much better job."
「在主 agent 里 review，它自己刚写完这些代码——agent 特别不擅长改自己刚写的代码，因为是它写的，它只会觉得'挺好挺好没问题'。换成新开的 sub-agent，它有一个干净的上下文窗口，review 得好得多。」
两根轴都回来后（逐条核对验收标准、逐项核对规范），代码就提交到当前分支。整个主流程闭环：开工前对齐 → 产出 spec 和 ticket 以撑起跨会话 → 实现 → implement 内置的 code review 收尾。
七、设计哲学：轻上下文、重对齐
这套流程背后有两条一以贯之的取舍。
第一，上下文要轻。尽管一次性下了全部 38 个 skill，它们在上下文里只占 660 tokens：
"Even though we've downloaded all of my skills, the skills only take up 660 tokens — very very light in terms of context load."
「哪怕把我全部 skill 都下下来，它们只占 660 tokens——上下文负担极轻。」
秘诀在于 Matt 的 skills 绝大多数是"用户触发"而非"模型触发"（user-invoked, not model-invoked）——大部分 skill 不会把自己塞进给模型看的描述里，描述本身也写得又短又精准。你主动 /grill-with-docs 才唤起它，而不是让它一直挂在上下文里抢注意力。
第二，对齐要重。Matt 反复回到那条 "smart zone" 判断：
"I think of my context window as getting significantly dumber around the 140k mark — that's the smart zone. Above 140k you get attention degradation, it gets stupider, does weird hallucinations."
「我把上下文窗口看成大概到 14 万 tokens 就明显变笨——那是 smart zone 的边界。超过 14 万就开始注意力衰减、变蠢、出奇怪的幻觉。」
正因为"聪明的预算"有限，整套流程才围绕把一件大事切成一个个能装进 smart zone 的会话来设计：grill 逼出共识、spec 定终点、ticket 定单会话粒度、implement 之间清上下文、review 用新的 sub-agent。轻上下文是为了省预算，重对齐是为了让每个会话都用在刀刃上。
主流程之外的都是 Matt 还在打磨的实验品——他说自己一直想把这个循环"跑得更快、更好、更省事"。这份 17 分钟的样板，就是这个循环目前最稳的形态。
本文基于 Matt Pocock（@mattpocockuk）2026 年 7 月 9 日发布的 Skills 主流程教程视频整理，清理了口语赘词，尽量保留讲者原话语气。英文引用为讲者原话（据视频转录整理），中文为对照译文。
视频来源：Matt Pocock 的推文 · @mattpocockuk