to-tickets

拆分交付工单

把一份计划、spec（规格说明）或对话拆成一组工单（ticket）：曳光弹（tracer-bullet）式的垂直切片（vertical slice），每张都声明阻塞它的那些工单。

工单系统（issue tracker）和分诊（triage）标签词汇本应已经提供给你。如果没有，请让用户运行 /setup-engineering-skills。

流程

1. 收集上下文

以对话上下文中已有的内容为基础工作。如果用户把一个引用（spec 路径、issue 编号或 URL）作为参数传入，就获取它并阅读其完整正文和评论。

2. 探索代码库（可选）

如果你还没有探索过代码库，请探索一下以了解代码现状。工单的标题和描述应使用项目领域词汇表中的用语，并尊重你所改动区域内的 ADR（架构决策记录）。

寻找预重构（prefactor）代码的机会，让实现更容易。"先让改动变容易，再做那个容易的改动。"

3. 起草垂直切片

把工作拆成曳光弹工单。

• 每个切片都纵向贯穿每一层（schema、API、UI、测试），切出一条窄但完整的通路：是垂直切片，不是某一层的水平切片
• 完成的切片可独立演示或验证
• 每个切片的规模以一个全新上下文窗口装得下为限
• 每个功能切片至少让一个父规格中的验收用例从未满足变为可独立证明；不要把全部测试和全部实现拆成两个水平工单
• 单元/模块测试、集成测试和系统验收按它们独立证明的事实分配，不在每层复制同一个断言
• 任何预重构都应最先完成

给每张工单配上它的阻塞边（blocking edge）：必须先完成、它才能开工的那些工单。没有阻塞者的工单可以立即开始。

宽重构是垂直切片的例外。 **宽重构（wide refactor）是一次机械性变更（重命名一个列、改一个共享符号的类型），其影响面（blast radius）呈扇形扩散到整个代码库，以至于一次编辑就同时破坏成千上万个调用点，没有任何垂直切片能落地保持绿色。不要硬把它塞进曳光弹；按扩展–收缩（expand–contract）**编排。先扩展：把新形式加在旧形式旁边，保证什么都不破坏。然后按影响面分批（按包、按目录）迁移调用点，每一批是自己的一张工单，被扩展工单阻塞；因为旧形式仍在，CI 逐批保持绿色。最后收缩：一旦再无调用方，就删除旧形式，这张工单被所有迁移批次阻塞。当连单批都无法独自保持绿色时，保留这个顺序，但让它们共享一个集成分支，全部阻塞一张最终的"集成并验证"工单；只有在那里才承诺绿色。

出现临时兼容、双写、Feature Flag 或新旧接口并存时，必须有一张明确的收缩/删除工单。不能只创建扩展和迁移工单，把垃圾回收留给“以后”。

4. 向用户提问

把提议的拆分呈现为编号列表。对每张工单展示：

• 标题：简短的描述性名称
• 阻塞于：还有哪些工单（若有）必须先完成
• 交付什么：这张工单使其跑通的端到端行为
• 验收用例：它负责哪些 AC-*，或在没有父规格时写出本地 Given/When/Then
• 验证证据：模块、集成、系统或架构检查分别证明什么
• 退出条件：它引入或删除哪些临时结构（若有）

向用户确认：

• 粒度感觉合适吗？（太粗 / 太细）
• 阻塞边是否正确：每张工单是否只依赖真正卡住它的工单？
• 是否有工单该合并或进一步拆分？
• 每个验收用例是否都有唯一的主要交付工单？
• 所有临时结构是否都有负责删除的工单？

迭代直到用户认可这个拆分。

5. 把工单发布到已配置的工单系统

发布已认可的工单。怎么发取决于 /setup-engineering-skills 配置的是哪种工单系统；两种方式下工单本身并无差别，变的只是阻塞边的形态：

• 本地文件 → 在 .scratch/<feature-slug>/issues/<NN>-<slug>.md 路径下每张工单写一个文件，按依赖顺序（阻塞者在前）从 01 开始编号。每个文件的"阻塞于"列出它依赖的工单编号/标题。使用下面的单工单文件模板：一张工单一个文件，绝不写成一个合并的大文件。
• 真实工单系统（GitHub、Linear、…） → 按依赖顺序（阻塞者在前）每张工单发布一个 issue，让每张工单的阻塞边能引用真实标识符。平台若有原生的阻塞 / 子 issue 关系就用它；否则把每张工单的"阻塞于"设为阻塞它的那些 issue。除非另有指示，打上 ready-for-agent 分诊标签；这些工单在构造上就是 agent 可直接认领的。