安装此技能
npx skills@latest add mattpocock/skills --skill=to-tickets 然后在你的编码 agent 里输入 /to-tickets 。
本页目录
它做什么
to-tickets 拿到一个计划、一份规范文档（spec），或者你正在进行的这场对话，把它拆成你 issue 追踪器上的一组**工单（tickets）。每个工单都声明自己的阻塞边（blocking edges）**：也就是必须先完成、它才能开始的其他工单。
每个工单都是一枚曳光弹（tracer bullet）：一条窄却完整的路径，穿过这次改动的每一层（schema、API、UI、测试），一旦落地，你就能单独演示它。这正是这个技能与那种显而易见的分工方式的不同之处——按层切、最后再集成。它还把每个工单的大小定在能装进一个全新的上下文窗口（context window）里，因为接下来拿起这个工单的，会是一场从未见过你规范文档的会话（session）。
什么时候用它
你通过输入 /to-tickets 来调用它。agent 不会主动去拿它。
| 你在哪里 | 该运行什么 |
|---|---|
| 你有一个规范文档 issue，而构建跨越好几场会话 | /to-tickets，或者 /to-tickets #<spec_issue> |
| 计划只在对话里，从未写成文 | /to-tickets 直接读讨论串，不需要规范文档 |
| 整个改动装得下一个上下文窗口 | implement，跳过工单 |
| 还什么都没决定 | grill-with-docs，然后是 to-spec |
| 一张 wayfinder 地图已经理清 | 先用 to-spec 把地图收拢，然后 /to-tickets |
to-tickets 产出的工单，从构造上就是 agent 可以直接开工的。不要对它们跑 triage。分诊是给从别人那里来的工作用的。
前提条件
to-tickets 往追踪器里发布，所以 setup-matt-pocock-skills 必须已经为这个仓库配置好一个追踪器，以及分诊标签词汇。两种都行：像 GitHub 或 Linear 这样的真实追踪器，或者 .scratch/ 下的本地 Markdown 文件——后者不需要任何额外配置就能用。
曳光弹，而不是分层
一个**水平（horizontal）切片只交付改动的一层。在每一层都落地之前，什么都不能用，而每个工单的验收标准（acceptance criteria）还得伸进另一个工单负责的工作里。一个垂直（vertical）**切片（也就是曳光弹）一次交付穿过所有层的一条细路径，所以它可以单独验证，并且对自己验收的一切负责。
这是人们最常打破的规则。有一个团队跑了一摞 26 个工单，按层切分（语料库、生产者、聚合器、选择器），结果每关闭一个工单大约要跑二十次 agent，其中约四分之三是返工。他们自己的复盘把每一类失败都追溯到了水平切分，而不是实现本身。
在任何东西发布之前，会发生两件事。to-tickets 会寻找预先重构（prefactoring）（原则是「先让改动变容易，再做容易的改动」），并把那部分工作排在最前面。然后它把拆解结果作为编号列表呈现给你，并就它考问你：粒度对吗，阻塞边是真的吗，有没有哪项该合并或拆分。在你批准之前，没有任何东西会进入追踪器，而这场考问正是你提出反对的地方。
阻塞边
这些边才是产物的重点。它们以两种方式起作用，取决于追踪器：
| 追踪器 | 边住在哪里 | 你怎么处理它们 |
|---|---|---|
| 本地 Markdown | .scratch/<feature>/issues/<NN>-<slug>.md 下每个工单一个文件，以文本形式写明，按阻塞者优先编号 | 从上到下，手工处理 |
| 真实追踪器（GitHub、Linear） | 原生的阻塞链接；如果追踪器支持子 issue（sub-issue），则用子 issue | 任何阻塞者都已完成的工单都在**前沿（frontier）**上，可以被拿走 |
不管哪种方式，边都住在工单里。追踪器只决定是否有东西能并行地利用它们。to-tickets 产出产物；运行它（一次一场会话，或者一支队伍并行）是你的工作，不是技能的工作。
大范围重构的例外
有一种形状会打破曳光弹规则。一次**大范围重构（wide refactor）是一次机械改动（重命名一列、改变一个共享符号的类型），它的爆炸半径（blast radius）**覆盖整个代码库。一处编辑会弄坏成千上万个调用点，所以没有任何垂直切片能以绿色落地。
to-tickets 改为按**扩展—收缩（expand–contract）**来排期：
- 扩展：在旧形式旁边加上新形式，这样什么都不会坏。
- 迁移：按爆炸半径划定批次（按包、按目录）把调用点搬过去，每批一个工单，每个工单都被扩展那一步阻塞。CI 保持绿色，因为旧形式仍然存在。
- 收缩：在没有调用者之后删除旧形式，放在一个被所有迁移批次阻塞的工单里。
如果连这些批次也无法各自保持绿色，就让它们共享一个集成分支，并全部阻塞一个最后的集成与验证工单。CI 只需要在那个工单处是绿色的。
常见问题
一次三行的改动，它产出了十二个工单。 过度拆分是关于这个技能报告得最多的问题，很多用户都遇到过。模型（model）会默认按原子单位来切，丢掉了那些能让它们有意义的归组。考问那一步就是你修正它的地方。让它合并工单，它就会合并。这里也有一个下限。如果整个改动装得下一个上下文窗口，你根本不需要这个技能。直接去 implement。
工单出来时一层一个：所有 schema 在一个工单里，所有 API 在另一个里。 这正是垂直切片规则要防的失败，而这个技能有时仍然会产出它。在考问那一步抓住它，对每个工单问一个问题：这个做完之后我能演示什么？回答不上来的工单就是水平切片。有些人因为这个原因，给每个工单加一行「演示路径」，并报告说这会把模型推向垂直切片。
在 GitHub 上，这些工单没有被创建为规范文档 issue 的子 issue。
这个问题在十几次运行、好几个模型上被报告过，最完整的记录在 issue #554。已修复：to-tickets 现在会把每个工单设为其来源 issue 的子 issue（sub-issue），GitHub 追踪器模板也给出了命令（gh issue create --parent <n>，gh 2.94+）。重跑 setup-matt-pocock-skills 来刷新旧的 docs/agents/issue-tracker.md。
「Blocked by」被写进了 issue 正文，而不是一个真正的阻塞链接。
这是同一类问题，记录在 issue #513 里，那里 agent 甚至声称 GitHub 根本没有原生的阻塞关系。它有：gh issue create --blocked-by 12,15。因为技能先发布阻塞者，它们的编号在创建时总是可用的。正文文字本是给没有原生边的追踪器用的兜底，不是默认做法。现在当边是原生的时候，工单模板会省略 ## Blocked by。
本地工单去哪里？v1.1 的说明说是根目录下的 tickets.md。
确实说过，那是个 bug。当并行的 agent 往同一个共享文件里写时，单一文件还会造成竞态条件。本地模式现在在 .scratch/<feature-slug>/issues/<NN>-<slug>.md 下每个工单写一个文件，按依赖顺序排列，与本地追踪器模板早已描述的布局一致。NN 前缀是真正的工单 ID，所以 /implement 03 能用，不必重新敲一个长标题。
它试图读我的规范文档时总是被截断。
一份非常大的规范文档可能超出追踪器 issue 能干净返回的限度。没有本地副本可以退而求其次，所以 agent 会把工具调用（tool calls）花在反复抓取分块上，永远到不了结尾。不要在 /to-spec 和 /to-tickets 之间清除（clearing）或压缩（compaction）。在同一场上下文窗口里运行它们，agent 就永远不必再取一次规范文档。
验收标准什么都没判定：有些在任何工作开始之前就已经通过了。 模板要求写验收标准，却只字不提它们是否可能失败，所以就会这样。有三种形状反复出现：一条标准在基线提交上已经为真；一条标准只有另一个工单里的工作才能满足；还有一条只是复述需求，而不是从产物推导出来。垂直切片能防住大部分，因为一个交付新行为的切片，按构造就会在基线提交上失败。这项检查仍然值得手工做一遍。对每条标准，说出能证明它为假的观察，并确认它在实现者开始的那个提交上会失败。
工单已经发布了。我到底该怎么跑它们？ 技能止于产物，没有自动派发模式。派发是手工的：看一眼看板，数一数没有未完成阻塞者的工单，然后开同样数量的 agent 会话。给每个工单一个全新的上下文，并在它们之间清除。无论在 GitHub 还是本地 Markdown 上，implement 完成时都不会可靠地关闭或勾掉工单，所以工单状态要你自己更新。
它生效的标志
- 每个工单都能回答「这个做完之后我能演示什么？」，而且答案是行为，不是一层。
- 在任何东西发布之前，列表以编号形式回到你手上，每个工单都有一行「Blocked by」。
- 最上面的工单没有阻塞者，可以立刻开始。
- 工单正文里没有文件路径或行号，除非是原型产出的一段代码。
- 每个工单读起来都像一场全新的会话能在你不在场的情况下完成的事。
- 预先重构，如果它找到了的话，排在最前面，而不是混进功能工单里。
它在体系中的位置
to-tickets 是主构建链上的一步：
grill-with-docs → to-spec → to-tickets → implement → code-review → retro
上游是 to-spec，它交给这个技能一份已经定下来的规范文档，供其切分。把两者保持在同一个上下文窗口里，中间不要清除。下游是 implement，它每场全新会话构建一个工单，为测试驱动 tdd，并以 code-review 收尾。implement-spec 是下游的另一条路。它把同一套阻塞边读成一张任务图，在一个集成分支上并行构建每一个已经就绪的工单。当你不确定哪个技能或哪条流程合适时，ask-matt 会为你路由。