Matt Pocock 的 AI Coding Skills 工作流

Matt Pocock 的 skills 仓库 把需求澄清、领域建模、规格整理、任务拆分、测试驱动实现和代码审查分别做成可组合的 Skill，再用一条主流程决定何时调用它们。

这种设计处理的是 AI 编程中三个反复出现的问题：意图没有说清、上下文越积越长、实现结果缺少独立验证。模型仍然负责推理和生成代码，但讨论结果会写入文档，复杂任务会切成可验证的纵向切片，审查也会放进独立上下文。

本文以 2026 年 8 月 5 日发布的 mattpocock/skills v1.2.2 为基准。工作流、安装方式和初始化选项均按该版本的 README.md 与 SKILL.md 整理。

先区分技能库与安装器

v1.2.2 提供两种安装入口。Claude Code 可以安装托管的只读 Plugin，Codex 和其他 Agent 则通过 Vercel Labs 维护的 skills CLI 选择需要的 Skill。两种方式不要同时安装，否则同一项 Skill 会出现两份。

Claude Code Plugin 的安装命令是：

claude plugins install mattpocock-skills

Codex 和其他 Agent 使用：

npx skills@latest add mattpocock/skills

交互式安装会选择具体 Skill、目标 Agent、安装范围和连接方式。使用 CLI 时，应确保选中 setup-matt-pocock-skills。当前安装器的关键选项如下：

团队优先选择 Project，因为 Skill 本身包含流程、术语和质量门槛，属于项目开发契约的一部分。项目级文件可以随仓库共享，成员和 Agent 能使用同一套配置，也能通过 Git 审查修改。Global 更适合个人偏好或多个仓库都需要的通用能力。

每个仓库先运行一次 Setup

安装完成后，在目标仓库调用：

/setup-matt-pocock-skills

这个 Skill 不修改其他 SKILL.md，而是把仓库差异写进 docs/agents/。它主要确定三件事：

1. Issue tracker 在哪里。GitHub、GitLab 和本地 Markdown 有内置模板；Jira、Linear 等系统通过「Other」记录自定义操作流程。

2. Triage labels 如何映射。只有安装了 triage 时才会生成对应配置，默认角色包括 needs-triage、needs-info、ready-for-agent、ready-for-human 和 wontfix。

3. Domain docs 如何组织。绝大多数仓库使用根目录 CONTEXT.md 与 docs/adr/；检测到大型 monorepo 信号后，才会提供 CONTEXT-MAP.md 与多上下文布局。

Setup 还会在已有的 CLAUDE.md 或 AGENTS.md 中加入 ## Agent skills 指针。当前选择规则是优先修改已存在的 CLAUDE.md，其次是 AGENTS.md；两者都不存在时再询问创建哪一个。

这一步为每个仓库建立独立契约。Issue 存放位置、领域术语和架构决策都与代码库绑定，应当进入版本控制。

两类 Skill 控制上下文开销

当前仓库按调用权限区分两类 Skill：

User-invoked Skill 通常带有 disable-model-invocation: true，Agent 不会自行触发。它们的描述只需支持发现和路由，完整流程等到显式调用后才进入上下文，从而减少常驻指令对上下文窗口的占用。

主流程如何运行

ask-matt 把主要路径概括为「idea → ship」。它是一个手写路由器：不知道下一步调用哪个 Skill 时，用它取得建议，然后显式调用对应 Skill。已经确定目标 Skill 时可以直接调用。

这条流程没有要求所有任务都生成 Spec 和 Tickets。关键判断是工作能否在一个状态良好的会话中完成。小改动可以在访谈后直接进入 implement；跨多个会话的功能才需要先压缩为 Spec，再拆成 Tickets。

1. grill-with-docs：先形成共享语言

grill-with-docs 调用 grilling 进行连续访谈，同时使用 domain-modeling 维护领域文档。Agent 不只提问，还会扫描代码库、核对已有术语，并把已经确认的信息写入：

• CONTEXT.md：定义领域词汇，以及应避免的近义词；

• docs/adr/：记录重要架构决定、背景和后果；

• CONTEXT-MAP.md：仅在多上下文仓库中指向相关领域文档。

深度访谈的价值在于提前暴露分支：角色是谁、行为边界在哪里、旧数据如何迁移、失败后如何恢复、哪些条件可以验收。实现前解决这些问题，成本通常只是一次讨论；代码生成后再发现理解不同，修改会扩散到接口、数据结构和测试。

访谈也不能替代验证。事实可以从代码、日志和文档中查证，产品取舍仍要由负责决定的人确认。CONTEXT.md 只记录稳定术语，不适合堆放完整聊天记录。

2. to-spec：把讨论压缩成终点定义

to-spec 直接综合已有会话与代码库信息，不重复需求访谈。它会先确认合适的测试 seam，再把结果发布到已配置的 Issue tracker。当前模板包括：

• Problem Statement 与 Solution；

• 完整的 User Stories；

• Implementation Decisions；

• Testing Decisions；

• Out of Scope 与 Further Notes。

它要求描述模块、接口、契约和测试决定，但默认不写具体文件路径或实现代码，因为这些细节在开发过程中最容易失效。Spec 描述的是完成后的外部行为和关键决定，为后续会话提供稳定终点。

这也是一次上下文压缩。数万 token 的讨论包含尝试、否定和重复解释，Spec 只保留已经确认的结论。压缩会丢失信息，因此应在同一会话中完成访谈、Spec 和 Tickets；如果会话接近 Smart Zone，再选择最近的阶段边界执行 /compact。

3. to-tickets：按可验证纵向切片拆分

to-tickets 把工作拆成可以单独验证的纵向切片，每个 Ticket 都贯穿完成行为所需的层次。「先数据库、再 API、最后 UI」这类水平拆分不符合它的默认规则。例如，第一张 Ticket 可以只交付一种最小订单路径，但要同时包含必要的数据、接口、界面和测试。

每张 Ticket 还要声明 blocking edges。没有 blocker 的 Ticket 可以立即开始；有依赖的 Ticket 只有在前置工作完成后才进入可执行状态。本地 tracker 会把它们保存为 .scratch/<feature>/issues/<NN>-<slug>.md，真实 tracker 则尽量使用原生依赖关系。

Ticket 大小以「能否在一个新的上下文窗口中完成」为准，不用固定行数衡量。当前 ask-matt 把 Smart Zone 描述为先进模型仍能清晰推理的约 150k tokens 区间。这个数值属于工作流的经验阈值；模型、Agent 运行环境、工具输出和任务类型都会改变有效范围。

纵向切片提高了局部可验证性，也会增加规划和依赖管理成本。机械式的大范围重命名很难保持每个切片独立通过，to-tickets 对这类 Wide Refactor 使用 expand-contract：先兼容新旧形式，再分批迁移调用方，最后删除旧形式。

4. implement 与 code-review：实现后回到两类证据

implement 读取 Spec 或 Tickets，在预先确认的 seam 上调用 tdd，持续运行类型检查和单个测试，结束前再运行完整测试套件。当前 Skill 最后还会调用 code-review，并提交当前分支。

这个自动提交行为需要提前纳入仓库规则。若团队要求人工批准 commit，应在 AGENTS.md 或 CLAUDE.md 中写明，不能假设所有 Skill 都采用相同的 Git 授权边界。

code-review 沿两个轴检查从固定 Git 基准点到 HEAD 的差异：

两个审查轴由并行子 Agent 执行，最后并列汇总，不把结果混成一个总分。独立上下文可以减少执行者对自己方案的锚定，也能防止「代码很整洁」掩盖「实现了错误需求」。客观正确性仍需由测试、类型检查、真实运行结果和人工判断共同证明。

用文档保存跨会话状态

这套工作流把不同类型的状态放进不同载体：

这些文件共同承担跨会话状态，但它们的权威范围不同。讨论 Skill 行为时，具体 SKILL.md 高于 ask-matt 的摘要；判断需求时，已批准 Spec 高于旧聊天片段；判断系统现状时，代码、测试和运行结果高于过期文档。

ask-matt 是流程路由，不是每项 Skill 的完整说明。只要某条建议会影响任务拆分、提交或发布，就应打开目标 SKILL.md 核对，路由摘要只用于定位下一步。

怎样按任务规模采用

这套流程可以逐步引入，不必一次安装全部 Skill。

对于一个会话内能完成的小功能，可采用：

setup（每个仓库一次）
→ grill-with-docs
→ implement
→ review and verify

对于跨多个会话的功能，可采用：

setup（每个仓库一次）
→ grill-with-docs
→ to-spec
→ to-tickets
→ 每张 Ticket 开新会话运行 implement
→ 集成验证

对于还无法通过讨论回答的状态模型、业务逻辑或 UI 问题，先用 handoff → prototype → handoff 做一次可运行实验，再回到原流程。对于更庞大且方向仍不清楚的 Greenfield 项目或大型功能，当前仓库还提供 wayfinder，先用 Decision Tickets 消除关键未知项，再进入 to-spec。

第一次实践时，最好选择一项边界清楚、能够运行测试、又确实需要澄清需求的真实改动。完成后检查四件事：领域术语是否更统一，Spec 是否删掉了讨论噪声，每张 Ticket 是否能单独验收，双轴审查是否发现了不同类型的问题。只有这些结果成立，流程成本才有实际回报。

参考资料

• Matt Pocock：mattpocock/skills: A complete AI Coding workflow, end-to-end

• mattpocock/skills：v1.2.2 Release

• mattpocock/skills：README

• mattpocock/skills：ask-matt

• mattpocock/skills：setup-matt-pocock-skills

• mattpocock/skills：grill-with-docs

• mattpocock/skills：to-spec

• mattpocock/skills：to-tickets

• mattpocock/skills：implement

• mattpocock/skills：code-review

• Vercel Labs skills CLI：安装范围与安装方式