to-tickets

转为工单

将计划、规范或对话拆分成一组工单：每个工单都是一条纵向贯穿的示踪子弹切片，并声明阻塞它的工单。

应已向你提供问题跟踪系统和分诊标签的词汇表。如果没有，请告诉用户运行 /setup-agent-skills。

流程

1. 收集上下文

根据对话中已有的上下文开展工作。如果用户传入了参考资料（规范文件路径、问题编号或 URL）作为参数，请获取该资料，并阅读完整正文和评论。

2. 探索代码库（可选）

如果你还没有探索代码库，请先了解代码的当前状态。工单标题和描述应使用项目的领域词汇表，并遵循你所涉及领域的 ADR。

寻找机会对代码进行预重构，以便简化实现。“先让改动变得容易，再做容易的改动。”

3. 起草纵向切片

将工作拆分为示踪子弹工单。

• 每个切片都应沿着一条狭窄但完整的路径贯穿所有层（架构、API、UI、测试）：采用纵向切片，而不是只切分单一层的横向切片
• 每个切片完成后都能独立演示或验证
• 每个切片的工作量应适合在单个全新的上下文窗口中完成
• 任何预重构都应先完成

为每个工单标注其阻塞关系：必须先完成哪些其他工单，它才能开始。没有阻塞项的工单可以立即开始。

大范围重构是纵向切片的例外。 大范围重构指一项机械性改动（例如重命名列、重新定义共享符号类型），其影响范围遍及整个代码库，因此一次编辑就会导致数千处调用点同时失效，无法通过任何纵向切片以绿色状态合并。不要强行将其拆成示踪子弹；应按扩展—收缩顺序进行。首先扩展：在保留旧形式的同时添加新形式，避免破坏现有代码。然后分批迁移调用点，根据影响范围划分批次（按软件包或目录），每个批次对应一个被扩展工单阻塞的独立工单；由于旧形式仍然存在，CI 应能在每批迁移后保持绿色。最后收缩：在没有调用方继续使用旧形式后，删除旧形式，并创建一个被所有迁移批次阻塞的工单。如果连这些批次也无法单独保持绿色，就保留上述顺序，但让它们共用一个集成分支，并都阻塞最终的集成与验证工单；只有在该工单中才保证绿色。

4. 向用户确认

以编号列表的形式展示拟议的拆分。对每个工单，说明：

• 标题：简短、描述性名称
• 阻塞项：必须先完成的其他工单（如有）
• 交付内容：该工单实现的端到端行为

询问用户：

• 粒度是否合适？（太粗 / 太细）
• 阻塞关系是否正确：每个工单是否只依赖确实会阻塞它的工单？
• 是否应该合并某些工单，或进一步拆分？

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

5. 将工单发布到已配置的跟踪系统

发布已批准的工单。具体方式取决于 /setup-agent-skills 配置的跟踪系统；工单内容相同，只有阻塞关系的表示方式不同：

• 本地文件 → 在 .scratch/<feature-slug>/issues/<NN>-<slug>.md 下为每个工单写入一个文件，按依赖顺序从 01 开始编号（先处理阻塞项）。每个文件的“阻塞于”字段列出它所依赖的工单编号／标题。使用下面的单工单文件模板：每个文件只放一个工单，绝不合并到同一个文件中。
• 真实的问题跟踪系统（GitHub、Linear 等） → 按依赖顺序（先处理阻塞项）为每个工单发布一个问题，这样每个工单的阻塞关系都能引用真实标识符。如果平台支持原生阻塞／子问题关系，请使用该关系；否则，在每个工单的“阻塞于”字段中填写阻塞它的问题。除非另有说明，否则添加 ready-for-agent 分类标签；这些工单的设计本身已确保 Agent 可以直接领取。

按前沿推进：阻塞项均已完成的工单即可处理。若依赖链完全线性，则按从上到下的顺序处理。

切勿关闭或修改任何父问题。

：

要构建的功能： 从用户视角描述此工单要实现的端到端行为，而不是按层罗列实现步骤。

阻塞于： 阻止此工单开始的工单编号／标题，或“无（可立即开始）”。

状态： ready-for-agent

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

父问题

跟踪系统中父问题的引用（如果来源是现有问题；否则省略本节）。

要构建的功能

描述此工单要实现的端到端行为，从用户视角出发，而不是按层罗列实现步骤。

验收标准

• 标准 1
• 标准 2

阻塞于

• 每个阻塞工单的引用，或“无（可立即开始）”。

无论使用哪种格式，都要避免写入具体文件路径或代码片段：它们很快就会过时。例外情况：如果原型生成的片段比文字更精确地表达了某项决策（状态机、reducer、架构、类型形状），可以将其内联，并简要说明它来自原型。只保留能明确表达决策的部分，不要放入可运行的演示，只保留重要内容。