| name | to-tickets |
| description | 将计划、规范或当前对话拆分为一组 tracer-bullet ticket，每个 ticket 声明其阻塞边（blocking edges），发布到已配置的跟踪器——本地文件中每个 ticket 一个文件以文本表示边，真实跟踪器上以原生阻塞链接表示。 |
| disable-model-invocation | true |
拆分为 Ticket
将计划、规范或对话拆分为一组 ticket——tracer-bullet 垂直切片，每个都声明阻塞它的其他 ticket。
Issue 跟踪器和分类标签词汇表应已提供给你——如果没有，请运行 /setup-matt-pocock-skills。
流程
1. 收集上下文
从对话上下文中已有的内容开始。如果用户传入引用（规范路径、Issue 编号或 URL）作为参数，获取它并读取其完整正文和评论。
2. 探索代码库（可选）
如果你尚未探索代码库，请先了解代码的当前状态。Ticket 标题和描述应使用项目的领域术语表词汇，并尊重你正在接触的区域的 ADR。
寻找预重构代码的机会，使实现更简单。"让改动变得容易，然后再做容易的改动。"
3. 起草垂直切片
将工作拆分为 tracer bullet ticket。
- 每个切片在每个层面（schema、API、UI、测试）提供一条狭窄但完整的通路——垂直，而非某个层面的水平切片
- 一个完成的切片本身是可演示或可验证的
- 每个切片大小适合单个全新的上下文窗口
- 任何预重构应首先完成
为每个 ticket 指定其阻塞边（blocking edges）——必须先完成才能开始的其他 ticket。没有阻塞项的 ticket 可以立即开始。
大范围重构是垂直切片的例外。 大范围重构是一种机械性变更（如重命名列、更改共享符号类型），其影响范围波及整个代码库，一次编辑会同时破坏数千个调用点，导致没有垂直切片能保持绿色。不要强行塞进 tracer bullet；而是通过**扩展-收缩（expand-contract）**来序列化。首先扩展：在旧形式旁边添加新形式，确保没有任何东西被破坏。然后按影响范围大小分批迁移调用点（按包、按目录），每批作为自己的 ticket，被扩展阻塞，由于旧形式仍然存在，CI 在批次之间保持绿色。最后收缩：在所有调用者迁移完毕后删除旧形式，作为一个被所有迁移批次阻塞的 ticket。即使当批次本身无法单独保持绿色时，保留这个序列，但让它们共享一个集成分支，该分支最终阻塞一个集成-验证 ticket——绿色只在那里承诺。
4. 征求用户意见
以编号列表的形式展示提议的拆解方案。对每个 ticket，展示：
- 标题：简短描述性名称
- 被以下阻塞：哪些其他 ticket（如果有）必须先完成
- 交付内容：此 ticket 使哪个端到端行为生效
询问用户：
- 粒度是否合适？（太粗 / 太细）
- 阻塞边是否正确——每个 ticket 是否只依赖真正制约它的 ticket？
- 是否有任何 ticket 需要合并或进一步拆分？
迭代直到用户批准拆解方案。
5. 将 ticket 发布到已配置的跟踪器
发布已批准的 ticket。发布方式取决于 /setup-matt-pocock-skills 配置的跟踪器——ticket 本身相同，只有阻塞边的形式不同：
- 本地文件 → 在
.scratch/<feature>/issues/ 下为每个 ticket 写入一个文件，按编号顺序命名（01-<slug>.md、02-<slug>.md 等），阻塞项在前。每个 ticket 的顶部通过 Blocked by: 行列出其依赖的标题。使用下面的文件模板。
- 真实 Issue 跟踪器（GitHub、Linear 等） → 按依赖顺序每 ticket 发布一个 Issue（阻塞项在前），这样每个 ticket 的阻塞边可以引用真实标识符。在平台支持的地方使用原生阻塞/子 Issue 关系；否则在每个 ticket 的 "Blocked by" 中设置阻塞的 Issue。除非另有指示，应用
ready-for-agent 分类标签——这些 ticket 本身就是 Agent 可抓取的。
不要关闭或修改任何父 Issue。
# <NN> — <Ticket 标题>
**构建内容：** 此 ticket 使哪个端到端行为生效，从用户视角出发——而不是逐层的实现列表。
**被以下阻塞：** 制约此 ticket 的其他 ticket 的编号，或"无——可立即开始"。
## 验收标准
- [ ] 标准 1
- [ ] 标准 2
## 被以下阻塞
- 每个阻塞 ticket 的编号或标题，或"无——可立即开始"。
父 Issue
跟踪器上父 Issue 的引用（如果源是现有 Issue，否则省略此部分）。
构建内容
此 ticket 使哪个端到端行为生效，从用户视角出发——而不是逐层实现。
验收标准
被以下阻塞
- 每个阻塞 ticket 的引用，或"无——可立即开始"。
无论哪种形式，避免具体的文件路径或代码片段——它们很快就会过时。例外：如果原型产出的代码片段比文字更精确地编码了某个决策（状态机、reducer、schema、类型结构），将其内联并简要说明来自原型。精简到决策密集的部分——不是工作演示，只是重要的内容。
每次用 /implement 处理一个前沿 ticket，在 ticket 之间清空上下文。
