2026 年 4 月底，Total TypeScript 创始人、TypeScript 社区教父级人物 Matt Pocock 干了一件挺简单的事——把他个人 .claude 目录下的全部 Agent Skills 开源了。仓库叫 mattpocock/skills，副标题只有一句话：Skills for Real Engineers。一个多月时间从 0 涨到 7.2 万 Star，本周还在每天涨 1500+。我把 18 个 Skill 一个一个翻完之后的判断是：这不是又一组炫技 prompt，不是让 Agent "更会自由发挥"的插件包，而是一套专门给 AI 编程踩刹车的工程流程。 如果你现在用 Claude Code、Codex、Cursor 经常觉得 AI 写代码"看起来很快、合起来很虚"，这篇值得花 15 分钟。

---

一、先讲清楚 Matt Pocock 是谁，以及他为什么有资格写这个

英文世界做 TypeScript 教学的人有不少，但能形成"事实标准"的就一个 Matt Pocock。

他全职运营 Total TypeScript ，一套被全球数万名开发者追捧的 TypeScript 系统课程，定价不便宜（一套近 $1000）但常年卖爆。他做过 Vercel、做过 Stately，离开大厂之后专心做教育。在他的影响力下，"shoehorn 优于 as"这种业界细节都变成了一种品味。

他这次做的事很反常——把自己电脑里 ~/.claude/skills/ 目录原样 push 到 GitHub。没有重新包装、没有改名、没有为开源做美化，就是平时他自己每天用的那套东西。

这一点很关键，因为它直接定义了这个仓库的定位：

“Skills I actually use every day, on real engineering work. Not vibe coding.”

翻译过来：我每天都在用，干的是真活，不是写着玩。

这一句话筛掉了 80% 的 prompt 项目——它们多数是"我设计的"，不是"我用的"。

---

二、它解决了 AI 编程的 4 个失败模式

仓库 README 第一屏没有讲"我多牛"，只列了一张表——“AI 编程的 4 种典型翻车场景，每一种我用哪个 Skill 救”。

#	翻车场景	根因	救它的 Skill
1	Agent 干的不是你想要的	对齐缺失	/grill-me /grill-with-docs
2	Agent 啰嗦到读不下去	没有共享语言	/grill-with-docs（写 CONTEXT.md + ADR）
3	代码跑不起来	反馈循环缺失	/tdd /diagnose
4	项目一坨泥球	架构腐化	/to-prd /zoom-out /improve-codebase-architecture

这张表本身就是这个项目最值钱的部分。

它隐含了一个反直觉的判断——AI 编程的瓶颈不是模型能力，是工程纪律。

更准确地说，是资深工程师 80% 的工作量没在敲键盘——在"决定不写哪些代码"、“挑战需求假设”、“拒绝走捷径”。这些"决策习惯"恰恰是 AI Agent 默认会跳过的部分。Matt 做的事就是——把这套"决策习惯"显式编码成 SKILL.md，让 Agent 强制执行。

---

三、18 个 Skill 全景图

仓库目录结构很克制，按使用频率分三类：

skills/
├── engineering/      # 10 个，日常代码工作必用
├── productivity/     # 4 个，通用工作流工具
└── misc/             # 4 个，偶尔派上用场

下面是完整清单，建议先收藏这张表，后面每个细节都跟着这张表走：

🔧 Engineering（10 个 · 工程纪律）

Skill	一句话
diagnose	硬 bug 闭环：复现 → 最小化 → 假设 → 插桩 → 修复 → 回归
grill-with-docs	挑战式追问，同步更新 CONTEXT.md + ADR
triage	用状态机角色给 issue 分类
improve-codebase-architecture	基于 ADR 寻找架构深化机会
setup-matt-pocock-skills	首次使用的初始化（issue tracker、标签、文档结构）
tdd	红-绿-重构，垂直切片严禁水平
to-issues	把任意计划/PRD 拆成可独立认领的 GitHub issue
to-prd	把当前对话直接转成 PRD 并提 issue
zoom-out	强制 agent 抽离细节回到高层视角
prototype	一次性原型（终端 app 或多 UI 变体）

⚡ Productivity（4 个 · 通用工作流）

Skill	一句话
caveman	超压缩通信模式，砍掉 ~75% token
grill-me	持续追问你的计划，直到决策树每个分支都清晰
handoff	把当前对话压成交接文档，便于另一个 agent 接力
write-a-skill	用规范结构 + 渐进披露 + 资源捆绑写新 Skill

🧩 Misc（4 个 · 偶用工具）

Skill	一句话
git-guardrails-claude-code	hook 拦截危险 git（push、reset --hard、clean）
migrate-to-shoehorn	把 as 类型断言迁移到 @total-typescript/shoehorn
scaffold-exercises	创建练习目录（sections/problems/solutions/explainers）
setup-pre-commit	配 Husky pre-commit hook 全家桶

18 个 Skill 没有一个是"AI 自动生成营销文案"、"AI 自动想点子"那种花活。每一个都对应一道工程师本来就该做、但被 AI 时代偷懒省略的纪律。

这才是为什么这个仓库能涨到 7.2 万 Star。

---

四、4 个最值得拆解的 Skill

18 个全讲会变成流水账。我挑出 4 个最能代表 Matt 设计哲学的细看——这 4 个吃透了，剩下 14 个的味道你自己就能闻出来。

4.1 tdd：把"红绿重构"从节奏升级为纪律

Matt 这个 Skill 对 TDD 的定义跟教科书有一处关键差别——强烈反对水平切片。

❌ 错误（水平切片 / 教科书常见）：
  RED:   test1, test2, test3, test4, test5
  GREEN: impl1, impl2, impl3, impl4, impl5

✅ 正确（垂直切片 / 曳光弹）：
  RED→GREEN: test1 → impl1
  RED→GREEN: test2 → impl2
  RED→GREEN: test3 → impl3

为什么这个差别要命？

Matt 在 SKILL 里直接列了水平切片的四个罪状：

1. 批量写测试 = 测试想象中的行为，不是真实行为
2. 测的是函数签名的"形状"，不是用户可见的行为
3. 测试对真实变化变得不敏感——行为坏了反而通过，行为正常反而失败
4. 在理解实现前就锁定了测试结构——后面想改也改不动

这一段我读完之后回头看自己过去几个项目的测试——几乎全中招。AI 帮我们写测试时尤其容易这样：你说"帮我写测试覆盖这个 module"，它哗哗一口气写完 8 个 test()，看起来覆盖率很高，但每一个都是"长得像测试的占位符"。

Matt 的解法是把 TDD 拆成 4 个铁律：

铁律 1：规划阶段必须先跟用户对齐

• 公开接口长什么样？
• 哪些行为最重要？
• 不能测试所有东西——必须选

铁律 2：曳光弹先打一发

• 写一个测试，证明端到端路径走得通
• 不是"先搭脚手架"，是"先打通一条路"

铁律 3：每个循环只走一步

• 一次一个测试
• 只写刚好够通过当前测试的代码
• 不要预测未来的测试
• 测试只描述"可观察的行为"，不描述"内部实现"

铁律 4：绝不在 RED 状态下重构

• 测试还红的时候只能改实现让它变绿
• 重构必须等所有测试都绿
• 重构后每一步都跑测试

这四条加起来其实在说一件事——让上一步学到的东西指导下一步。这是真正的"增量式开发"，而不是"批量计划 + 批量执行"的瀑布伪装。

---

4.2 grill-me：用 70 个英文单词定义一种"对抗式协作"

这个 Skill 的完整正文我数了下——只有 3 句话、70 个单词。

Interview me relentlessly about every aspect of this plan
until we reach a shared understanding. Walk down each branch
of the design tree, resolving dependencies between decisions
one-by-one. For each question, provide your recommended answer.

Ask the questions one at a time.

If a question can be answered by exploring the codebase,
explore the codebase instead.

但这 70 个词每一个都不可替换。我把它拆开看：

关键词	作用
Interview me relentlessly	角色反转——AI 从"顺从助手"变成"挑剔面试官"
relentlessly（不留情面）	单个副词压制了 AI 的礼貌性放水
Walk down each branch of the design tree	给一个明确的算法框架——深度优先遍历
provide your recommended answer	强制 AI 先承诺立场——把"审问"升级为"对撞"
one at a time	节奏锁，防止 LLM 一次抛 10 个问题信息过载
explore the codebase instead	防止"懒惰式审问"——能自己查的事别甩给用户

这是 prompt 工程的一个范本级别作品。

很多人写 prompt 喜欢堆形容词：“请你认真严谨细致全面地……” Matt 这里反过来——用最少的词数定义一种明确的对话关系结构。

我把它直接抄进我自己的 .claude/skills/ 里用了一周。每次启动新项目设计前先 /grill me on this plan，它会一棵决策树一棵决策树地把你逼问到地基。最有杀伤力的是 provide your recommended answer 这一句——AI 不能假装中立追问，必须先表态自己的答案，于是你不得不真正去反驳或赞同，整个讨论一下子就深了一档。

很多人花几小时写产品方案，让 grill-me 跑半小时之后，自己都不愿意继续做这个方案了——因为方案没经过反驳，本质上就是一个未经证伪的猜想。这才是这个 Skill 真正解决的问题。

---

4.3 caveman：用单个开关把对话压缩 75%

这个 Skill 处理一个特别现实的问题——Claude 这种模型默认很啰嗦。

普通模式：
"Sure! I'd be happy to help you with that.
The issue you're experiencing is likely caused by..."

翻译：“好的！我很乐意帮你。你遇到的问题可能是由…”

这种回答信息密度极低、token 消耗极高。在长对话里这种"礼貌噪音"加起来能占掉 30-40% 的 context window。

Matt 的解法是写一个开关 Skill。触发词：caveman mode / /caveman / less tokens。

开启之后整个对话风格变成"原始人电报体"：

Caveman 模式：
"Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"

翻译：“auth 中间件有 bug。token 过期检查用了 < 不是 <=。修法：”

caveman 的实现逻辑特别清晰，分删 / 换 / 留三类：

删除类：冠词（a/an/the）、填充词（just/really/basically）、客套话（sure/certainly）、模糊措辞（might be/it seems）、不必要的连接词

替换类：用短同义词（big 替 extensive、fix 替 implement a solution for）；缩写常用术语（DB / auth / config / req / res）；用箭头表达因果（X → Y）

保留类：技术术语精确不变；代码块原样；错误信息精确引用

最聪明的设计在最后——Auto-Clarity Exception（自动清晰例外）：

当遇到以下场景时，自动临时退出 caveman，写完整句子：

• 安全警告
• 不可逆操作确认（如 DROP TABLE）
• 多步骤序列（片段顺序可能被误读）
• 用户要求澄清或重复提问

完成后立即恢复 caveman。

这一条价值千金。它体现的是Matt 对"工程效率"和"工程安全"边界的精确判断——你可以省钱省 token，但不能用省钱赌一次 rm -rf。

整个 Skill 的核心哲学是一句话：

“Smart Caveman: not stupid, just civilized rhetoric removed. Same information density, way less token cost.”

不是变蠢，是去掉文明世界的修辞。信息密度不变，token 成本骤降。

我自己 caveman 跑了一周后回头看普通模式的对话——突然觉得 95% 的话都是废话。这是这个 Skill 给你的副作用，比省 token 更值钱。

---

4.4 to-prd + to-issues：把对话当作 PRD 的草稿

这两个 Skill 通常成对出现，是 Matt 整套工作流里最反 AI 直觉的一对。

普通 AI 编程流是怎么样的？

讨论需求 → AI 直接写代码 → 跑通 → 提交

Matt 的流是这样的：

讨论需求
  → /to-prd（把对话沉淀成 PRD 文档，提到 GitHub issue）
  → /to-issues（把 PRD 拆成 N 个可独立认领的 sub-issue）
  → 每个 sub-issue 单独开 PR
  → /tdd 红绿重构走完
  → /grill-with-docs 把决策落到 CONTEXT.md + ADR
  → 合并

这一套流让我很久没看到过的术语都回来了——PRD、ADR、可独立认领的工单。这些是十年前互联网公司的基本功，AI 时代被"反正能跑就行"冲垮了。

Matt 用一个简单的逻辑把它们捞回来——

“如果你不能把这次对话写成 PRD，你其实没想清楚要做什么。”

to-prd 这个 Skill 在做的事就是强制你"说人话"——把"哎我们做个 X 吧"那种模糊讨论，转换成一份带需求边界、验收标准、技术约束的文档。

最妙的是它默认会把这份 PRD 提到 GitHub issue。一旦提了 issue，这个需求就不再属于"AI 对话上下文里那段易失记忆"——它变成了可被引用、可被回溯、可被指派的工作单元。

to-issues 紧跟着把 PRD 拆成更小的可独立认领单元——每个都能给一个工程师（或者一个 AI 实例）单独干。这就把"一次性长对话"变成了"多人/多 Agent 协作"的基础设施。

我看完这一对 Skill 之后停下来想了很久。它们没有用任何高阶 AI 能力，只是把传统软件工程的基本功用 Markdown 重新缝回了 AI 工作流——但这恰恰是最稀缺的事。

---

五、设计哲学：渐进披露 + 触发词机制

把 18 个 Skill 看完之后，再回过头看 Matt 怎么"组织"这些 Skill，会发现他用了 Anthropic 官方 Agent Skills 规范 的两个核心思想：

5.1 渐进披露（Progressive Disclosure）

每个 Skill 的 SKILL.md 都遵循同样的结构：

---
name: tdd
description: Test-driven development with red-green-refactor loop.
  Use when user wants to build features or fix bugs using TDD,
  mentions "red-green-refactor", wants integration tests,
  or asks for test-first development.
---

# 核心规则（短）

# 关联资源（按需召回）
- tests.md
- mocking.md
- deep-modules.md
- interface-design.md
- refactoring.md

核心规则在主文件里、深入细节散布在多个 .md 资源里——只有 Agent 真的需要某个细节时才会去读对应的 .md。

这个设计解决了一个特别现实的痛点——Skill 写太长会浪费 context，写太短又不够指导。渐进披露让"长度"变成"按需消费"的，主文件保持精简，深入细节按需召回。

5.2 触发词机制

注意每个 Skill 的 description 字段——

Use when user wants to build features or fix bugs using TDD,
mentions "red-green-refactor", wants integration tests,
or asks for test-first development.

这一段不是给人看的，是给路由 Agent 看的——它列出了一组"什么时候召唤我"的触发条件。这意味着用户不需要记住每个 Skill 的名字，只要说一句**“我要红绿重构"或"测试先行”**，对应的 tdd Skill 就会自动加载。

这是 Matt 整套 Skills 能"形成系统"而不是"散文件堆"的关键设计——每个 Skill 都知道自己什么时候该出场，而不是等用户手动调用。

---

六、和市面其他 Skills 集合的差异

最近一两个月类似的项目突然变多了。我把 Matt 这套和另外两个高 Star 项目放在一起对比：

项目	Star	主导设计	风格
addyosmani/agent-skills（Google Director Addy Osmani）	32k+	22 个 Skill × 7 slash × 6 阶段生命周期	重型工业，完整 SDLC
mattpocock/skills（Matt Pocock）	72k+	18 个 Skill × 触发词机制 × 渐进披露	轻量纪律，对单人开发者最友好
tech-leads-club/agent-skills	~5k	安全审核的 Skill 注册表	企业治理向

Osmani 那套是给团队用的——把整个交付生命周期切成 6 阶段、每阶段绑定固定 Skill。结构严谨但学习成本高。

Matt 这套是单人独立开发者的实战路径——你不需要从 DEFINE 走到 SHIP 全套流程，你今天想 grill 就用 grill-me、想 TDD 就用 tdd、想压 token 就用 caveman。每个 Skill 都能独立工作、也能任意组合。

这就是它跑得更快的原因——对独立开发者门槛低、对工程师吸引力强、对 Claude Code / Cursor / Codex 用户立刻能落地。

---

七、几个我立刻在用的组合

理论讲完，给点能立刻用的招。这是我自己用了两周的几个组合，亲测有效：

组合 1：新需求启动三连击

1. /grill-me        # 先把方案逼问到决策树叶子节点
2. /to-prd          # 把对话沉淀成 PRD 提交 GitHub issue
3. /to-issues       # 把 PRD 拆成可独立认领的 sub-issue

效果：从"哎要不要做个 X"到"3 个可独立开 PR 的 issue 已经在 GitHub 上"——半小时搞定。

组合 2：写复杂功能的两步走

1. /tdd             # 垂直切片，曳光弹打第一发
2. /grill-with-docs # 决策完成后落进 CONTEXT.md + ADR

效果：代码写完的同时，架构决策已经被文档化——下次别人接手不需要再问"为什么当初这么设计"。

组合 3：长会话治理

1. /caveman          # 全程压缩 token
2. /zoom-out         # 困住了让 Agent 跳出当前细节
3. /handoff          # 真没时间写完，压成交接文档传给另一个 agent

效果：在 100k+ 的对话窗口里也能保持清醒——这是 Matt 处理长任务的核心心法。

组合 4：代码救火

1. /diagnose        # 复现 → 最小化 → 假设 → 插桩 → 修复 → 回归

这一个 Skill 把 bug 修复变成了纪律化的 6 步流程。最关键的是"最小化"——多数人遇到 bug 直接开始猜，Matt 的逻辑是先把 bug 缩小到最小复现单元再开始猜。这一步省掉的时间，比 AI 写代码本身省的都多。

---

八、So What——给读到这里的你 3 个判断

读完之后我自己沉淀了 3 个判断，给你做参考：

判断 1：AI 编程进入"工程纪律"时代

过去一年 AI 编程的玩法是"如何把 prompt 写得更骚"。今年开始变了。

mattpocock/skills、addyosmani/agent-skills、humanlayer/12-factor-agents、tech-leads-club/agent-skills——这一批同期爆红的项目都在做同一件事：把工程基本功（TDD、PRD、ADR、Code Review、Architecture Decision）重新封装成 Agent 能消费的格式。

这意味着模型层卷不动了，工程纪律层在崛起。下一波竞争的赢家不是"谁的模型最聪明"，是"谁能把工程师的隐性知识显性化、可复用、可分发"。

判断 2：Skills 是新的"开源资产"

GitHub 上现在最值钱的项目类型变了——不是新框架，是 Skills 集合。

Matt Pocock 这套之所以涨得这么快，本质是他把自己作为 TypeScript 教父几十年工程经验、几万小时的真实工作 pattern，全部压缩进了 18 个 Markdown 文件里、免费给了所有人。这是单人工程师能产生的最大杠杆——一个人的纪律，通过 Skill 被 100 万人复用。

对个人来说，"你的 ~/.claude/skills/ 目录"开始变成一种履历。

判断 3：你现在该做的第一件事

不需要全套 18 个都装。今天就装这 3 个：

npx skills@latest add mattpocock/skills

# 然后只激活这三个：
/grill-me           # 任何新需求开始前都跑一遍
/tdd                # 任何"写功能/修 bug"任务都用这个
/caveman            # 长对话默认开

跑一周。如果一周后你还想关掉，再来 GitHub 上 unstar 也来得及。

---

九、最后

这个项目最让我停下来想的，不是 18 个 Skill 写得多好——

是 Matt Pocock 这种级别的人，把自己每天用的工具原样开源。没有商业化、没有改写美化、没有付费版。

“These are the skills I actually use. Take them. Modify them. Make them your own.”

这种"工具不应该藏在自己 .claude/ 目录里"的态度，可能比任何一个 Skill 都重要。

如果你最近也在攒 prompt、攒 skills、攒自己的 .claude/ 目录——

可以考虑跟 Matt 学一招：把它 push 上 GitHub。

---

原仓库：https://github.com/mattpocock/skills
新闻订阅：https://www.aihero.dev/s/skills-newsletter （6 万订阅，Matt 每周一封）
Skills CLI：https://skills.sh/mattpocock/skills

---