视频拆解 Matt Pocock Skills 日常使用工作流从模糊想法到可工作代码的端到端方法论录这期视频的时候mattpocock/skills 已经有 16.2 万 star、750 万次下载。截到 2026-08-03我查了下已经逼近 20 万 star199,820。forks 17,235还在涨。太多人问这些 skill 按什么顺序用怎么装怎么配Matt 干脆录了 17 分钟把主线流程从头走了一遍。不讲高级功能。不讲实验性内容。只讲一条主线每天打开 AI Coding 工具该走的那条。安装一条命令41 个 skill前提装好 Node.js。npx skillslatest add mattpocock/skills这条命令会跑 Vercel 的 skills.sh CLI 安装器。把整个仓库拉下来然后带你走交互式配置。一共 41 个 skill。视频录制时是 38 个后来有新增。仓库按 6 个功能目录组织engineering18 个主力 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。简单省事不用纠结。装完按/就能看到一堆 skillgrill-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-reviewMatt 管它叫 「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 ZoneMatt 有个很实用的概念Smart Zone。Claude Code 用下来的实际体验context window 前面大概 140k tokens是模型的聪明区间。超过这个数注意力衰减幻觉变多。所以做完 grill走一个分叉任务小一个会话干得完直接/implement任务大需要多个会话走to-spec → to-tickets → implementMatt 这次的任务删 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。跑完一个 ticketclear context下一个。关键规则一次只做一个 ticket。不是把所有 ticket 都做了。是一个一个来。每个 ticket 之间清空上下文。目标是把每个会话都保持在 smart zone 里。implementskill 自动跑 type check、build、verification。Code Review双轴审查子 Agent 执行Implement 跑完code-reviewskill 自动触发。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 内。不会越跑越蠢。小结这套工作流在做三件事把 context window 当硬约束不指望它够用。Smart Zone 是决策锚点。单会话还是多会话、切几个 ticket全围着 140k 这个数转。把软件工程的基本功搬进 AI coding。需求访谈、方案设计、任务拆分、逐片实现、对照验收、独立审查。工具换了流程没变。让 agent 做擅长的让结构管住它不擅长的。agent 擅长在下限内执行。那就拆 ticket、清 context、用 spec 对齐。agent 不擅长自我审查。那就 spawn 子 agent 做 code-review。不用装 Matt 的 skill也能落地这些原则。每次新会话前想清楚「这次只做一件事」。做完把关键决策写进 CLAUDE.md。审查用独立会话。够了。