to-ticketslisted

# To Tickets 将计划、spec 或对话拆解为一组 **tickets**——tracer bullet 式的 vertical slices，每张 ticket 声明**阻塞**它的那些 tickets。 issue tracker 与 triage label 词汇应该已经提供给你——若没有，请运行 `/setup-rolex-skills`。 ## 流程 ### 1. 收集上下文 从对话上下文中已有的内容入手。如果用户把某个引用（spec 路径、issue 编号或 URL）作为参数传入，就去获取它，并通读其完整正文与评论。 ### 2. 探索代码库（可选） 如果你尚未探索过代码库，先这样做，以了解代码当前的状态。ticket 标题与描述应使用项目的 domain glossary 词汇，并尊重你将要改动区域内的 ADRs。 留意是否有机会 prefactor 代码，让实现变得更容易。"先把变更变容易，再去做那个容易的变更。" ### 3. 起草 vertical slices 把工作拆解为 **tracer bullet** tickets。 <vertical-slice-rules> - 每个 slice 都要切出一条窄但**完整**贯穿每一层（schema、API、UI、tests）的路径——是 vertical，而不是某一层的 horizontal slice - 完成的 slice 可以独立 demo 或独立验证 - 每个 slice 的大小以能放进一个全新的 context window 为准 - 任何 prefactoring 都应先做 </vertical-slice-rules> 为每张 ticket 给出其 **blocking edges**——在它开始之前必须先完成的其他 tickets。没有 blocker 的 ticket 可以立即开始。 **Wide refactor 是 vertical slicing 的例外。** **wide refactor** 是单一机械变更——重命名一列、重写某个共享符号的类型——其 **blast radius** 波及整个代码库，一次编辑就会同时破坏成千上万个调用点，没有任何 vertical slice 能保持 green。别硬把它塞进 tracer bullet；把它编排成 **expand–contract** 序列。先 expand：在旧形式旁加入新形式，这样什么都不破坏。然后按 blast radius 决定批量大小（按 package、按 directory）将调用点迁移过来，每批都是各自的 ticket、被 expand 阻塞，由于旧形式仍然存在，CI 得以一批接一批保持 green。最后 contract：当不再有调用者时删除旧形式，用一个被所有 migrate 批次阻塞的 ticket 完成。当即便批次本身也无法单独保持 green 时，保留这个序列，但让它们共享一个 integration branch，并让它们共同阻塞一个最终的 integrate-and-verify ticket——green 只在那里被承诺。 ### 4. 追问用户 把提议的拆解方案以编号列表呈现。对每张 ticket，展示： - **Title**：简短描述性的名称 - **Blocked by**：哪些其他 tickets（如果有）必须先完成 - **What it delivers**：这张 ticket 使哪些端到端行为生效 询