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	机械性、低判断要求的工作：配置升级、文案修改、影响范围较小的重命名、添加与现有测试模式相似的测试	Sonnet（Claude Code）/ Sonnet（Cursor）

根据工单所需的判断力而非 diff 大小来评估：部署流水线中的一行改动属于 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、架构、类型结构），则可将其内联，并简要注明该片段来自原型。只保留体现关键决策的部分，不要贴出可运行的演示，只需保留重要内容。