Codex + Matt Pocock Skills 实战：别全装，这 13 个 Skill 才是真正的核心

最近在研究 Matt Pocock 的 skills 仓库。

如果只是看 Skill 列表，很容易产生一种冲动：

既然都是工程实践相关 Skill，那干脆全部装上。

但实际用下来，我反而不建议这么做。

尤其是我的主要使用场景是：

css 复制代码

现有项目维护
→ 需求拆解
→ Plan / Spec
→ AI 实现
→ 人工审核
→ AI Code Review
→ 第二次人工审核
→ 人工决定是否提交

核心目标并不是让 Agent 完全接管开发，而是：

把 AI 放进现有软件工程流程，同时保留人工决策权。

所以 Matt Pocock Skills 更合理的使用方式，是按职责拆成三层：

核心安装：13 个
按需安装：6 个
暂时不用：3 个

这篇文章主要分享我目前给 Codex 使用 Matt Pocock Skills 的选择方案，以及最终组合出来的一套 AI Coding 工作流。

一、先说结论：不要把 Skills 当成"大一统开发框架"

Matt Pocock 的 Skills 有一个我比较喜欢的设计思路：

Skill 应该是小型、可组合、可修改的。

也就是说，它更像一组工程能力模块，而不是：

sql 复制代码

输入需求
↓
AI 自动分析
↓
AI 自动开发
↓
AI 自动 Review
↓
AI 自动 Commit
↓
结束

真正适合工程开发的方式应该是：

sql 复制代码

需求
↓
选择合适 Skill
↓
需求澄清
↓
生成 Spec
↓
拆 Ticket
↓
逐 Ticket 实现
↓
测试
↓
人工审核
↓
AI Review
↓
人工审核
↓
Commit / PR

这里面有一个非常重要的原则：

AI 可以负责执行，但不应该默认拥有最终决策权。

尤其是以下几个环节，我认为必须保留人工控制：

最终需求判断
技术方案决策
变更范围控制
业务正确性审核
是否提交代码
是否合并 PR
是否上线

基于这个原则，再来看哪些 Skill 值得安装。

二、最值得安装的 13 个 Skill

1. `setup-matt-pocock-skills`

这是整个体系的初始化 Skill。

它主要负责确定：

复制代码

Issue 放在哪里
CONTEXT.md 放在哪里
ADR 放在哪里
Issue 状态如何管理
AGENTS.md 如何配置

个人使用 Codex 的话，我比较推荐：

bash 复制代码

Issue tracker：Local Markdown
Domain docs：项目根目录 CONTEXT.md
ADR：docs/adr/

原因很简单。

如果只是自己开发，没有必要为了 AI Coding 再额外维护一套 GitHub Issue 流程。

本地 Markdown 更轻。

例如：

markdown 复制代码

.scratch/
  download-retry/
    spec.md
    issues/
      001.md
      002.md

CONTEXT.md

docs/
  adr/

一个项目通常初始化一次即可。

2. `ask-matt`

这个 Skill 我建议装。

因为 Matt Pocock Skills 多起来以后，真正的问题不是：

Skill 不够。

而是：

你经常忘记这个问题应该调用哪个 Skill。

例如：

bash 复制代码

$ask-matt

我要给 Electron 下载模块增加失败重试，
应该走什么流程？

它可能给出：

vbnet 复制代码

grill-with-docs
→ to-spec
→ to-tickets
→ implement

如果是 Bug：

css 复制代码

diagnosing-bugs
→ tdd
→ code-review

所以我更愿意把 ask-matt 理解成：

Skill Router。

它不负责真正实现需求，而是决定下一步应该进入什么工程流程。

3. `grilling`

grilling 是一个非常有意思的 Skill。

它干的事情，本质上就是：

阻止 AI 在需求还没搞清楚的时候直接开始写代码。

它会围绕需求不断追问，例如：

复制代码

用户真正想解决什么问题？
哪些情况不处理？
失败后如何处理？
数据是否需要持久化？
是否兼容旧逻辑？
验收标准是什么？

这其实正好解决 AI Coding 中最常见的问题：

erlang 复制代码

需求只说了 30%
AI 猜了剩下 70%
然后非常努力地把错误方案实现完整

所以我认为，真正成熟的 AI Coding 流程不是：

复制代码

Prompt 越详细越好

而是：

复制代码

需求
→ AI 反问
→ 人确认
→ 再实施

4. `grill-with-docs`

这是我认为最有价值的 Skill 之一。

普通 grilling 只负责反问。

grill-with-docs 更进一步：

反问需求的同时，把项目知识沉淀下来。

它会配合：

diff 复制代码

grilling
+
domain-modeling

维护：

bash 复制代码

CONTEXT.md
docs/adr/

例如：

bash 复制代码

$grill-with-docs

我要给下载任务增加失败自动重试。

先反问确认需求，不要修改代码。

它会先：

检查项目结构
阅读已有 CONTEXT.md
阅读 ADR
逐个追问需求
统一业务术语
记录重要技术决策
更新领域上下文

这比单纯写一份超长 Prompt 好很多。

因为 Prompt 是一次性的。

而：

复制代码

CONTEXT.md
ADR
Spec
Ticket

是可以跨 Session 使用的。

5. `domain-modeling`

这个 Skill 解决的是一个非常容易被忽视的问题：

AI 不理解你的业务词汇。

例如一个项目里可能同时存在：

复制代码

账号
门店账号
登录账号
下载账号

或者：

复制代码

任务
主任务
子任务
下载任务
门店任务

如果没有统一定义，不同 Session 中 Agent 很可能使用不同叫法。

结果就是：

复制代码

变量名变来变去
类名不一致
文档概念不一致
需求理解发生漂移

domain-modeling 会把这些东西沉淀到：

复制代码

CONTEXT.md

而对于一些比较难逆转的技术决策，则记录为：

bash 复制代码

docs/adr/*.md

例如：

复制代码

ADR-001：下载任务状态由主进程统一维护
ADR-002：失败重试不复用原有任务 ID

这样 Agent 每次进入项目时，都能先读取这些约束。

6. `to-spec`

当需求已经通过反问确认完成以后，不应该马上开始写代码。

下一步应该是：

css 复制代码

to-spec

它负责把：

复制代码

当前对话
代码库
CONTEXT.md
ADR
已确认决策

整理成正式 Spec。

例如：

bash 复制代码

$to-spec

把当前已经确认的需求整理成实施规格。
不要扩展未确认的需求。

最终 Spec 通常应该覆盖：

sql 复制代码

背景
问题描述
目标
解决方案
用户故事
技术方案
影响范围
测试计划
验收标准
非目标 / Out of Scope

我尤其建议保留：

sql 复制代码

Out of Scope

因为 AI 最容易出现的问题之一就是：

顺手优化。

比如你只是让它增加下载重试。

最后它顺便：

复制代码

重构 DownloadManager
修改日志模块
调整目录结构
统一错误类型
修改 UI

代码可能确实变"漂亮"了。

但变更范围已经失控。

7. `to-tickets`

需求稍微复杂一点，我都不建议直接把整个 Spec 一次性交给 Agent。

更合理的是：

复制代码

Spec
↓
Ticket
↓
一个 Ticket 一个 Session

to-tickets 就是干这个的。

它强调一种很重要的拆法：

Vertical Slice，垂直切片。

不要这样拆：

复制代码

任务 1：修改数据库
任务 2：修改后端
任务 3：修改前端
任务 4：补测试

而应该类似：

复制代码

任务 1：完成基础重试配置完整链路

任务 2：完成网络异常自动重试完整链路

任务 3：完成达到最大重试次数后的失败状态处理

每个 Ticket 最好满足：

可以独立完成
可以独立测试
可以独立验收
明确依赖关系
有清晰验收标准
新 Agent Session 可以独立理解

这对于 Codex 很重要。

因为与其让一个 Agent：

复制代码

连续工作几个小时
上下文越来越大
不停 compact

不如：

复制代码

Ticket 001
→ 新 Session

Ticket 002
→ 新 Session

Ticket 003
→ 新 Session

这样稳定性通常更高。

8. `implement`

implement 是真正进入开发阶段的 Skill。

它大致会执行：

css 复制代码

读取 Spec / Ticket
↓
尽可能使用 TDD
↓
实现代码
↓
类型检查
↓
运行测试
↓
Code Review
↓
Commit

例如：

diff 复制代码

$implement

实现 .scratch/download-retry/issues/001.md。

限制：

- 只处理当前 Ticket
- 不实现后续 Ticket
- 不修改需求外代码
- 完成后运行测试
- 不要提交 Git

这里有一个我认为必须修改的地方。

Matt Pocock 原版 implement 存在自动 Commit 的设计。

但是这和我的 AI Coding 流程冲突。

我的流程是：

css 复制代码

AI 实现
↓
第一次人工审核
↓
AI Code Review
↓
第二次人工审核
↓
人工决定是否 Commit

所以我会修改安装后的 implement/SKILL.md：

sql 复制代码

Do not commit automatically.

Present the diff, test results,
risks, and remaining work.

Only commit when the user
explicitly requests it.

这一点非常重要。

我并不希望：

复制代码

AI 写完
= 
AI 认为任务完成
=
直接进入 Git 历史

Commit 应该是一个人工确认点。

9. `tdd`

tdd 的流程比较经典：

复制代码

写失败测试
↓
确认失败
↓
最小实现
↓
测试通过
↓
重构
↓
再次测试

不过我不建议为了"TDD"三个字机械套用。

它特别适合：

sql 复制代码

数据转换
状态机
重试规则
任务状态判断
SQL 构造
业务计算
纯函数逻辑

比如：

复制代码

下载失败

第一次失败 → retrying
第二次失败 → retrying
第三次失败 → failed

这种逻辑非常适合先写测试。

但下面这些场景就不一定适合强行 TDD：

复制代码

WinForm UI 布局
Electron 窗口行为
第三方网页选择器
复杂浏览器交互
难以稳定模拟的外部系统

所以我对 TDD 的原则是：

适合测试的业务逻辑尽量 TDD，不为了形式而 TDD。

10. `diagnosing-bugs`

这个 Skill 我很推荐。

因为 Agent 修 Bug 最危险的模式就是：

复制代码

看代码
↓
猜原因
↓
修改
↓
发现不对
↓
继续猜

diagnosing-bugs 更强调：

先建立稳定的反馈回路。

也就是必须有一个东西可以明确告诉你：

复制代码

Bug 存在 → Fail
Bug 修好 → Pass

这个反馈信号可以是：

arduino 复制代码

单元测试
集成测试
curl
CLI
Playwright
Puppeteer
网络请求重放
最小复现项目
日志
Trace
git bisect run

完整流程类似：

复制代码

复现
↓
最小化
↓
提出假设
↓
增加观测
↓
验证假设
↓
修复
↓
回归测试

这个思路对浏览器自动化尤其有用。

例如：

css 复制代码

Execution context destroyed
Runtime.callFunctionOn
DownloadItem destroyed
networkidle 卡死
iframe 状态异常

这种 Bug 如果只是让 Agent "看看哪里有问题"，很容易不断试错。

如果先让它建立一个稳定复现脚本，效率会高很多。

11. `code-review`

这个 Skill 有一点我非常喜欢：

它把 Review 拆成两个维度。

Standards Review

检查代码本身：

复制代码

项目规范
重复逻辑
异常处理
代码异味
隐藏耦合
维护成本
是否过度设计

Spec Review

检查需求：

复制代码

有没有正确实现 Spec？
有没有遗漏用户故事？
有没有超出需求范围？
有没有违反验收标准？

这两个 Review 分开非常合理。

因为：

复制代码

代码质量很好

不代表：

复制代码

需求实现正确

AI Coding 最容易出现的一种情况就是：

代码写得非常漂亮，但实现错了需求。

我一般会这样调用：

diff 复制代码

$code-review

审查当前分支相对 main 的全部改动。

只报告问题，不修改代码。

重点检查：

- Spec 符合度
- 需求外修改
- 潜在回归
- 异常路径
- 测试覆盖

注意：

Review 阶段我更倾向让 AI 只报告，不自动修复。

否则：

复制代码

Review
↓
自动修改
↓
又产生新 Diff
↓
原来的人工审核结果失效

12. `codebase-design`

AI 写代码有一个非常常见的问题：

特别喜欢抽象。

最后可能出现：

vbnet 复制代码

10 个 Interface
20 个 Service
30 个小文件
大量 Adapter / Factory / Manager

每个文件都很"干净"。

但是理解一个功能要跳十几个文件。

codebase-design 强调的是：

Deep Module。

简单理解就是：

复制代码

对外接口尽量简单
内部承担足够多的复杂行为

它关注：

vbnet 复制代码

Module
Interface
Implementation
Seam
Adapter
Depth
Locality
Leverage

这个 Skill 特别适合拿来约束 AI：

不要为了"看起来架构很好"而制造大量浅层抽象。

尤其对于：

复制代码

WinForm
Electron
自动化工具
中小型桌面项目

过度拆分通常比"不够抽象"更难维护。

13. `handoff`

这是另外一个我非常推荐的 Skill。

Codex 长 Session 最终几乎都会遇到：

复制代码

上下文越来越长
历史讨论越来越多
Agent 注意力开始下降

与其一直 /compact，我现在更倾向：

ini 复制代码

一个 Ticket
=
一个 Session

Ticket 做完以后：

bash 复制代码

$handoff

生成交接。

例如：

bash 复制代码

$handoff

下一会话继续实现
下载失败重试 Ticket 002。

Handoff 会整理：

复制代码

当前目标
已确认决策
已完成内容
代码状态
Spec
Ticket
ADR
测试结果
风险
剩余任务
下一步建议

新的 Agent Session 只需要：

diff 复制代码

Ticket
+
Handoff
+
CONTEXT.md
+
ADR

就可以继续工作。

这比把整个聊天历史重新塞进去干净很多。

三、另外 6 个 Skill，我建议按需安装

下面这些不是没用。

而是没有必要每个项目第一天就安装。

14. `improve-codebase-architecture`

适合分析遗留项目架构。

它会寻找：

复制代码

热点代码
浅模块
高耦合
跨大量文件跳转的功能
难测试模块
缺少 Seam 的代码

例如接手一个多年 WinForm 项目，可以先：

复制代码

只分析 DownloadManager
和相关任务状态管理模块。

不要修改代码。

最多提出 3 个候选改进方案。

我特别建议：

不要让 Agent 直接"优化整个项目架构"。

范围一定要限制。

15. `prototype`

用一次性代码快速验证方案。

可以用来做：

rust 复制代码

状态机 Prototype
业务流程 Prototype
UI Prototype
复杂表单 Prototype

比如准备重写一个时间选择器：

复制代码

先生成 3 套交互方案

先比较。

确认以后再进入正式开发。

关键点在于：

Prototype 从一开始就应该被认为是可删除代码。

不要：

复制代码

原型能跑
↓
直接复制到生产

16. `research`

用于查：

复制代码

官方文档
规范
源码
第一方 API
官方 Example

例如：

复制代码

研究 Electron will-download
和 DownloadItem destroyed 的官方行为

或者：

matlab 复制代码

研究 Playwright persistent context
的登录态限制

这种场景比让 Agent：

复制代码

根据记忆告诉我

靠谱很多。

17. `resolving-merge-conflicts`

专门处理：

sql 复制代码

merge
rebase

冲突。

它不是简单选：

复制代码

ours

或者：

复制代码

theirs

而是尝试理解：

sql 复制代码

两边 Commit 的意图
Issue
PR
历史代码

然后尽可能同时保留两边意图。

多人协作项目值得装。

个人项目优先级没那么高。

18. `triage`

如果项目有很多：

复制代码

GitHub Issue
Bug
需求
PR

这个 Skill 会比较有价值。

它负责：

复制代码

分类
补充信息
验证 Bug
判断是否重复
生成 Agent Brief
决定是否适合 AI 处理

例如 Issue 状态可以在：

arduino 复制代码

needs-triage
needs-info
ready-for-agent
ready-for-human
wontfix

之间流转。

如果只是个人项目 + Local Markdown Ticket，可以先不装。

19. `writing-great-skills`

这个虽然我放在"按需安装"，但对准备长期使用 AI Coding 的人其实很值得装。

因为最终最有价值的，很可能不是：

一直寻找别人写好的 Skill。

而是：

把自己的工程方法沉淀成 Skill。

比如我后面准备把自己的流程固化成：

rust 复制代码

AI for SDD
需求分析
Plan Review
实施范围控制
人工审核检查点
PR 准备

第三方 Skill 解决的是通用工程能力。

自己的 Skill 解决：

复制代码

我的团队
我的项目
我的审核方式
我的风险偏好
我的开发流程

两者并不冲突。

四、这 3 个 Skill，我暂时不会装

`wayfinder`

它更适合：

复制代码

大型平台
长期架构迁移
跨多个系统
大量未知问题

它通过决策 Ticket 一步步消除未知。

普通功能需求上它会显得太重。

`grill-me`

这是没有代码库时使用的通用反问工具。

对于已有项目：

csharp 复制代码

grill-with-docs

更适合。

因为后者还能结合：

复制代码

CONTEXT.md
ADR
代码库

一起使用。

`teach`

主要用于学习一个知识领域。

例如：

复制代码

系统学习 WPF
系统学习 Android
系统学习后端

不是软件交付核心流程。

所以暂时不装。

五、最终安装清单

第一阶段，我建议先安装核心 13 个：

css 复制代码

setup-matt-pocock-skills
ask-matt

grilling
grill-with-docs
domain-modeling

to-spec
to-tickets

implement
tdd

diagnosing-bugs
code-review
codebase-design

handoff

安装入口：

sql 复制代码

npx skills@latest add mattpocock/skills

如果准备自己改 Skill、沉淀团队流程，再增加：

复制代码

writing-great-skills

之后按项目需要增加：

perl 复制代码

improve-codebase-architecture
prototype
research
resolving-merge-conflicts
triage

六、最终我准备这样使用 Codex

组合以后，我现在比较认可的流程是：

markdown 复制代码

不知道应该使用什么 Skill
        ↓
     ask-matt
        ↓
────────────────────

需求不明确
        ↓
 grill-with-docs
   ├─ grilling
   └─ domain-modeling
        ↓
────────────────────

需求确认
        ↓
      to-spec
        ↓
────────────────────

复杂需求
        ↓
    to-tickets
        ↓
────────────────────

Ticket 001
        ↓
    implement
   ├─ tdd
   ├─ typecheck
   ├─ test
   └─ code-review
        ↓
────────────────────

第一次人工审核
        ↓
   code-review
        ↓
第二次人工审核
        ↓
人工决定 Commit / PR

Bug 则单独走：

css 复制代码

Bug
↓
diagnosing-bugs
↓
建立稳定复现
↓
定位根因
↓
tdd / 回归测试
↓
修复
↓
code-review

上下文过长：

复制代码

handoff
↓
新 Codex Session

遗留项目结构太乱：

复制代码

improve-codebase-architecture
↓
codebase-design
↓
人工选择重构目标

七、我认为真正重要的不是 Skill，而是"控制权"

用了一圈以后，我最大的感受反而不是：

Matt Pocock 哪个 Skill 最强？

而是：

AI Coding 最重要的，是把 AI 的权限边界设计清楚。

比如我不会允许 Agent：

sql 复制代码

需求不明确 → 直接编码

Review 发现问题 → 自动大范围修改

实现完成 → 自动 Commit

发现架构不好 → 自动重构整个模块

我的原则更接近：

sql 复制代码

AI 负责：
分析
拆解
实现
测试
Review
提供建议

人负责：
需求确认
方案选择
范围控制
业务审核
风险判断
Commit
Merge
上线

Skill 的真正价值，就是把这些约束从：

复制代码

每次重新写 Prompt

变成：

复制代码

固定的工程流程

最后

如果只是想体验 Matt Pocock Skills，全部安装当然没有什么问题。

但如果目标是长期把 Codex 用在真实工程项目里，我更建议从小规模开始：

css 复制代码

grill-with-docs
→ to-spec
→ to-tickets
→ implement
→ code-review
→ handoff

先把这一条主链跑顺。

然后再根据实际问题增加：

perl 复制代码

diagnosing-bugs
tdd
prototype
research
architecture
triage

最终最好再把自己的：

css 复制代码

需求分析方式
Plan 模板
人工审核点
变更范围规则
Code Review 标准
Git / PR 流程

固化成自己的 Skill。

到了这一步，AI Coding 才不再只是：

"让 AI 帮我写代码。"

而会逐渐变成：

"让 AI 按我的软件工程流程参与开发。"

这两者之间，我认为差别非常大。

Codex + Matt Pocock Skills 实战：别全装，这 13 个 Skill 才是真正的核心

一、先说结论：不要把 Skills 当成"大一统开发框架"

二、最值得安装的 13 个 Skill

1. setup-matt-pocock-skills

2. ask-matt

3. grilling

4. grill-with-docs

5. domain-modeling

6. to-spec

7. to-tickets

8. implement

9. tdd

10. diagnosing-bugs

11. code-review

Standards Review

Spec Review

12. codebase-design

13. handoff

三、另外 6 个 Skill，我建议按需安装

14. improve-codebase-architecture

15. prototype

16. research

17. resolving-merge-conflicts

18. triage

19. writing-great-skills

四、这 3 个 Skill，我暂时不会装

wayfinder

grill-me

teach

五、最终安装清单

六、最终我准备这样使用 Codex

七、我认为真正重要的不是 Skill，而是"控制权"

最后

1. `setup-matt-pocock-skills`

2. `ask-matt`

3. `grilling`

4. `grill-with-docs`

5. `domain-modeling`

6. `to-spec`

7. `to-tickets`

8. `implement`

9. `tdd`

10. `diagnosing-bugs`

11. `code-review`

12. `codebase-design`

13. `handoff`

14. `improve-codebase-architecture`

15. `prototype`

16. `research`

17. `resolving-merge-conflicts`

18. `triage`

19. `writing-great-skills`

`wayfinder`

`grill-me`

`teach`