to-tickets

转化为工单

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

应已向你提供问题跟踪器和分类标签的词汇表。如果没有，请先运行 set-up-project skill。

流程

1. 收集上下文

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

2. 探索代码库（可选）

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

寻找预先整理代码的机会，让后续实现更容易。“先让改动变容易，再做容易的改动。”

3. 起草纵向切片

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

• 每个切片都要以狭窄但 完整 的路径贯穿每一层（架构、API、UI、测试）：纵向切分，而非 按单层横向切分
• 每个已完成的切片都能独立演示或验证
• 每个切片的规模应适合在一个全新的上下文窗口中完成
• 任何预先整理工作都应先完成

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

提及工单时，始终使用其标题，绝不要只用编号：写成 #12 Add login 或 03: Add login，而不是 #12。分解方案、“阻塞于”字段以及告知用户的任何内容都遵循此规则。

大范围重构 是纵向切分的例外。大范围重构 是指一项机械性改动（例如重命名列、重新声明共享符号类型），其 影响范围 扩展到整个代码库，导致一次编辑会同时破坏成千上万个调用点，无法通过任何纵向切片实现绿色合并。不要强行将其拆成示踪弹；应按 扩展–收缩 的方式安排。首先扩展：在旧形式旁边添加新形式，以免破坏任何内容。然后分批迁移调用点，每批的规模应与影响范围相称（按软件包、按目录）；每批都是一个由扩展工单阻塞的独立工单。由于旧形式仍然存在，各批次之间应保持 CI 绿色。最后收缩：在不再有调用方后，通过一个由所有迁移批次共同阻塞的工单删除旧形式。如果批次本身也无法保持绿色，则保留原有顺序，但让它们共用一个集成分支，并共同阻塞最终的集成与验证工单；只有在该工单中才承诺保持绿色。

4. 征询用户意见

以编号列表的形式展示拟定的分解方案。对每个工单，列出：

• 标题：简短且具有描述性的名称，前缀应符合 docs/agents/issue-tracker.md 中“Title prefixes”的规定
• 阻塞于：必须先完成的其他工单（如有）
• 交付内容：此工单实现的端到端行为

询问用户：

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

反复迭代，直到用户批准该分解方案。

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

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

• 本地文件 → 在 .efforts/<effort>/issues/<NN>-<slug>.md 下为每张工单创建一个文件，与该工作项的 spec.md 放在一起（<effort> 是工作项的名称；如果没有工作项，则使用功能的简短 slug），按依赖顺序从 01 开始编号（先处理阻塞项）。每个文件的“Blocked by”应列出其依赖的工单，包含编号和标题。使用下面的单工单文件模板：每个文件只放一张工单，绝不要合并到一个文件中。
• 真实的问题跟踪系统（GitHub、Linear、…） → 按依赖顺序为每张工单创建一个问题（先处理阻塞项），以便每张工单的阻塞关系可以引用真实标识符。如果平台提供原生阻塞关系／子问题关系，请使用该功能；否则，在每张工单的“Blocked by”中列出阻塞问题。除非另有指示，否则添加 ready-for-agent 分流标签；这些工单按设计即可由 Agent 领取。

处理前沿工单：所有阻塞项均已完成的工单。对于纯线性依赖链，这意味着从上到下处理。

不要关闭或修改任何父问题。

：

要构建的内容： 从用户视角说明此工单将实现的端到端行为，而不是逐层罗列实现步骤。

阻塞项： 阻塞此工单的每张工单的编号和标题，或“无（可立即开始）”。

状态： ready-for-agent

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

父问题

跟踪系统中父问题的引用（如果源自现有问题；否则省略此部分）。

要构建的内容

说明此工单将实现的端到端行为，需从用户视角出发，而非逐层罗列实现步骤。

验收标准

• 标准 1
• 标准 2

阻塞项

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

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