| 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 标题,或"无 —— 可立即开始"。
<Ticket 标题>
...
父 issue
对 tracker 上父 issue 的引用(如果来源是已有 issue,否则省略此节)。
要构建什么
此 ticket 使哪些端到端行为可用,从用户视角 —— 不是逐层实现。
验收标准
被阻塞于
- 对每个阻塞 ticket 的引用,或"无 —— 可立即开始"。
无论哪种形式,避免具体文件路径或代码片段 —— 它们会很快过时。例外:如果原型产生了一个代码片段,它比文字更精确地编码了一个决策(状态机、reducer、schema、类型结构),将其内联并简要注明来自原型。精简到富含决策的部分 —— 不是可运行的演示,只是关键部分。
使用 /implement 逐个处理前沿上的 tickets,ticket 之间清空上下文。