mattpocock/skills 深度解析：真实工程师的 AI 编程工作流

这不是一个花哨的多 Agent 编排框架，没有 Party Mode，没有虚拟 23 人团队——而是将软件工程几十年积累的最佳实践，封装为。文件，没有自己的语法、没有插件 API、没有运行时。：坚持几周，它就会成为整个团队（包括人和 Agent）的"行话词典"，之后每个 session 启动 token 立省 30%-50%。一个连"穴居人模式"都开发出来的人，对工程实用主义的关注是写在 DNA

echoy_189

650人浏览 · 2026-05-06 12:16:04

echoy_189 · 2026-05-06 12:16:04 发布

来自真实工程师 .claude 目录的 AI 编程技能集合 | GitHub 55K+ Stars | 2026年3月上线即霸榜 Trending #1

一、项目背景与诞生故事

2026 年 3 月，TypeScript 社区知名讲师 Matt Pocock（Total TypeScript 课程作者）将自己日常在 Claude Code 里使用的 .claude/skills 目录原样推到 GitHub，仓库名为 mattpocock/skills，副标题写着：

"My agent skills that I use every day to do real engineering - not vibe coding."

结果一夜之间冲上 GitHub Trending #1，目前已累计 55,000+ Stars、4,100+ Forks，被翻译进十几种语言的博客，连 Pulumi 官方博客都将它与 GSD、Superpowers 一起进行对比分析。

整个仓库只有 21 个 Markdown 文件，每个文件就是一段写给 Claude Code 的"工程原则提示词"。这不是一个花哨的多 Agent 编排框架，没有 Party Mode，没有虚拟 23 人团队——而是将软件工程几十年积累的最佳实践，封装为小巧、可组合、可适配的 Skill。

💡 核心设计哲学："Approaches like GSD, BMAD, and Spec-Kit try to help by owning the process. But while doing so, they take away your control and make bugs in the process hard to resolve." —— Matt Pocock

二、解决的四大核心痛点

痛点 #1：Agent 没听懂我说啥（Misalignment）

"No-one knows exactly what they want." —— The Pragmatic Programmer

问题根源：最常见的 AI 编程失败模式是对齐偏差。你以为说清楚了，Agent 以为它听懂了，代码生成出来才发现完全跑偏。

解决方案：在写代码前，先让 Agent 反过来"拷问"你。

/grill-me —— 用于非代码类决策
/grill-with-docs —— 代码场景拷问 + 顺手更新领域文档

痛点 #2：Agent 太啰嗦（Verbosity）

"With a ubiquitous language, conversations are all derived from the same domain model." —— Domain-Driven Design

问题根源：Agent 进入项目时不懂团队"行话"，用 20 个词描述一个概念，而你们内部一个词就够了。

解决方案：建立共享领域语言，沉淀到 CONTEXT.md。

优化前	优化后
"There's a problem when a lesson inside a section of a course is made 'real' (i.e. given a spot in the file system)"	"There's a problem with the materialization cascade"

这个 CONTEXT.md 不只减少啰嗦，还让变量名、函数名、文件名自动保持一致，Agent 消耗的 token 也大幅减少。

痛点 #3：代码写出来不 work（Code Quality）

"Always take small, deliberate steps. The rate of feedback is your speed limit." —— The Pragmatic Programmer

问题根源：没有反馈环，Agent 就是闭眼开车。没有类型检查、没有自动化测试、没有浏览器实时验证，模型无法自我校验。

解决方案：

/tdd —— 真正的 Red-Green-Refactor 循环
/diagnose —— 将 reproduce → minimise → hypothesise → instrument → fix → regression-test 固化为 6 阶段调试流程

痛点 #4：项目变成大泥球（Architecture Decay）

"Invest in the design of the system every day." —— Extreme Programming Explained

问题根源：AI 让写代码速度提升 5 倍，也让代码烂掉的速度提升 5 倍。

解决方案：把"关心架构"这件事融入每一层 Skill：

/to-prd 在生成 PRD 前先盘问你影响哪些模块
/zoom-out 强制 Agent 站在整个系统视角解释代码
/improve-codebase-architecture 周期性"修剪"代码库（建议每隔几天跑一次）

三、完整 Skill 清单

Engineering 分类（日常开发主力军）

Skill	定位	何时使用
`grill-with-docs`	拷问需求 + 更新 CONTEXT.md/ADR	每次开始新需求前
`tdd`	强制 Red-Green-Refactor，反对水平切片	写新功能 / 修 Bug
`diagnose`	6 阶段调试方法论，先建反馈环	难复现 Bug、性能回退
`to-prd`	把当前对话凝练成 PRD 并提交 Issue	拷问完成后落地
`to-issues`	把 PRD/计划拆成垂直切片 Issues	PRD 落地后准备并行执行
`triage`	Issue 状态机分类，按 label 流转	接手新 backlog 时
`improve-codebase-architecture`	找加深模块机会，做架构精修	每隔几天、重构周
`zoom-out`	让 Agent 站在系统层面再讲一遍	进入陌生模块时
`setup-matt-pocock-skills`	一次性配置 issue tracker、标签、文档路径	装完 skills 第一次跑

Productivity 分类（通用工作流工具）

Skill	定位	亮点
`caveman`	极简通信模式，token 占用立省约 75%	穴居人模式，砍掉废话只留技术结论
`grill-me`	非代码场景的需求拷问	适用于架构决策、方案讨论
`write-a-skill`	帮你按规范写一个新 Skill	支持渐进式披露结构

Misc 分类（偶尔用一次）

Skill	用途	推荐度
`git-guardrails-claude-code`	拦截 `push --force` / `reset --hard` / `clean -fd` 等危险命令	⭐⭐⭐⭐⭐ 强烈推荐
`migrate-to-shoehorn`	测试断言迁移到 `@total-typescript/shoehorn`	TypeScript 项目专用
`scaffold-exercises`	创建结构化练习题目录	Matt 课程作者自用
`setup-pre-commit`	一键配置 Husky + lint-staged + Prettier + tsc + test	新项目初始化利器

四、三大核心 Skill 深度解析

/tdd —— 真正的测试驱动开发

绝大多数所谓"AI TDD"都是水平切片：先把所有测试写完，然后让 Agent 把所有实现一次性写出来。Matt 直接把这种做法标为 anti-pattern。

正确做法是垂直切片（Tracer Bullet）：

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

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

核心原则：只测公共接口的行为，不要 mock 内部协作者。如果你重命名一个内部函数测试就挂，这个测试本身就是错的。

/diagnose —— 6步调试法

阶段	行动	核心目标
Phase 1	Build Feedback Loop	先建 2 秒内能跑完的 pass/fail 信号
Phase 2	Reproduce	复现率提到 50% 以上再继续
Phase 3	Minimise	最小化复现场景，删除无关变量
Phase 4	Hypothesise	提出可证伪的假设
Phase 5	Instrument	打点验证假设
Phase 6	Fix + Regression Test	修复 + 写回归测试防止复发

💡 最重要的是 Phase 1：一个 2 秒能跑完的确定性 pass/fail 信号，被 Matt 称为"调试超能力"。如果 Bug 不稳定复现，先把复现率提到 50% 以上再继续。

/grill-with-docs —— 需求拷问 + 领域语言

这是仓库里最受欢迎的 Skill，核心价值在于两件事同时完成：

在开始前通过连续追问澄清需求的每个分支
把每次澄清的术语自动 commit 到 CONTEXT.md

CONTEXT.md 的复利效应：坚持几周，它就会成为整个团队（包括人和 Agent）的"行话词典"，之后每个 session 启动 token 立省 30%-50%。

五、安装与首次配置（30 秒上手）

Step 1 —— 一行命令安装

npx skills@latest add mattpocock/skills

推荐至少勾选：setup-matt-pocock-skills、grill-with-docs、tdd、diagnose、to-prd、to-issues、improve-codebase-architecture、git-guardrails-claude-code

Step 2 —— 跑初始化向导（每个仓库执行一次）

/setup-matt-pocock-skills

问题	选项	说明
Issue Tracker 用什么？	GitHub Issues / Linear / 本地文件	影响 `to-issues` 和 `triage` 的行为
`triage` 用什么标签？	自定义标签词典	用于 Issue 状态机分类
领域文档放哪里？	默认 `CONTEXT.md` + `docs/adr/`	共享语言和架构决策存放位置

跑完后仓库里会多出来：

.
├── CONTEXT.md              # 共享领域语言词典
├── docs/
│   └── adr/                # 架构决策记录（ADR）
└── docs/agents/
    └── triage-labels.md    # Issue 标签字典

Step 3 —— 推荐标准打法

/grill-with-docs    # 澄清需求，沉淀领域语言
/to-prd             # 把对话凝结成 PRD 提交 Issue
/to-issues          # 拆成垂直切片 Issue
/tdd                # Red-Green-Refactor 实现
/diagnose           # 遇到难 Bug 切到这个
/zoom-out           # 走进陌生模块时
# 每周跑一次：
/improve-codebase-architecture

六、最佳实战套路（5 个高效用法）

套路 1：grill-with-docs 是省钱第一神器

坚持使用几周，CONTEXT.md 就会成为整个团队的"行话词典"，之后所有 session 启动 token 立省 30%-50%。

套路 2：to-issues 要做垂直切片，不是按文件拆

每个 Issue 应该是端到端可独立验收的最小用户能感知到的改动（比如"在登录页加 GitHub OAuth 按钮"），不是"加一个 OAuth utils 文件"。

套路 3：调试时先建 2 秒反馈环

遇到 Bug 先停下来问：我现在有没有一个能在 2 秒内吐出 pass/fail 的命令？ 没有就先建。

套路 4：每周给项目"修剪"一次

improve-codebase-architecture 设计为周期性使用，每周跑一次，坚持一个季度，项目不会变成大泥球。

套路 5：caveman + git-guardrails 长期开着

caveman 在长任务里能直接砍掉 75% 的 token
git-guardrails 拦住所有"删库跑路"级别的命令，装上忘掉就行

七、横向对比：五大 AI 编程框架

维度	mattpocock/skills	GSD	BMAD-METHOD	Superpowers	Spec-Kit
Star 数	55K+	51K+	—	149K+	—
核心理念	不接管流程，给工程基本功	接管 context window	接管 SDLC，模拟敏捷团队	接管 TDD 纪律	接管 spec→impl 转换
抽象单位	Skill（.md 提示词）	Phase + Slash command	Agent 角色（PM/Arch/Dev…）	orchestrator + 子 agent	Spec 文档
可定制度	极高，一个 .md 一改	中等	受 Agent 角色约束	高	中等
学习成本	🟢 低	🟡 中	🟠 高	🟡 中	🟡 中
适用场景	日常工程，保留控制权	跨天多文件长任务	真正敏捷流程的团队	强 TDD 信仰的单人	需求评审重的企业

框架选型决策指南

长期演进的真实产品（3个月以上）
- 团队人多、需要敏捷流程 → BMAD
- 单人/小团队，要 own 控制权 → mattpocock/skills
- 长任务多文件，怕 context rot → GSD
一次性小项目或学习项目 → mattpocock/skills（入门首推）
强 TDD 信仰 → Superpowers
企业级，需求评审重 → Spec-Kit