---
name: to-tickets
description: 将计划、规格或当前对话拆成一组声明前置依赖的端到端最小闭环任务（曳光弹），并发布到已配置的 issue 追踪器。
disable-model-invocation: true
---

# 拆分开发任务

把计划、规格或对话拆成一组**开发任务**（tickets）：范围窄但完整穿透各层的端到端最小闭环任务（tracer bullet），每项任务明确列出它的**前置依赖**（必须先完成的任务）。

issue 追踪器和分诊标签词汇应该已经提供给你。如果没有，告诉用户运行 `/setup-dev-skills`。

## 流程

### 1. 收集上下文

以对话中已有的内容为准。如果用户通过参数传入了引用（规格路径、issue 编号或 URL），读取它的完整正文和所有评论。

### 2. 探索代码库（可选）

如果尚未探索过代码库，先探索以了解代码现状。任务标题和描述应当使用项目术语表中的词汇，并遵守涉及区域的 ADR。

寻找可以先做的预备性重构，让后续实现变容易：“先让改动变容易，再做容易的改动”。

### 3. 起草纵向切分任务

把工作拆成**端到端最小闭环任务**（曳光弹切片）。

<vertical-slice-rules>

- 每项切片范围窄，但**完整**穿过每一层（schema、API、UI、测试）：按功能纵向切分，而非横向按层切分
- 完成后的切片本身可独立演示或验证
- 每项任务的规模适宜在单个全新的上下文窗口内完成
- 任何预备性重构都应当排在最前面

</vertical-slice-rules>

为每项任务明确它的**前置依赖**：即开始该任务之前必须完成的其他任务。没有前置依赖的任务可以立即开始。

**大范围重构是纵向切分的例外。**所谓**大范围重构**，是指一次机械性改动（重命名一列、修改共享符号的类型），其影响范围波及整个代码库，导致单次修改同时破坏成千上万个调用点，没有任何纵向切分能保持测试通过。不要强行将其塞入单一切片，而应按**先扩展、再迁移、后收缩**（扩展-迁移-收缩模式）推进：首先扩展，在旧形式旁边引入新形式，不破坏任何现有代码；然后按影响范围分批迁移调用方（按包、按目录），每批作为一个独立任务并依赖扩展任务，由于旧形式仍存在，批次之间保持测试通过；最后收缩，在所有调用方迁移完毕后清理旧形式，该任务依赖所有迁移批次。若连分批迁移都无法独立保持测试通过，仍然保留该顺序，但让它们共享一个集成分支，统一作为最后“集成与验证”任务的前置依赖，并在那里保证全部测试通过。

### 4. 与用户逐项核对切分方案

将拟定的任务拆分以编号列表展示给用户。每项任务列出：

- **标题**：简短的描述性名称
- **前置依赖**（Blocked by）：哪些任务必须先完成（如有）
- **交付内容**：这项任务让哪段端到端行为可以工作

向用户核对以下问题：

- 任务粒度是否合适（太粗还是太细）？
- 前置依赖是否准确：每项任务是否只依赖真正制约它的前置任务？
- 是否有需要合并或进一步拆分的任务？

根据反馈迭代，直到用户认可拆分方案。

### 5. 发布任务到已配置的追踪器

发布用户认可的任务。**发布方式**取决于 `/setup-dev-skills` 配置的追踪器类型；无论哪种形式，任务本身相同，只是前置依赖的表达方式不同：

- **本地文件**：每项任务在 `.scratch/<功能-slug>/issues/<NN>-<slug>.md` 下写入一个文件，按依赖顺序（前置任务在前）从 `01` 开始编号。每个文件的“Blocked by”列出其依赖的任务编号或标题。使用下方的本地任务模板：一项任务一个文件，切勿合并为单个大文件。
- **真实 issue 追踪器（GitHub、Linear 等）**：按依赖顺序（前置任务在前）为每项任务发布一个 issue，以便前置依赖引用真实的 issue 标识。平台具备原生依赖关联或子 issue 功能时直接使用；否则在每个任务的“Blocked by”中引用制约它的 issue。除非另有指示，附上 `ready-for-agent` 分诊标签；这些任务在设计上就已达到 agent 可直接领取的标准。

按**当前可执行任务**（就绪任务）推进：任何所有前置任务均已完成的任务均可开始。对于纯线性依赖链，即从上到下依次执行。

切勿关闭或修改任何父 issue。

<local-ticket-template>

# <NN>: <任务标题>

**要构建什么：** 这项任务让哪段端到端行为可以工作。从用户视角描述，而非逐层的实现细节清单。

**前置依赖：** 阻塞该任务的前置任务编号/标题，或“无（可立即开始）”。

**状态：** ready-for-agent

- [ ] 验收标准 1
- [ ] 验收标准 2

</local-ticket-template>

<issue-template>

## 父 issue

追踪器上父 issue 的引用（若来源是已有 issue；否则省略本节）。

## 要构建什么

这项任务让哪段端到端行为可以工作。从用户视角描述，而非逐层的实现细节清单。

## 验收标准

- [ ] 验收标准 1
- [ ] 验收标准 2

## 前置依赖

- 阻塞该任务的每个前置任务引用，或“无（可立即开始）”。

</issue-template>

无论哪种形式，都应避免具体的代码文件路径或代码片段：它们很快就会过时。例外：如果原型产出的片段（状态机、reducer、schema、类型结构）比文字更准确地表达了决策，可以将其内联并简要注明来自原型。只截取体现关键决策的部分，不要放完整的演示代码。