Matt Pocock skills 1.3 解析：Implement Spec、PR 与 Retro 三大核心技能

AI 编程工具链的迭代速度，往往体现在那些看似不起眼却决定工作流上限的细节里。Matt Pocock 最近发布了 skills 仓库的 1.3 版本，带来了三个被他称为「工作流核心」的技能：Implement Spec、PR 和 Retro。这三个 Skill 分别对应了开发流程中的实现编排、代码审查效率、以及 agent 会话的复盘优化。

Implement Spec：用 SubAgent 编排 Ticket 图

当你面对一大块工作时，Matt 的做法是将其拆成两样东西：**Spec（目标）**和 Ticket（执行单元）。Spec 是你想去的目的地，而 Ticket 则把目的地拆成一个个可独立交给 Coding Agent 执行的小任务。

他的核心判断是：让一个 Coding Agent 一次性做完整个 Spec，会进入「犯傻区」，还可能触发自动压缩。虽然这种做法有时也能跑通，而且效果在变好，但把活拆成 Ticket 交给独立的 Agent 执行，要干净得多。

问题是，如何编排这些 Ticket？Matt 列出了三种方式：

• 手动循环：用户扮演 Full 循环，对 Agent 说「实现第一个 Ticket」，等它做完、清掉上下文，再说「实现第二个」。他直言「一点都不好玩」。
• 确定性循环：写个脚本读取每个 Ticket 并自动跑实现。可靠且便宜，因为跑循环的不是 Agent 也不是人，而是脚本。但打磨这个循环需要很多耐心，对新手的门槛太高。
• SubAgent 循环：这是 Implement Spec 采用的折中方案——让 SubAgent 去跑循环做实现，相当于把「看孩子」的活交给 Agent。

这次之所以可行，是因为 SubAgent 现在自己也能再派 SubAgent 了。以前的 SubAgent 多少有点被削弱，而现在它们跟编排 Agent 一样强大。

Implement Spec 的流程一共 9 步，关键点在于能并行的地方就并行。Ticket 不是一串线性步骤，而是一张带依赖关系的任务图，所以总有一批 Ticket 随时可以领取。Agent 会先读 Spec 和所有 Ticket，在 SubAgent 里做探索，创建集成分支，然后派出负责实现的 SubAgent 用 TDD 方式去做每一个 Ticket，还会用上 WorkTree。做完后用一个 SubAgent 把成果合并到集成分支，再派更多分支继续，直到所有活干完。最后对集成分支跑 Code Review，清理干净，把 PR 设为待审。

用他的话说，这么大一份 Spec，最后只拿到一个 PR。

SubAgent 是相对「主 Agent」（或称编排 Agent）而言的概念：主 Agent 负责理解用户意图、规划步骤、分派任务，而 SubAgent 是被主 Agent 派生出来的、拥有独立上下文窗口的子进程，专注执行某一个具体子任务。过去的 SubAgent 通常被限制为一次性、无状态、能力较弱的辅助角色，无法再向下派生。当 SubAgent 具备继续派生 SubAgent 的能力后，编排就变成了一种树状结构：主 Agent 派出的 SubAgent 可以再派自己的 SubAgent，每一层只关心自己这一小块问题。这正是 Implement Spec 能自动化执行 Ticket 图的技术前提。

WorkTree 指 Git 的 git worktree 特性，它允许从同一个仓库同时检出多个工作目录，各自对应不同分支。相比传统的「复制一份仓库」或「反复切分支」，WorkTree 让多个并行运行的 SubAgent 拥有互不干扰的文件系统，同时又共享同一份 Git 历史和对象库，合并更干净、磁盘开销更小。这是「能并行就并行」策略能落地的基础设施。

TDD（测试驱动开发） 是一种「先写测试，再写实现，最后重构」的开发节奏。在 Agent 场景下它格外有价值：测试为 Agent 提供了一份可执行的、明确的目标定义，让 Agent 不必依赖模糊的自然语言来判断「做完了没有」。

PR Skill：让代码审查变得轻松

Matt 自称是 Dex Hossi 的铁粉，后者的 Show Me 技能用简洁图表帮用户直观理解话题。受到启发，他做了自己的 PR Skill，目标是尽可能让人工审查变得轻松简单。

这个 Skill 的核心是给了一个写 PR 描述的模板，要求包含三个关键部分：

1. 总结：用 Show Me 风格模板先写一段概要。
2. 证据：改动前后的对比，包括测试、截图和运行时信息。
3. 合并风险：这个 PR 合进去有多危险。

Matt 用了一个很形象的比喻：这是单向门还是双向门？双向门是你还能走回来的，也就是很容易回滚；单向门则会在真实世界产生影响，比如删掉数据，回滚代价很大。如果它是双向门且影响范围小，那这个 PR 其实不用审得太仔细。

为什么证据这么关键？Matt 说，要求 Agent 提供证据，往往意味着它会多跑一个测试、多截一张图，给你运行时信息来证明改动确实在做它以为在做的事。不要求证据的话，Agent 很容易说「应该能用，我看过代码了」。他坦言自己最近对验证这件事越来越执着。

据他观察，PR Skill 是他见过最稳定的、被模型主动调用的 Skill 之一。作为用户完全不用管它，至少在 Opus 5.5 上，它好像每次都会自己调用。

Show Me 风格指的是用结构化图表、缩略示意和代码块把抽象概念可视化的写作方式，它强调「读者能在几秒内抓住结构」，而非堆砌长段落。PR 描述中采用这种风格，目的是让审查者即使对改动背景一无所知，也能快速建立心智模型。

单向门 / 双向门这一比喻来自亚马逊的决策分类框架：双向门指容易回滚的决策，可以快速试错、快速纠正；单向门指难以回滚的决策，一旦执行就在真实世界产生不可逆后果（如删除数据、发版、对外发布）。把这一框架用在 PR 审查上，审查者只需先判断「这是哪一类门」，再决定审查力度——双向门加小范围影响可以快速放行，单向门则需要严格审视。它把「该审多仔细」这个模糊问题转换成了一个可以快速分类的判断题。

领域建模与 Retro：从真实会话里挖问题

在讲 Retro 之前，Matt 提到了一个工作方式的重大变化：domain modeling 技能不再往 context.md 写内容，而是改成写 glossary.md。灵感来自 Eric Evans 的《领域驱动设计》，原文件名 context.md 取自其中的「限界上下文」概念。

但 Matt 觉得 context.md 这个名字「含义过载」、太模糊，没法让 Agent 在该读的时候主动去读，用户看着也迷糊。他把内容一路删减，最后真的只剩一个术语表，所以干脆改名 glossary.md。很多其他 Skill 都需要看到这个文件才能正常工作、才能在每个环节用上领域语言，所以必须记得更新。行为本身没有变化，只是改了文件名。

Retro 到底在做什么

Matt 反思道，自己一直要求用户对仓库做各种长期改动：管理 AGENTS.md、管理 Skill、确保仓库省 token、让环境对 Agent 友好又安全、写好 lint 规则、做好代码导航。后来他意识到，他自己一直在对仓库和 Agent 做这些事情，于是想为什么不打包成一个 Skill——这就是 Retro（Retrospective 回顾）。

Retro 会在一个 Coding Agent 会话上跑，可以是当前会话、现在开着的十个之一、或上一个会话，给出下次可改进的地方。读真实会话的酷处在于，它能看见 Agent 当时到底干了什么，能看到它可能对你的 Skill 藏着的低效之处。

Matt 引用了一句话来形容这个价值：「Agent 抱怨得没它该抱怨的那么多，也不会主动去修自己的错。你得另找一个 agent 回头去看那些会话，看看哪里出了错，看看怎么帮它。」

Agent 在他的会话里发现了这些问题：

• 没等拍板就干了件撤不回的事——找到了 1.3.0 版本缺失的原因，然后没问一声就直接发了版。这就是为什么 releases 里没有 1.3.0 只有 1.3.1。
• 仓库没有任何护栏——有个 PMPM check 脚本但根本没动过。
• 长会话里每次压缩之间都会丢失上下文——建议把反复出现的指令挪进一个动态 Skill 里。

为什么他反对自动化 Retro

Matt 明确表示，几乎每个人看到 Retro 都会说「我想自动化」，但他的回答是「不，你不会想把它自动化的」。

原因很直接：一旦自动化，Agent 就会陷进一个死循环——不停地找到各种误报，不停地去修东西，最后走上一条很怪的路，把仓库和 Agent 带到它们不该去的地方。

Retro 的设计本身就是要有人参与把关的，不是设计来「随便一跑就修」的。Matt 建议挑一部分 Agent 会话来跑 Retro，每当有空、突然想起来好久没跑了，就让它把最近的会话过一遍，或者挑一个出了问题、Agent 干了怪事的会话。

在 Retro Skill 的步骤里，列出了好几类要寻找的改进点：代码库好不好导航、有没有能加的自动检查、能不能加写编码规范让自动审查执行、全局 AGENTS.md 健不健康、工具用得划算吗、指令和引导文件里有没有无效内容、Agent 能不能拿到它需要的所有信息。

Matt 说，坚持定期跑 Retro 后，他的 token 效率和产出质量都大幅提升了。

领域驱动设计（Domain-Driven Design，DDD） 由 Eric Evans 在 2003 年的同名著作中系统提出，核心思想是让软件结构与业务领域的概念模型保持一致，并使用统一的「领域语言」（Ubiquitous Language）贯穿代码、文档和团队交流。其中 限界上下文（Bounded Context） 指一个概念、术语有明确且唯一含义的边界；跨出这个边界，同一个词可能指代完全不同的东西。Matt 原先使用的 context.md 正是取自这一概念，但「上下文」一词在 Agent 语境里同时还能指「上下文窗口」「系统提示」等含义，属于典型的术语过载，因此改为 glossary.md（术语表）反而更精确、更易被 Agent 主动读取。

自动压缩（Auto-compaction） 指当会话的上下文长度接近模型窗口上限时，系统自动总结较早的对话、丢弃原始细节，从而腾出空间继续对话。这是长会话得以维持的机制，但代价是丢失细粒度信息——Matt 在 Retro 中正是把「每次压缩之间上下文丢失」列为需要修复的问题。

三个 Skill 的组合价值

把这三个 Skill 放在一起看，能发现一条清晰的思路：Implement Spec 解决的是如何让 Agent 可靠地完成大块工作，PR Skill 解决的是如何让人快速信任并审查 Agent 的产出，Retro 解决的是如何从真实运行中持续改进整个环境。

前两者偏向执行效率，后者偏向长期演进。而 Matt 对 Retro 自动化的反对，也提示了一个更普遍的原则：涉及判断和取舍的环节，人类把关仍然不可替代。尤其是当自动化会放大误报、把系统带偏的时候，「有人参与」不是保守，而是一种设计上的清醒。