用途
to-tickets 用于把一份计划、规格说明（spec）或当前对话内容，拆解成一组工单（tickets）。这些工单是「曳光弹式」的纵向切片：每个切片都贯穿所有层（schema、API、UI、测试），是一条窄但完整的路径，而不是某一层的横向切片。每个工单都会声明自己的阻塞边，即必须先完成哪些其他工单才能开始。
主要能力
- 从对话上下文或用户传入的引用（spec 路径、issue 编号或 URL）中收集上下文，并读取其完整正文与评论。
- 可选地探索代码库，理解代码现状；工单标题与描述应使用项目的领域术语表词汇，并遵守相关区域的 ADR。
- 寻找预重构（prefactor）机会，让后续实现更容易。
- 把工作拆成纵向切片：每个切片贯穿所有层、可独立演示或验证、大小适合放进一个全新的上下文窗口；预重构应最先完成。
- 为每个工单标注阻塞边：没有阻塞的工单可以立即开始。
- 对「宽重构」采用例外处理：按 expand–contract 顺序排列，先扩展（在旧形式旁新增新形式），再分批迁移调用点，最后收缩（删除旧形式）。
- 以编号列表向用户展示拆分方案，逐条显示标题、被谁阻塞、交付什么，并询问粒度是否合适、阻塞边是否正确、是否需要合并或拆分，迭代直到用户批准。
- 把批准的工单发布到已配置的追踪器。
使用方式
该技能假定 issue tracker 与 triage 标签词汇已经提供；如果没有，需要先运行 /setup-utarn-skills。
流程分为五步：
- 收集上下文：基于对话中已有内容工作；若用户传入引用，则抓取并阅读其完整正文与评论。
- 探索代码库（可选）：若尚未探索，则了解代码现状；工单标题与描述使用项目领域术语表词汇，并遵守相关 ADR；寻找预重构机会。
- 起草纵向切片：拆成曳光弹工单，每个切片贯穿所有层、可独立演示或验证、适合单个上下文窗口；预重构最先做；为每个工单标注阻塞边。宽重构按 expand–contract 排序。
- 向用户提问：以编号列表展示拆分方案，逐条显示标题、被谁阻塞、交付什么；询问粒度是否合适、阻塞边是否正确、是否需要合并或拆分；迭代直到用户批准。
- 发布工单到已配置的追踪器：
- 本地文件：在
.scratch/<feature-slug>/issues/<NN>-<slug>.md下每个工单写一个文件，按依赖顺序从 01 编号（阻塞者在前）；每个文件的「Blocked by」列出所依赖的编号/标题；每个工单一个文件，绝不合并成单个文件。 - 真实 issue tracker（GitHub、Linear 等）：按依赖顺序（阻塞者在前）每个工单发布一个 issue，以便阻塞边引用真实标识符；平台有原生阻塞/子 issue 关系时使用它，否则把每个工单的「Blocked by」设为阻塞它的 issue；除非另有指示，应用 ready-for-agent triage 标签。
- 本地文件：在
推进方式：处理前沿（frontier），即所有阻塞者都已完成的工单；对于纯线性链，就是从顶到底。不要关闭或修改任何父 issue。
工单模板包含：What to build（从用户视角描述的端到端行为，而非逐层实现清单）、Blocked by（阻塞它的工单编号/标题，或「None — can start immediately」）、Status（ready-for-agent）、验收标准、Parent（若来源是已有 issue，则引用追踪器上的父 issue，否则省略该节）。
两种形式都应避免具体文件路径或代码片段，因为它们很快会过时。例外：如果原型产出的片段比文字更精确地编码了某个决策（状态机、reducer、schema、类型形状），可以内联并简要注明来自原型，只保留决策密集的部分。
适用场景
- 需要把计划、规格说明或对话内容转化为可被智能体逐个领取的开发任务。
- 希望任务按依赖顺序推进，且每个任务都能独立演示或验证。
- 需要处理贯穿整个代码库的宽重构，并保持 CI 绿色。
限制
- 需要预先配置 issue tracker 与 triage 标签词汇，否则需先运行
/setup-utarn-skills。 - 工单应避免具体文件路径或代码片段，以免过时。
- 宽重构不能强行套用曳光弹切片，必须按 expand–contract 顺序处理。
- 当分批迁移无法单独保持绿色时，需要共享集成分支，并由最终的 integrate-and-verify 工单统一保证绿色。
- 不要关闭或修改任何父 issue。