Matt Pocock skills 新手完整教程
适用场景：Claude Code、Cursor、Codex 等支持 skills 的 coding agent 目标：让 AI 先理解问题，再设计方案，最后实现代码，避免直接让 AI “猜需求 + 写代码”。
很多新手第一次使用 mattpocock/skills 会误解：
“是不是安装后，每次开发都把所有 skill 依次执行？”
答案：不是。
它不是一个固定流水线，而是一组工程辅助工具。
正确理念：
小任务 → 直接处理
中型功能 → 思考 → 规范 → 实现
大型功能 → 思考 → 规范 → 拆任务 → 实现
不确定 → 先探索
第一章：安装前准备
1. 安装 Claude Code（示例）
如果你使用 Claude Code：
安装 Node.js：
node -v
确认 Node 已安装。
安装 Claude Code：
npm install -g @anthropic-ai/claude-code
启动：
claude
2. 进入你的项目目录
例如：
cd my-project
确认这是代码仓库：
ls
应该看到类似：
package.json
src/
README.md
.git/
第二章：安装 mattpocock/skills
方法一：使用 npx skills（推荐）
在项目目录执行：
npx skills@latest add mattpocock/skills
安装过程中会让你选择技能。
推荐安装：
setup-matt-pocock-skills
ask-matt
grill-with-docs
to-spec
to-tickets
implement
tdd
code-review
diagnosing-bugs
wayfinder
handoff
triage
方法二：只安装需要的 skill
例如：
只安装初始化：
npx skills@latest add mattpocock/skills \
--skill=setup-matt-pocock-skills
只安装实现：
npx skills@latest add mattpocock/skills \
--skill=implement
第三章：第一次使用必须执行 setup 吗？
是，但只需要一次。
进入项目：
claude
执行：
/setup-matt-pocock-skills
它不是每天执行。
它的作用类似：
告诉 AI：“这个项目怎么管理需求、文档和任务。”
它会询问：
例如：
Issue 放哪里？
选择：
GitHub Issues
GitLab Issues
Markdown 文件
其他系统
项目文档在哪里？
例如：
docs/
标签如何管理？
例如：
bug
feature
needs-info
ready-for-agent
初始化后通常会生成：
docs/
└── agents/
├── issue-tracker.md
├── triage-labels.md
└── domain.md
以后：
- 修改项目规则
- 修改领域知识
直接编辑这些文件即可。
不用重新：
/setup-matt-pocock-skills
第四章：理解每个 Skill 的作用
先记住：
| Skill | 作用 |
|---|---|
| setup | 初始化项目环境 |
| grill-with-docs | 深入讨论需求 |
| to-spec | 生成正式设计文档 |
| to-tickets | 拆任务 |
| implement | 执行开发 |
| tdd | 测试驱动开发 |
| diagnosing-bugs | 排查 Bug |
| wayfinder | 探索大型未知项目 |
| triage | 管理 Issue |
| handoff | 跨会话交接 |
| ask-matt | 不知道下一步问它 |
第五章：标准开发流程
场景：
你想新增：
后台 CSV 批量导入用户功能
第一步：不要马上 implement
错误：
/implement
帮我做 CSV 导入
为什么？
因为 AI 不知道：
- CSV 格式？
- 错误如何处理？
- 权限？
- 数据库策略？
- 是否允许部分成功？
第二步：描述目标
告诉 AI：
例如：
我想给后台增加 CSV 批量导入用户功能。
管理员上传 CSV。
每行包含：
email
name
department
role
有效用户导入。
失败用户记录原因。
最后返回成功和失败统计。
第三步：需求讨论
执行：
/grill-with-docs
AI 会开始提问：
例如：
重复邮箱怎么办？
A 覆盖
B 跳过
C 报错
你回答：
跳过，并记录原因。
继续：
角色不存在怎么办？
回答：
该行失败，但其他用户继续导入。
这个阶段目标：
不是写代码。
而是确定：
业务规则
异常情况
技术边界
术语定义
第六章：生成 Spec
需求明确后：
执行：
/to-spec
生成：
例如：
docs/specs/user-import.md
里面包含：
功能目标
管理员可以批量导入用户。
用户行为
上传 CSV。
系统验证。
返回结果。
决策
重复邮箱：
跳过。
无效角色：
失败。
测试方式
测试：
ImportUsersService.import()
而不是：
parseCSV()
validateEmail()
为什么？
因为测试应该关注：
用户能看到什么结果
而不是：
内部代码怎么实现
第七章：什么时候需要拆 Tickets？
如果功能很小：
直接：
/spec
↓
implement
即可。
如果很大：
执行：
/to-tickets
例如拆成：
Ticket 1
完成最小流程：
上传 CSV
一个用户成功导入
返回成功结果
Ticket 2
增加：
错误行收集
Ticket 3
增加：
重复用户处理
Ticket 4
增加：
权限控制
好的 ticket：
完成后可以展示一个完整用户价值。
坏的 ticket：
创建数据库表
开发 API
写前端
写测试
这是按技术层拆，不推荐。
第八章：开始实现
执行：
/implement
或者：
/implement issue #123
它负责：
读取 spec
读取 ticket
写代码
运行测试
检查类型
修复问题
提交修改
注意：
implement 不是产品经理。
它不会替你决定：
- 需求是什么
- 架构方向
- 业务规则
这些应该提前确定。
第九章：TDD 怎么使用？
TDD：
/tdd
核心：
不是：
先写100个测试
再写代码
而是：
循环：
失败测试
↓
最少代码通过
↓
重构
↓
下一条测试
例如：
第一个循环
测试：
一个有效用户可以导入
代码通过。
第二个循环：
测试：
错误邮箱应该失败
代码通过。
第三个循环：
测试：
失败用户不能影响其他用户
代码通过。
第十章：Bug 怎么处理？
不要：
/implement
修一下这个 bug
如果原因不明。
应该：
/diagnosing-bugs
流程：
复现
↓
缩小范围
↓
提出假设
↓
验证
↓
修复
↓
增加回归测试
第十一章：大型项目怎么办？
如果你不知道：
- 怎么拆
- 技术路线是什么
- 架构怎么设计
不要直接：
/to-spec
先：
/wayfinder
它帮助：
发现未知问题
↓
建立路线图
↓
明确决策
↓
进入 spec
第十二章：跨会话继续开发
聊天太长：
执行：
/handoff
例如：
/handoff 下一次继续完成用户导入功能
它生成交接信息：
包含：
当前状态
已经完成
未完成任务
下一步建议
新会话读取即可继续。
第十三章：不知道下一步怎么办？
使用：
/ask-matt
例如：
我已经讨论完需求，
但是还没有写 spec。
下一步应该使用哪个 skill？
第十四章：新手最推荐的使用模板
小修改
例如：
改按钮文字：
直接修改
小 Bug
/diagnosing-bugs
中型功能
推荐：
/grill-with-docs
/to-spec
/implement
大型功能
推荐：
/grill-with-docs
/to-spec
/to-tickets
/implement
超大型项目
推荐：
/wayfinder
↓
/to-spec
↓
/to-tickets
↓
/implement
最后记忆口诀
不知道做什么？
→ grill-with-docs
知道需求，要写方案？
→ to-spec
方案太大？
→ to-tickets
方案确定，要写代码？
→ implement
测试优先？
→ tdd
不知道路线？
→ wayfinder
不知道选哪个？
→ ask-matt
最重要的一条：
不要让 AI 同时负责“想清楚做什么”和“怎么写代码”。
mattpocock/skills 的核心思想就是：
人和 AI 一起确定方向
↓
文档固定决策
↓
AI 执行实现
这样 AI 才像一个可靠的软件工程助手，而不是一个只会生成代码的聊天机器人。
