to-tickets

name	to-tickets
description	将计划、spec 或当前对话拆分为一组曳光弹式 tickets，每个 ticket 声明其阻塞边，发布到已配置的 tracker —— 对于本地文件，边以文本形式呈现；对于真实 tracker，使用原生阻塞链接。
disable-model-invocation	true

转为 Tickets

将计划、spec 或对话拆分为一组 tickets —— 曳光弹式垂直切片，每个 ticket 声明阻塞它的那些 tickets。

Issue tracker 和 triage 标签词汇表应已提供给你 —— 如果没有，运行 /setup-matt-pocock-skills。

流程

1. 收集上下文

基于对话上下文中已有的内容进行工作。如果用户将某个引用（spec 路径、issue 编号或 URL）作为参数传入，拉取它并读取其完整正文和评论。

2. 探索代码库（可选）

如果尚未探索代码库，进行探索以了解代码的当前状态。Ticket 标题和描述应使用项目的领域词汇表，并尊重所涉及区域的 ADR。

寻找预重构（prefactor）的机会，使实现更简单。"让变更变容易，然后做容易的变更。"

3. 草拟垂直切片

将工作拆分为曳光弹 tickets。

• 每个切片横向切穿每一层（schema、API、UI、测试），是一条窄但完整的路径 —— 是垂直切片，不是某一层的水平切片
• 一个完成的切片可以独立演示或验证
• 每个切片的大小适配单个全新上下文窗口
• 任何预重构应最先完成

为每个 ticket 标注其阻塞边 —— 即必须在它开始之前完成的其他 tickets。没有阻塞边的 ticket 可以立即开始。

宽重构是垂直切片的例外。 宽重构是指一个机械性变更 —— 重命名字段、修改共享符号的类型 —— 其影响范围辐射整个代码库，因此单次编辑会破坏数千个调用点，任何垂直切片都无法以绿色状态落地。不要强行将其塞入曳光弹；应将其排序为扩展-收缩序列。首先扩展：在旧形式旁边添加新形式，使一切不中断。然后按影响范围分批迁移调用点（按包、按目录），每批是一个由扩展阶段阻塞的独立 ticket，保持 CI 逐批绿色，因为旧形式仍然存在。最后收缩：当没有调用方残留时删除旧形式，由一个由所有迁移批次阻塞的 ticket 负责。当连批次本身都无法独立保持绿色时，保持排序不变，但让它们共享一个集成分支，所有批次共同阻塞一个最终的集成验证 ticket —— 绿色仅在该处得到承诺。

4. 与用户核对

以编号列表形式呈现提议的拆分方案。对于每个 ticket，展示：

• 标题：简短的描述性名称
• 被阻塞于：必须首先完成的其他 tickets（如有）
• 它交付什么：此 ticket 使哪些端到端行为可用

询问用户：

• 粒度是否合适？（太粗 / 太细）
• 阻塞边是否正确 —— 每个 ticket 是否只依赖于真正阻碍它的 tickets？
• 是否有 tickets 应合并或进一步拆分？

迭代直到用户批准拆分方案。

5. 将 tickets 发布到已配置的 tracker

发布已批准的 tickets。如何发布取决于 /setup-matt-pocock-skills 配置的 tracker —— 无论哪种方式 tickets 都相同，只有阻塞边的形式不同：

• 本地文件 → 在仓库根目录写入一个 tickets.md，按依赖顺序排列所有 tickets（阻塞者在前），每个 ticket 的"被阻塞于"列出它所依赖的标题。使用下面的文件模板。
• 真实 issue tracker（GitHub、Linear 等） → 按依赖顺序（阻塞者在前）为每个 ticket 发布一个 issue，以便每个 ticket 的阻塞边可以引用真实标识符。使用平台的原生阻塞/子 issue 关系（如果有的话）；否则将每个 ticket 的"被阻塞于"设置为阻塞它的 issues。除非另有指示，应用 ready-for-agent triage 标签 —— 这些 tickets 在构造上就是 agent 可领取的。

不要关闭或修改任何父 issue。

Tickets：<工作的简短名称>

一句话总结这些 tickets 构建的内容。如果有来源 spec，引用它。

从前沿开始工作：找到所有阻塞边已完成的 tickets。对于纯线性链，这意味着从上到下。

<Ticket 标题>

要构建什么： 此 ticket 使哪些端到端行为可用，从用户视角 —— 不是逐层实现清单。

被阻塞于： 阻碍此 ticket 的 tickets 标题，或"无 —— 可立即开始"。

• 验收标准 1
• 验收标准 2

<Ticket 标题>

...

父 issue

对 tracker 上父 issue 的引用（如果来源是已有 issue，否则省略此节）。

要构建什么

此 ticket 使哪些端到端行为可用，从用户视角 —— 不是逐层实现。

验收标准

• 标准 1
• 标准 2

被阻塞于

• 对每个阻塞 ticket 的引用，或"无 —— 可立即开始"。

无论哪种形式，避免具体文件路径或代码片段 —— 它们会很快过时。例外：如果原型产生了一个代码片段，它比文字更精确地编码了一个决策（状态机、reducer、schema、类型结构），将其内联并简要注明来自原型。精简到富含决策的部分 —— 不是可运行的演示，只是关键部分。

使用 /implement 逐个处理前沿上的 tickets，ticket 之间清空上下文。