TypeScript 社区知名开发者 Matt Pocock 把自己用了一年多的 AI 工程师工具包开源了。一天涨了 7,000+ Stars，不是靠话题噱头，而是因为它踩的坑每个人都踩过。
Matt Pocock 不是那种泡在 AI 社区刷存在感的人。他在 TypeScript 圈子里干了很多年，Total TypeScript 是当前最受欢迎的 TypeScript 进阶学习平台之一，订阅人数超过 6 万。他的受众基本都是写真实项目的工程师，不是玩具代码选手。
所以当他把自己 .claude 目录里的工具包开源，说"这是我每天用的东西"，你大概可以相信他不是在吹牛。
这个项目的出发点很直接：AI 助手会加速你写代码，但同时也会加速你制造技术债。写得快不等于写得好。Matt 把自己在过去一年里摸索出的应对套路整理成了一套可复用的 Skills，任何 AI 编程代理都能用。
Matt 在 README 里一开头就点明了他观察到的四种失败模式，这部分是整个项目最有价值的地方——不是因为结论新鲜，而是因为说清楚了。
引用了《程序员修炼之道》里的一句话："没有人确切知道自己想要什么。" Agent 只会按你说的去做，你说的话又往往不够精确。双重不确定性叠在一起，跑出来的东西经常和你想的是两件事。
解法是在开始写代码之前先做一轮"审问"——/grill-me 和 /grill-with-docs 就是干这个的。
每次跟 Agent 交流，它都得从零理解你的项目语境。术语不统一，它就会用 20 个词解释一个词的意思。而且每多描述一次，token 就多烧一次。
解法是建立共享语言文档（CONTEXT.md），把项目里的核心概念、术语约定记下来，Agent 加载这个文件就不用每次都重新解释。
AI 生成代码速度很快，但没有运行反馈它就是在盲飞。你让它改一个 bug，它改了，但你不知道它的修改逻辑对不对，下一个 bug 照样冒出来。
解法是把测试驱动开发（TDD）塞进工作流，/tdd 技能强制执行红-绿-重构循环，每次只处理一个垂直切片。
以前代码腐化是一个月、一个季度的事。有了 AI 助手，你一天就能把代码库写成一团乱麻，因为生成速度快，但结构考虑少。
解法是定期用 /improve-codebase-architecture 审视代码库，找出深化机会，而不是等到重构无可避免再动手。
项目分三类：Engineering（工程技能）、Productivity（生产力）和 Misc（杂项）。下面按实际使用频率排列。
最常用的一个。开始写代码之前先用这个审问你的计划，同时检查现有的领域模型，优化术语，然后实时更新 CONTEXT.md 和 ADR（架构决策记录）。
测试驱动开发。红-绿-重构循环，每次只做一个垂直切片。不是那种"写完代码再补测试"的假 TDD，是真的先写测试。
调试 bug 用的系统化流程：复现 → 最小化 → 假设 → 探测 → 修复 → 回归测试。对难以定位的 bug 和性能回归有用。
扫描代码库，找出结构弱点，建议每隔几天跑一次，不要等代码彻底腐化再用。
让 Agent 退一步，从系统整体视角解释当前代码的位置，适合接手新代码库或几天没看某个模块时使用。
把当前对话上下文转成 PRD 并作为 GitHub Issue 提交，省掉重复填写需求文档的功夫。
把任何计划或 PRD 拆成独立可处理的 GitHub Issues，用垂直切片方法，适合一个人或小团队管理任务。
用基于标签的状态机对 GitHub Issues 做分类处理，适合 issue 数量开始失控时使用。
超压缩通信模式。删掉所有填充词，保留技术准确性，能把 token 使用量压低约 75%。长时间使用 AI 编程代理的人会很有感触。
纯粹的需求审问，适合非代码场景。反复追问，把计划的每个分支都逼出来。
创建自定义 Skill 的模板工具，教你怎么组织 Skill 的结构、渐进式披露和资源捆绑。
在危险 git 命令执行前拦截，比如 push、reset --hard、clean 等。如果你用 AI 代理管过 git，你懂的。
自动配置 Husky pre-commit hooks，包含 lint-staged、Prettier、类型检查和测试。
把测试文件里的 as 类型断言迁移到 @total-typescript/shoehorn，TypeScript 专用工具。
安装方式比大多数工具省事。一条命令，交互式选择你要的 Skill 和目标代理：
# 安装命令
npx skills@latest add mattpocock/skills
# 运行后会进入交互界面：
# 1. 选择要安装的 Skills（可多选）
# 2. 选择安装到哪个 AI 代理（Claude Code / Cursor / Copilot 等）
# 3. 确认，完成安装完成后，在 Claude Code 或其他支持的代理中直接用斜杠命令触发：
# 开始一个新功能前，先审问需求
/grill-with-docs
# 开始写代码，用 TDD 模式
/tdd
# 调试难搞的 bug
/diagnose
# 每隔几天跑一次，检查代码架构
/improve-codebase-architecture
# 节省 token 的通信模式
/caveman/grill-me 和 /tdd，这两个是使用频率最高的。/caveman 适合你已经熟悉项目后用，前期可以先不开。整个技能库里最有意思的概念不是某个具体的 Skill，而是"共享语言"这个思路。
问题背景：AI 代理每次对话都是从零开始的，你项目里的领域术语它不知道，每次都要重新解释。你说"materialization cascade"，它不懂，就得用一整段话描述同样的东西。
解法是维护一个 CONTEXT.md，把你项目里的核心术语、概念、约定记下来，Agent 加载这个文件之后就有了项目语境。
下面是一个 CONTEXT.md 的示例，来自 Matt 的实际案例：
# 项目语言约定（CONTEXT.md）
## 核心概念
materialization cascade: 当课程中的课时被标记为"真实"（即分配了
文件系统位置）时，触发的一系列衍生更新操作。
lesson: 课程中的单个学习单元，包含视频、练习和解答三个子元素。
section: 包含多个 lesson 的分组容器，对应课程大纲的一级目录。
## 代码约定
- 所有 section 使用 kebab-case 命名
- lesson 文件结构：problem.ts / solution.ts / explainer.md
- 测试文件命名：*.test.ts，使用 vitest"优化前：'当课程部分中的课时被标记为真实时出现问题'
优化后：'materialization cascade 问题'"
— Matt Pocock，README 里的真实案例
效果很实在：沟通更精确，变量命名更统一，烧掉的 token 更少。对于一个长期维护的项目，这个文件会随着项目成长慢慢变成一份活文档。
ADR（架构决策记录）是另一个相关实践。/grill-with-docs 会在审问结束后自动更新 docs/adr/ 里的决策记录，帮你追踪"我们当时为什么这么决定"。
GitHub 上的 Claude Code Skills 项目不少，下面和几个常见的对比一下：
| 项目 | 定位 | Skills 数量 | 工程实践深度 | 模型支持 | 维护状态 |
|---|---|---|---|---|---|
| mattpocock/skills | 真实工程工作流 | 14 | ★★★★★ | 任意代理 | 活跃 |
| awesome-claude-code-skills | Skills 策展合集 | 30+ | ★★★☆☆ | Claude Code | 一般 |
| superpowers | MCP + 工程强化 | 20+ | ★★★★☆ | Claude Code | 活跃 |
| ComposioHQ/awesome-codex-skills | Codex CLI 工作流 | ~30 | ★★★☆☆ | Codex | 新发布 |
| 自定义 CLAUDE.md | 项目级指令 | 无限 | ★★★★☆ | Claude Code | 自维护 |
mattpocock/skills 最显著的区别有两点：一是每个 Skill 都有明确的问题背景和工程理由，不是凑数的；二是设计上刻意保持"模型无关"，不绑定 Claude Code，Cursor、Copilot 或者任何未来出现的代理都能用。
一个人或小团队维护复杂 TypeScript/JavaScript 项目的。 核心 Skills 设计出发点就是这个场景，尤其是 /grill-with-docs 和 CONTEXT.md 那套，在小团队里价值最明显。
已经在日常工作中重度使用 Claude Code 的开发者。 如果你每天用 AI 代理写代码超过 2 小时，token 成本和上下文质量的问题会越来越突出，这个项目能直接改善这两点。
正在研究怎么让 AI 辅助开发更"工程化"的人。 即使不直接用这些 Skills，把 README 认真读一遍也值。Matt 对 AI 编程失败模式的分析比大多数博客文章都实在。
如果你的工作主要是探索性的原型开发、一次性脚本或者数据分析，这套严格的工程化工作流可能有点重。/tdd 和 /improve-codebase-architecture 的价值在长期维护的代码库上才真正显现。
另外，/migrate-to-shoehorn 这个 Skill 明显是 Matt 为自己的 TypeScript 工具链写的，如果你不用他的那套库，这个 Skill 对你没什么用。
/grill-me，用一周，感受一下在写代码之前先审问需求的效果。如果觉得有用，再装 /tdd 和 /grill-with-docs。不用一次全装。