to-tickets

转换为工单

将计划、规范或对话拆分为一组工单：每个工单都是一条垂直切片式的示踪弹路径，并声明哪些工单会阻塞它。

如果需要分类标签或工单跟踪约定，但当前缺少这些内容，请运行 /setup-skills。下文的目标位置解析无需设置。

流程

1. 收集上下文

基于对话中已有的上下文开展工作。如果用户在参数中提供了引用（规范路径、问题编号或 URL），请获取并阅读其完整正文和评论。

2. 探索代码库（可选）

如果你尚未探索代码库，请进行探索，以了解代码当前状态。工单标题和描述应使用项目领域术语表中的词汇，并遵循你要修改部分的 ADR。

留意能否预先重构代码，让实现更容易。“先让改动变容易，再做容易的改动。”

3. 起草垂直切片

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

• 每个切片都应以狭窄但完整的路径贯穿每一层（架构、API、UI、测试）：采用垂直切片，而非只切分某一层的水平切片
• 每个已完成的切片都能独立演示或验证
• 每个切片的规模应适合在单个全新的上下文窗口中完成
• 应先完成任何预先重构

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

大范围重构是垂直切片的例外。 大范围重构是指一项机械性改动（例如重命名列、修改共享符号的类型），其影响范围遍及整个代码库，因此单次编辑就会同时破坏数千处调用点，无法通过任何垂直切片以绿色状态合并。不要强行将其拆成示踪弹；应按扩展—收缩的顺序安排。首先扩展：在旧形式旁添加新形式，确保不会破坏任何内容。然后分批迁移调用点，批次规模按影响范围划分（按包、按目录）；每个批次单独作为一个工单，并依赖扩展工单。由于旧形式仍然存在，各批次之间都应保持 CI 绿色。最后收缩：在所有调用方都完成迁移后，删除旧形式；该工单应依赖每个迁移批次。如果连单独的批次都无法保持绿色，就保留这一顺序，但让它们共用一个集成分支，并全部依赖最终的集成与验证工单；只有在该工单中才承诺保持绿色。

4. 评估每个工单的难度

为每个工单指定一个难度等级，并为接手者推荐一个模型。推荐仅供参考，并非强制要求：读者可能使用 Claude Code、Cursor 或其他工具，因此应分别按工具推荐模型，让他们自行替换。

等级	适用内容	推荐模型
Heavy	基础设施、部署、迁移、架构决策、安全边界、大范围重构，以及任何影响范围跨越多个子系统的工作	Opus（Claude Code）/ Opus 或可用的最强推理模型（Cursor）
Standard	常规编程逻辑：功能切片、端点、组件，以及涉及实际分支逻辑的 Bug 修复。默认等级，也是大多数工单适用的等级	Sonnet（Claude Code）/ Sonnet（Cursor）
Light	机械性、低判断要求的工作：配置升级、文案修改、影响范围较小的重命名、添加与现有测试类似的测试	Haiku（Claude Code）/ claude-4.5-haiku-thinking（Cursor）

评估工单所需的判断力，而不是差异大小：部署流水线中的一行改动也属于 Heavy；遵循现有模式的 400 行组件则属于 Standard。如果某个工单介于两个等级之间，请选择较高等级。如果一轮中的大多数工单都评为 Heavy，那么切片很可能过于宽泛，请重新审视步骤 3。

5. 展示拆分结果

用编号列表展示拟议的拆分。对于每个工单，列出：

• 标题：简短且具有描述性的名称
• 难度：等级和建议使用的模型
• 阻塞项：必须先完成的其他工单（如有）
• 交付内容：此工单要实现的端到端行为

发布前不要请求确认。 展示列表后立即发布：不要停下来询问“这样可以吗？”。只有在用户明确要求本次运行中先审核或批准拆分时，才先暂停并与用户迭代。

6. 发布工单

确定发布位置：不要询问。 静默选择：

1. 如果用户在本次运行中明确要求发布到 GitHub、GitLab、本地 Markdown 或其他跟踪系统：使用该位置。
2. 否则，如果 docs/agents/issue-tracker.md 存在（由 /setup-skills 写入）且指定了跟踪系统：使用该系统。
3. 否则：本地 Markdown。不要检查 git remote。不要让用户选择发布位置。

无论采用哪种方式，工单内容都相同；只有阻塞关系的表示方式不同：

• 本地 Markdown → 按依赖顺序（先列阻塞项），从 01 开始编号，每个工单写入 .scratch/<feature-slug>/tickets/<NN>-<slug>.md 下的一个文件。每个文件的“阻塞项”列出其依赖项的编号和标题。使用下面的单工单文件模板：每个文件一个工单，绝不合并到单个文件中。
• 真实的跟踪系统（GitHub、GitLab、Linear 等） → 按依赖顺序（先列阻塞项）逐个发布工单，以便每个工单的阻塞关系都能引用真实标识符。存在 docs/agents/issue-tracker.md 时，遵循其中的说明。若平台支持，使用平台原生的阻塞关系／子工单关系；否则，在每个工单的“阻塞项”中列出阻塞工单。如果来源是现有工单，则将每个工单创建为其子工单（按跟踪系统文档中的操作执行）。除非另有说明，否则添加 ready-for-agent 分类标签：这些工单本身已可供 Agent 领取。

处理当前可推进项：所有阻塞项均已完成的工单。若依赖关系是纯线性链，则按从上到下的顺序处理。

不要关闭或修改任何父工单。

# <NN>: <Ticket title>

> **Difficulty:** Heavy | Standard | Light: **suggested model:** <model> (Claude Code) / <model> (Cursor). Suggestion only, use whatever model you have to hand.

**Spec:** the path of the spec this ticket comes from, relative to this ticket file (with the default layout, `../SPEC.md`). Omit the line only when no spec file exists (the plan came from the conversation).

**What to build:** the end-to-end behaviour this ticket makes work, from the user's perspective, not a layer-by-layer implementation list.

**Seams:** the seams from the spec's Testing Decisions that this ticket exercises, one per bullet. If the ticket tests no seam (for example a pure config change), write "None" explicitly. Never leave the line out.

**Blocked by:** the numbers/titles of the tickets that gate this one, or "None (can start immediately)".

Status: ready-for-agent

- [ ] Acceptance criterion 1
- [ ] Acceptance criterion 2

难度： Heavy | Standard | Light：建议使用的模型： （Claude Code）/ （Cursor）。仅供建议，请使用手头可用的模型。

难度行必须是工单正文的第一项，位于所有章节之前。

父工单

跟踪系统中父工单的引用（如果来源是现有工单；否则省略此章节）。

要构建的内容

从用户的角度描述此工单要实现的端到端行为，而不是逐层描述实现方式。

接缝

列出此工单涉及的规范中“测试决策”部分所述的接缝，每项一条。如果工单不测试任何接缝，明确写“无”。不得省略此章节。

验收标准

• 标准 1
• 标准 2

阻塞项

• 引用每个阻塞工单，或写“无（可立即开始）”。如果阻塞关系已设置为原生关系，则省略此章节。

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