原文：
01-选题与灵感/01-待深化选题/mattpocock skills 推荐.md01-选题与灵感/01-待深化选题/X 上的 Kieran Zhang介绍一下我最喜欢的 agentic coding skills 套件作者 mattpocockuk 刚刚正式发布 v100 版本了相比旧版本有了不少的改动今天从全局视.md重写说明：基于两篇原文合并重写，保留推荐口吻，调整成一条更清楚的「idea → ship」主线。
Matt Pocock 的 skills v1，最值得看的不是清单，而是一套工程工作流
最近我在看 Matt Pocock 的 skills，发现它有一种很明显的活人气息。
很多 AI workflow 看起来像框架设计文档，概念很满，但你很难判断作者是不是真的每天在用。
Matt 这套不一样。
它的 README 里写得很直接：这些 skills 来自他的 .claude 目录，是他自己每天做真实工程时用的东西。不是为了包装一个完美框架，而是把一些工程师真的会踩的坑，拆成一组很小、很具体、可以组合的工作流。
说得再直白一点：
这套 skills 的重点不是“让 AI 更会写代码”，而是“让人和 Agent 更不容易一起跑偏”。
这次 v1 发布之后，结构比之前清楚很多。官方 README 现在把 skills 分成两类：
- User-invoked skills：你主动输入命令触发，比如
/grill-me、/to-prd。 - Model-invoked skills：Agent 在合适的时候自动使用，比如
tdd、domain-modeling、codebase-design。
这个划分很关键。
以前很多人写 skill，容易把“流程入口”和“底层纪律”混在一起。结果就是每个 skill 都想管全流程，最后上下文又长，边界又乱。
Matt 这次的思路更像工程拆模块：用户只需要记住几个入口，底层复用的规则放到更小的 model-invoked skills 里。
这也是我觉得 v1 真正有价值的地方。
一条主流程
如果你第一次用这套 skills，记一条主线就够了：
idea -> 打磨设计 -> 固化任务 -> 实现构建 -> 持续优化
这条线其实就是一个正常的软件开发周期。
区别在于，以前我们经常直接从 idea 跳到 code。现在有了 Agent，跳得更快，也更危险。
你随手说一句“帮我做个权限系统”，Agent 可能真的开始写了。它写得越快，越容易把模糊需求变成一堆看起来能跑、但后面很难改的代码。
Matt 这套 skills 最先解决的就是这个问题：别急着写，先把事情想清楚。
第一步：不知道用哪个，就先问 ask-matt
v1 里新增的 ask-matt 很像一个路由器。
你不用一开始就判断现在该用 /grill-me、/prototype 还是 /to-prd。如果你卡住了，直接问它，让它根据当前情况推荐下一步。
这点很实用。
很多 workflow 最大的问题不是“不好用”，而是你不知道什么时候该用。一个路由 skill 的价值，就在于把选择成本降下来。
尤其是当 skills 越来越多时，入口必须少。
这和我之前写 Agent Skills 时的感受很像：Skill 不应该一股脑塞进主提示词。更好的方式是先给 Agent 一个索引，真的需要时再按需加载。
第二步：用 grill 把想法拷问清楚
这套 skills 里我最喜欢的，一直是 grill-me 和 grill-with-docs。
它们做的事情很朴素：让 AI 反过来问你问题。
不是那种礼貌地问两句”你希望什么风格”，而是围着你的计划、设计、边界条件一直追问，直到你自己也没法继续含糊。
我实际跑了一次，有个细节让我印象很深：它问的问题不像 AI，像一个资深工程师在做 design review。
它会问”这个接口改了之后，依赖它的三个下游怎么处理”，而不是”你打算怎么设计这个功能”。
前者是有上下文意识的追问，后者是套模板。这个差别说起来简单，但体感完全不一样。（我当时被问到第三个问题就开始低头翻代码了，这才是它想要的结果。）
如果你还没有代码，只有一个想法，用 /grill-me。
如果项目里已经有代码，而且你准备做一个新功能或改一个模块，用 /grill-with-docs。
后者更重一点。它不只是拷问需求，还会顺手沉淀项目的领域模型，更新 CONTEXT.md 和 ADR。
这件事听起来像文档洁癖，但它其实很工程。
Agent 最大的问题之一，是它经常不知道项目里的“黑话”。人类团队里一句“这里会触发 materialization cascade”，Agent 可能要绕二十句话才理解。
如果你把这些领域词汇沉淀下来，后面的对话会短很多，代码命名也会稳定很多。
所以 domain-modeling 这种底层 skill 不一定经常被你直接调用，但它很重要。它像项目里的词汇表，帮 Agent 少说废话，也少猜错。
第三步：把聊清楚的东西固化下来
需求聊清楚之后，不一定马上写代码。
如果这个功能比较大，可以先用 /to-prd 把当前对话整理成 PRD。
这里的重点是“当前对话已经聊透”。to-prd 不是再开一轮拷问，而是把已经形成的共识固化成文档。
再往下，可以用 /to-issues 把 PRD 拆成一个个独立的 issue。
我觉得这个地方很适合 Agent 开发。
因为 Agent 最怕大而糊的任务。你给它一个”做完整支付系统”，它会把很多判断藏在实现里。你给它一个边界明确的 issue，它反而更容易做出可 review 的增量。
这也是所谓 vertical slice 的价值：每个任务都应该能独立交付、独立验证。
有一点我体验之前没预期到：/to-issues 不是把 issue 写成本地 markdown 文件，它会真的帮你在 GitHub 上创建 issue。
这个细节让整个流程跟工程协作接上了。你不是在本地自说自话，你创建的东西直接进了 repo 的 issue tracker，可以分配、打标签、被 PR 引用。
我第一次跑完发现 issue 真的出现在 GitHub 上，有点愣了一秒（以为自己配错了什么）。后来才意识到这是设计如此。和 GitHub 这一层的集成，是这套 workflow 能在真实团队里跑起来的关键。
第四步：到这里才开始写代码
前面看起来绕，但真正写代码时会省很多时间。
到实现阶段，Matt 这套里面有几个很关键的底层纪律。
tdd 负责红-绿-重构。也就是先写失败测试，再写实现，再整理结构。
这不是为了仪式感。
Agent 写代码很快，但如果没有反馈循环，它也会很快把错的东西写完整。测试就是最直接的刹车片。
diagnosing-bugs 负责 debug 纪律。它强迫 Agent 先复现问题，再缩小范围，再提出假设，再加日志或工具验证，最后修复和回归。
这点对 Agent 特别重要。
因为 Agent 很容易“看起来很懂”地猜一个原因，然后直接改代码。猜对时很爽，猜错时就是在制造第二个 bug。
codebase-design 则更像一套设计语言。它强调 deep modules：把复杂性藏在简单接口后面，并且让接口可测试。
这个思路我很喜欢。
现在很多 AI coding 的问题不是“写不出来”，而是“写太多”。模块边界没想清楚，代码会越来越像一坨泥。Agent 提速之后，这个腐化过程也会被提速。
所以 v1 里把 codebase-design 抽成底层 skill，我觉得是一个很对的改动。
第五步：上线不是终点，还要回头看结构
功能做完之后，这条线没有结束。
你可以隔几天跑一次 /improve-codebase-architecture。
它会扫描代码库，找出可以加深模块、收紧接口、降低耦合的机会，然后生成一个可视化 HTML 报告。你选中一个点之后，它会继续拉你进入 grill 流程。
这就形成了一个闭环：
上线后的代码问题 -> 新的设计问题 -> grill -> PRD/issue -> 实现 -> 再回头检查
这也是这套 skills 和普通“命令合集”的区别。
它不是一堆互不相干的小工具，而是在模拟一个工程团队的基本工作方式：先对齐，再拆分，再实现，再复盘。
番外：/teach 把我的学习方式重构了
主流程之外，还有一个 skill 让我没想到：/teach。
它解决的不是"怎么做项目"，而是"怎么学"。
我的学习路径大概经历了三个阶段：
- 最早看文档。白皮书、官方 spec，翻到第三章开始走神，翻到第五章已经忘了第一章讲啥。
- 后来有了大模型，不懂的概念丢给 ChatGPT 追问，比啃文档快。但有个前提——你得自己想到下一个问题，你不知道自己不知道什么，关键盲区很容易漏掉。本质还是你在驾驭节奏。
- 现在用
/teach，主动权反转了。
我跟它说"teach me agent fundamentals"，它先问你为什么学、当前什么水平、学习目标。然后它自己规划课程大纲，自己检索资源，生成课件，一课一课往下推。
是它在引导你，不是你在驾驭它。
有个细节让我觉得它真的在做"定制课程"而不是"通用模板"：演示视频里有人说想学法语，是因为要去见妻子的法国亲戚。AI 问完背景之后，第一课直接教"怎么问候亲戚"，还顺手讲了贴面礼。
不是从字母表开始的通用课程。是从你真实的场景倒推的课。
另一个让我觉得很对的设计：它在本地生成学习记录，你学到哪了、哪些答对了、哪些答错了，都存着。你清空对话再回来，它读一下文件就知道你上次学到哪，接着往下。
（这套逻辑和 grill 沉淀 CONTEXT.md 是同一个思路：上下文不丢，每次不用重新介绍自己。）
每天二十分钟跟它过一课，比对着文档硬啃两小时效率高太多。而且不限于技术——学语言、乐理、任何需要系统推进的东西都能用。
我为什么喜欢这套 skills？
我喜欢它，不是因为每个 skill 都很复杂。
恰好相反，很多 skill 的内容都很短。甚至有些就是几句话，告诉 Agent 在这个场景下该坚持什么纪律。
但这反而是它最值得学的地方。
好的 skill 不一定要写成小论文。它应该像一个工程师贴在屏幕边上的提醒：
- 先问清楚，不要急着写。
- 先复现 bug，不要直接猜。
- 先写失败测试，不要先堆实现。
- 先明确领域词汇，不要每次重新解释。
- 先把模块边界想清楚，不要让 Agent 把复杂性摊得到处都是。
这些都不是 AI 时代才出现的新道理。
它们本来就是软件工程里的老道理。只是在 Agent 写代码越来越快之后，这些老道理更重要了。
如果你要开始用，按这个顺序来
我建议不要一上来装完所有东西就乱试。
可以按这个顺序：
- 先安装：
npx skills@latest add mattpocock/skills
- 在项目里先跑一次：
/setup-matt-pocock-skills
它会配置 issue tracker、triage 标签、文档路径这些基础信息。
- 日常不知道用什么时，先用：
/ask-matt
- 有新功能或新模块时，优先进入：
/grill-with-docs
- 聊清楚之后，再用：
/to-prd
/to-issues
真正写代码时，把
tdd、diagnosing-bugs、codebase-design当成底层纪律。项目跑一段时间后，用：
/improve-codebase-architecture
回头清理结构债。
它不是银弹
这套 skills 也不是装上之后，Agent 就会自动变成高级工程师。
它更像一组轻量护栏。
你还是要参与判断，还是要 review，还是要决定什么东西值得写，什么东西应该删掉。
但它的价值在于：它把很多“资深工程师脑子里的隐性流程”，变成了 Agent 可以反复执行的工作流。
这正是我觉得它值得读的原因。
你不只是下载一套 skills。你是在读一个工程师如何和 AI 一起工作的痕迹。
如果你也在用 Claude Code、Codex 或其他 coding agent，我建议至少读一遍这个 repo。哪怕你不直接使用，也可以把里面的思路拆出来，改成自己的团队工作流。
Agent 不缺写代码的能力。它更缺的是边界、反馈和纪律。
Matt 这套 skills 做的，就是把这些东西补回来。
总结
这次 v1 最值得看的变化，不是多了几个命令，而是结构更清楚了：
ask-matt负责降低入口选择成本。grill-me和grill-with-docs负责先把问题想清楚。to-prd和to-issues负责把共识固化成可执行任务（后者直接在 GitHub 上创建 issue，不是本地文件）。tdd和diagnosing-bugs负责给实现加反馈循环。domain-modeling和codebase-design负责统一语言和模块设计。improve-codebase-architecture负责让项目持续回到可维护状态。teach负责另一个维度：让 AI 主动规划课程、引导你学，而不是你不停地问它。
如果只记一句话：
这套 skills 不是让 Agent 替你思考，而是逼你和 Agent 一起把工程流程走完整。
你现在用 coding agent 时，最容易失控的是哪一步？是需求没对齐、任务拆不细，还是代码写完之后没人回头看结构？