7 月初，@mattpocockuk 对 skills 的改动方向很清楚：把 AI Agent 的工作过程拆解成几个更容易检查和交接的环节。先问清需求，写成 spec，拆成 tickets，一次执行一小块，最后 review 和 handoff。单看这些名字会觉得零散，放回真实任务里，逻辑反而清楚了很多。

这套方法解决的是日常使用 Agent 时最容易不受控的部分：需求聊了很长时间，最后没有一份可执行说明；代码虽然写出来了，却对不上验收标准；任务做到一半换session，下一轮又要重新解释背景。mattpocock/skills 的价值，在于把这些环节一个个固定下来。

这篇文章按使用场景讲。普通任务走「问清楚、写约束、拆工单、执行、审查、交接」；大任务先用 /wayfinder 画地图；查资料让 /research 产出带引用的 Markdown；配置第三方服务用 /wizard 把步骤变成交互式 CLI。更合适的读法：这是一套工作流程，命令只是入口。

注：此文配图源自本人开源skill：「卷卷整理研究所：内容插画 Skill」，https://github.com/dososo/juju-content-illustrations

[!abstract] 本文要点
以 mattpocock/skills 为例，把 AI Agent 工作流讲透：普通任务的六步流程（grill → spec → tickets → implement → review → handoff）、大任务先用 /wayfinder 画地图，以及 Superpowers / GStack 如何选、自己写 Skill 的正确路径。

1. 先说清楚：Skills 解决的是「AI 工作过程没人管」

1.1. 把聊天变成可检查的记录

mattpocock/skills 的重点，是把 Agent 工作拆成一串可检查的记录。需求要写成 spec，任务要拆成 tickets，代码要经过 review，长任务要留下 handoff。这样一来，人能随时知道 Agent 做到哪一步、依据是什么、下一步该交给谁。

1.2. 厨房备菜式的工作流

可以把这套流程想成厨房备菜。厨师再厉害，也需要菜单、备料清单、出餐节奏和复盘记录。/grill-with-docs 负责问清楚要做什么，/to-spec 负责把口头需求写成约束，/to-tickets 负责拆出可领取的工单，/implement 负责做一小块，/code-review 负责检查成品，/handoff 负责把现场交给下一轮。

核心动作很简单：把聊天里的想法，变成 spec、tickets、review、handoff 这些看得见的记录。 这也是 Matt 最近一周在 X 和 GitHub 上持续调整的方向。

2. Matt 最近一周改了什么

1. AGENTS.md 要简化

21小时

90% 的人可以删除他们的 AGENTS.md 文件，他们的输出就会有所改善。将其用作指向重要文件的索引指针，即使如此，也要积极地修剪掉那些无操作的部分。这模糊不清的程度如何？

2.1. AGENTS.md 要简化

Matt 近期多次提到，AGENTS.md 或 CLAUDE.md 可以删掉大量内容，结果反而更好。这个判断很实用，因为 AGENTS.md 属于高频上下文，每次启动 Agent 都会进入模型视野。把项目历史、产品理念、目录说明、编码规则、部署细节全部塞进去，相当于让人每次开工都背一本手册。

更好的写法是把 AGENTS.md 当索引，只放高频规则和入口位置：项目怎么测试，禁止哪些高风险操作，术语文档在哪里，架构决策放在哪个目录，Issue 规则去哪看。正文知识放到独立文件，任务需要时再读。这样上下文更干净，规则也更容易维护。

# AGENTS.md

环境：macOS，pnpm，Node 22
测试：pnpm test
类型检查：pnpm typecheck
禁止批量删除文件
项目术语见：docs/CONTEXT.md
架构决策见：docs/adr/
Issue 规则见：docs/agents/issue-tracker.md

2. /wayfinder 用来处理大任务的迷雾

2.2. /wayfinder 处理大任务迷雾

Matt 这周持续迭代 /wayfinder，还提到用它规划一门课程，背后跑了接近 100 次 grilling、prototype、research session，最后汇总到一张中心地图。这个数字很说明问题：大任务刚开始时，难点往往是路线尚未成形，执行还没到关键阶段。

7月3日

我他妈的爱死原型设计了。Wayfinder 又一次干得漂亮，随处打开一个模态框就能用 AI 编辑我课程的文本

/wayfinder 适合处理这种状态：目标大致知道，但关键决策、研究点、原型验证点和依赖关系还没摊开。

2.2.1. /wayfinder 的产出

它的产物应该是一张地图，里面写清楚已确认的决策、仍需研究的问题、需要做原型的部分、需要继续追问的部分、可以并行的工单，以及哪些工作必须等前置结论。

3. /to-prd 正在转向 /to-spec

2.3. /to-prd 转向 /to-spec

Matt 7 月 2 日提到，/to-prd 会改向 /to-spec，/to-issues 会改向 /to-tickets。这不只是改名，表达的重心变了。PRD 容易被理解成文档，spec 更接近执行约束；issues 容易变成列表，tickets 更像可以领取、可以验收的工作单。

一个有用的 spec，要写清楚目标、术语、边界、验收标准、明确不做的内容。一个有用的 ticket，要能单独交付，最好是一条 vertical slice，也就是用户能看到变化的一小段完整路径。拆成「数据库、API、前端、测试」看着专业，但每一步很难单独验收；拆成「一条选题可以保存一个来源并展示」，执行者和验收者都更轻松。

4. /research、/wizard、/handoff 在补边角

2.4. /research、/wizard、/handoff 补边角

/research 的职责很窄：让后台 Agent 查一手来源，并保存带引用的 Markdown。/wizard 解决第三方服务配置，把 API key、.env、GitHub Secrets 这些步骤变成可交互流程。/handoff 解决换会话、换模型、换 Agent 时的交接。

这些 Skill 听起来不是很酷炫，但很有工程味。AI 协作出问题，常常发生在边角：资料来源没人记，配置步骤讲不清，任务做到一半换会话，下一轮完全不知道现场。Matt 这轮调整把这些边角补上，整套流程才更像工作系统。

3. 还有几个重要入口，简单提一下

3.1. 配置入口与导航

/setup-matt-pocock-skills 是第一次使用前要跑的配置入口，用来设置 issue tracker、triage labels 和文档保存位置。这个步骤很基础，但会影响后面 /to-issues、/triage、/implement 怎么工作，建议放在最前面处理。

/ask-matt 是路由器。遇到「这个场景该用哪个 Skill」时，可以先让它判断。它会把任务放到主流程、on-ramp、standalone 或底层 vocabulary 里，比直接猜命令更省心。

3.2. 原型、教学与排查工具

/prototype 适合处理还没想清楚的设计问题，例如状态模型是否合理、交互方案是否成立、某个 UI 感觉是否对。它的定位是一次性原型，目标是回答问题，答案留下，代码可以丢掉。

/teach 会把当前目录当成学习 workspace，维护 mission、resources、lessons 和 learning records。适合用来系统学一个概念，不适合直接推进工程任务。

/triage、/diagnosing-bugs、/domain-modeling、/codebase-design、/improve-codebase-architecture 也值得知道。/triage 把外部 issue 变成 agent-ready brief；/diagnosing-bugs 先建立可复现反馈循环，再定位问题；/domain-modeling 管业务语言；/codebase-design 管模块和接口形状；/improve-codebase-architecture 用来扫描代码库里适合改进的结构点。它们都很有用，只是不要一开始全塞进主流程，按场景调用就行。

4. 普通任务直接照这条流程跑

先别研究所有 Skill。拿一个真实任务，按下面这条线跑一遍：

graph TD
  A["真实需求"] --> B["/grill-with-docs"]
  B --> C["/to-prd 或 /to-spec"]
  C --> D["/to-issues 或 /to-tickets"]
  D --> E["/implement"]
  E --> F["/code-review"]
  F --> G["/handoff"]

4.1. 第一步：拿真实需求，不拿玩具任务

「写一个 TODO App」这类测试暴露不出流程问题。更适合的任务应该来自实际工作，范围小，能验收，例如给内容选题工具加「来源证据记录」，给文章草稿系统加「引用来源字段」，给后台列表加「批量标记已处理」，给用户反馈系统加「AI 摘要」。

判断标准很简单：这个需求有实际用途，范围可以控制，完成后能看见明确结果。

4.2. 第二步：先 /grill-with-docs

这一轮只做追问，暂时不写代码。可以这样给 Agent：

/grill-with-docs

要给内容选题工具加一个「来源证据记录」功能。
每条选题需要记录来源链接、发布时间、来源类型、推荐理由、是否一手来源。
请先问问题，直到需求、边界、术语、验收标准都清楚，再进入下一步。

这一轮通常会问出隐藏问题：来源是一条还是多条，是否区分主来源和辅助来源，过期来源怎么提醒，导出时是否带来源，没有来源的选题能否进入发布池，一手来源和二手来源如何排序。把这些问题提前问完，后面写 spec 才不会含糊。

4.3. 第三步：用 /to-spec 写成约束

如果当前仓库里还叫 /to-prd，就先用旧名字；如果已经更新到 /to-spec，优先用新名字。这里不要追求文档漂亮，重点是减少后续猜测。

spec 至少包含这些内容：用户问题、解决方案、术语定义、用户故事、验收标准、明确不做的内容、需要测试的行为。尤其要写「明确不做」，例如只加来源记录，不重做整个选题系统；只展示来源，不自动判断来源真实性；只支持手动录入，不做网页全文抓取。

4.4. 第四步：用 /to-tickets 拆成可验收工单

拆工单时，不要拆成技术层。更好的拆法是按用户可见结果拆：

Ticket 1：一条选题可以保存一个来源链接，并在详情页展示
Ticket 2：一条选题可以保存多个来源，并标记主来源
Ticket 3：来源可以记录发布时间，超过窗口时显示提醒
Ticket 4：导出选题时带上来源证据

每个 ticket 都要能单独验收。这样即使不懂完整架构，也能判断这一步有没有完成。

4.5. 第五步：一次只 /implement 一个 ticket

执行时要收窄范围，提示词可以这样写：

/implement

请实现 issue #12。
只处理这个 issue 的验收标准。
优先使用 /tdd。
不要重构无关代码。
完成后运行相关测试和类型检查。

这里的关键是「只处理这个 issue」。Agent 能处理大量工作，不代表一次应该交给它大量工作。边界越清楚，结果越容易审查。

4.6. 第六步：写完固定 /code-review

测试通过只能说明没有明显红灯，不能说明需求被完整满足。实现结束后，要让另一个视角检查 spec、ticket 和代码差异：

/code-review

请 review 当前分支相对 main 的改动。
重点检查：
1. 是否满足 issue #12 的验收标准
2. 是否有额外改动
3. 是否出现过度设计
4. 是否有代码异味
5. 是否留下 UI stub 或未完成状态

Matt 最近把 Fowler 的 code smells 放进 review 逻辑里，这个方向很实用。Agent 写代码很快，审查环节更不能省。

4.7. 第七步：上下文变长就 /handoff

任务没做完，或者要换会话、换模型、换 Agent，不要硬撑长上下文。用 /handoff 生成交接说明：已完成什么，改了哪些文件，跑过哪些测试，剩什么没做，下一步从哪里开始。

长任务最怕现场丢失。暂停可以接受，交接缺失会让下一轮重新摸索。handoff 的作用，就是给下一轮留一张现场照片。

5. 一个案例：把「来源证据记录」变成可执行任务

5.1. 案例：来源证据记录功能

原始需求只有一句话：给选题工具加一个来源证据记录功能。直接丢给 Agent，它大概率会加字段、改页面、写保存逻辑，但这个需求里有几个必须提前确认的问题：来源数量、主来源、来源类型、发布时间、导出格式、无来源选题是否允许保存、链接失效时怎么处理。

追问结束后，可以把 spec 压成下面这种结构：

目标：每条选题都能记录来源证据，方便写作、复盘和审核。

核心字段：
source_url
source_title
source_type
published_at
evidence_note
is_primary_source

验收标准：
创建选题时可以添加至少一个来源
详情页能展示来源列表
可以标记一个主来源
发布时间超过选题窗口时显示提醒
导出选题时包含来源信息

明确不做：
不自动抓取全文
不自动判断来源真实性
不重构整个选题系统

再拆成 tickets，执行难度会明显下降：先做「保存一个来源并展示」，再做「多个来源和主来源」，再做「发布时间提醒」，最后做「导出带来源」。Agent 拿到的任务会从模糊的「把来源功能做好」，收敛为「完成 Ticket 1，并通过对应验收」。

5.2. Skill 的本质是压缩检查成本

这个案例说明了一件事：Skill 的作用，是压缩检查成本，让每一步都能验收。

6. 大任务先用 /wayfinder

6.1. 什么时候用 /wayfinder

如果任务像「重做内容生产系统」「规划一门课程」「设计一个 AI Agent 产品」「重构一个老项目」，直接进入 /grill-with-docs 可能会太早，因为这时连路线都没形成。先用 /wayfinder 更合适。

提示词可以这样写：

/wayfinder

要规划一套内容选题到文章发布的 AI 工作流。
请先建立一张地图：
已知目标
关键决策
未确认问题
需要 research 的点
需要 prototype 的点
需要 grilling 的点
可以拆成哪些 tickets

判断是否需要 /wayfinder，看三点：任务一次会话讲不完；多个关键决策会互相影响；需要 research、prototype、grilling 混合推进。符合这些条件，先画地图，再把地图里的迷雾拆成 tickets。

7. Superpowers、GStack、mattpocock/skills 怎么选

7.1. 三个方案对比

这三个方案经常被放在一起，实际使用方式差别很大。

Superpowers 更像教练，会把使用者带进 brainstorming、spec、plan、execute、verify 的流程。它适合缺少工程流程约束的场景，代价是任务小的时候会显得重。

GStack 更像一个虚拟创业团队，用 CEO、Engineering Manager、Designer、QA、Reviewer 等角色推进项目。它适合产品型项目和独立开发者做多视角讨论，代价是简单任务会出现角色成本。

mattpocock/skills 更像工具箱。它保留使用者自己的工作节奏，只在关键节点插入 /grill-with-docs、/to-spec、/to-tickets、/implement、/code-review、/handoff。已有工作习惯，只想让 Agent 在关键节点更可靠，选这套更舒服。

7.2. 一句话选择建议

一句话建议：缺流程，用 Superpowers；做产品团队模拟，用 GStack；已有自己的流程，想给关键节点加工具，用 mattpocock/skills。

8. 自己写 Skill，要从真实任务里提炼

8.1. 正确路径：先跑任务再写 Skill

这里最容易做反。直接让 AI 写一个 Skill，通常会得到一份漂亮但空泛的提示词。更好的路径是先完成真实任务，再记录 AI 反复出错的地方，把反复纠正的话沉淀成步骤、检查项和完成标准。

以「来源证据记录」为例，如果 Agent 反复漏掉发布时间、主来源、导出字段、一手来源判断、过期提醒，就可以沉淀一个窄职责 Skill：

/source-aware-topic-design

职责：设计内容选题功能时，强制检查来源、时效、一手程度、导出和可验证性。

8.2. 一个好 Skill 的五要素

**一个好 Skill 至少写清楚五件事：什么时候触发，要读哪些文件，要问哪些问题，要产出什么，什么情况下必须停下来让人确认。**Matt 提到的 /writing-great-skills 适合放到最后使用，先跑真实任务，再封装固定流程。

9. 使用时最容易出问题的 8 个点

9.1. 常见问题清单

1. 把 Skill 当提示词收藏。只写「请按专家标准输出」价值很低，流程、判断、产物、完成标准都要写进去。
2. AGENTS.md 写成百科全书。高频上下文要短，低频知识放文件，需要时再读。
3. 省掉 grilling。需求没对齐时，越早写代码，后面返工越多。
4. ticket 拆成技术层。数据库、API、前端、测试这种拆法不利于验收，优先拆成用户能看到的小结果。
5. 一次给 Agent 太多工作。一次只做一个 ticket，大任务先用 /wayfinder。
6. 写完不 review。测试通过只是底线，/code-review 应该检查 spec、无关改动、代码异味和未完成状态。
7. 决策只留在聊天里。重要内容要写进 spec、issue、CONTEXT、ADR 或 handoff。
8. 一开始就写自己的 Skill。先跑任务，记录重复问题，再把固定做法封装起来。

10. 收藏版流程

10.1. 普通任务：

graph TD
  A["真实需求"] --> B["/grill-with-docs"]
  B --> C["/to-prd 或 /to-spec"]
  C --> D["/to-issues 或 /to-tickets"]
  D --> E["/implement"]
  E --> F["/code-review"]
  F --> G["/handoff"]

10.2. 大任务：

graph TD
  A["/wayfinder"] --> B["建立地图"]
  B --> C["拆出 research、prototype、grilling tickets"]
  C --> D["逐个处理未确认问题"]
  D --> E["进入 spec、tickets、implement"]

10.3. 查资料：

graph TD
  A["/research"] --> B["后台查一手来源"]
  B --> C["保存带引用的 Markdown"]
  C --> D["回到主流程继续决策"]

10.4. 配置第三方服务：

graph TD
  A["/wizard"] --> B["生成交互式 CLI"]
  B --> C["按步骤复制 key、写 env、设置 secrets"]
  C --> D["验证配置是否生效"]

10.5. 写自己的 Skill：

graph TD
  A["先跑真实任务"] --> B["记录反复纠正 AI 的地方"]
  B --> C["把纠正变成步骤和完成标准"]
  C --> D["再用 /writing-great-skills 封装"]

11. 最后一句

11.1. 核心要点

mattpocock/skills 的核心可以概括成一句话：让 AI 工作留下可检查的记录。 有 spec，才知道需求边界；有 tickets，才知道先做哪一块；有 code review，才知道改动是否合格；有 handoff，下一轮才接得住。

如果已经 star 了仓库，建议别从安装一堆 Skill 开始。拿一个真实需求，完整跑一遍 /grill-with-docs、/to-spec、/to-tickets、/implement、/code-review。跑完这条线，再决定哪些环节需要写成自己的 Skill。

12. 参考来源

1. Matt X 账号近一周讨论：@mattpocockuk
2. mattpocock/skills 仓库：GitHub
3. /research 合入：PR #409
4. grilling 加确认门：PR #433
5. wayfinder 原生依赖：PR #435
6. wayfinder assignee claim：PR #436
7. GStack 仓库：garrytan/gstack
8. Superpowers 仓库：obra/superpowers
9. /ask-matt Skill：GitHub
10. /teach Skill：GitHub
11. /setup-matt-pocock-skills Skill：GitHub