To Tickets - 把计划拆成曳光弹工单

技能概述

To Tickets 是一个把计划、规格文档或当前对话内容，拆解成一组「曳光弹工单」（tracer bullet tickets）的技能：每张工单都是一条贯穿各层的完整垂直切片，并明确声明自己依赖哪些工单，最后按依赖顺序发布到你配置的任务追踪器里。

适用场景

1. 拿到方案后需要落地成任务：你已经写好技术方案或 PRD，甚至已经在对话里和 AI 讨论清楚了要做什么，但面对一份长文档不知道从哪一刀切下去。To Tickets 会把它拆成一组边界清晰、彼此有依赖关系的工单，直接进入待开发状态。

2. 多人协作需要划清任务边界：几个人并行开发同一个功能时，最难的不是写代码，而是说清楚「谁先做、谁等谁」。每张工单都标注了阻塞它的前置工单，没有阻塞的工单可以立刻开工，有阻塞的一眼就能看出在等什么。

3. 大型重构不敢一次改完：像改字段名、改共享类型这种一处改动会波及成千上万个调用点的宽重构，硬塞进一个垂直切片只会让 CI 一直红着。To Tickets 会把它排成「先扩展、再分批迁移、最后收缩」的序列，让每一批都能单独保持绿色。

核心功能

1. 垂直切片拆分，而不是按层切：每张工单都是一条窄而完整的路径，从数据结构、接口到界面和测试一次性打通，做完就能演示或验证。它不会给你「先做完所有数据库改动，再做完所有接口」这种横向切法——那种切法在任何一层做完时都拿不出可验证的成果。每张工单的体量控制在一个全新的上下文窗口内能完成。

2. 显式声明阻塞关系：每张工单都会列出「阻塞它的工单」。没有任何前置依赖的工单可以立即开始，其余工单按依赖顺序排队，形成一条清晰的推进链路。开发时只需要盯住「前沿」——所有前置都已完成的那批工单。

3. 按追踪器形态发布：如果配置的是本地文件，会在 .scratch/<功能名>/issues/ 下按依赖顺序编号，一张工单一个 Markdown 文件，阻塞关系写在文件里；如果配置的是真实的 issue 追踪器（GitHub、Linear 等），则按依赖顺序逐条创建 issue，优先使用平台原生的阻塞／子任务关系来表达依赖，并自动打上 ready-for-agent 标签，让 Agent 可以直接认领。

常见问题

什么是一张「曳光弹」工单？和普通任务有什么区别？

曳光弹（tracer bullet）的原意是先打一发能看见弹道的子弹，确认方向对了再倾泻火力。对应到开发上，一张曳光弹工单必须是一条贯穿所有层的完整窄路径：数据结构、接口、界面、测试都碰到一点，但每一处都只做最薄的一层。它的验收标准是「做完之后能演示或验证」，而不是「这一层做完了」。所以它和「实现用户表的增删改查」这类横向任务不同，后者做完时用户还看不到任何东西。

拆出来的工单会存到哪里？支持哪些追踪器？

取决于你的配置。本地模式下，每个功能会有一个独立目录，工单按 01、02 这样的依赖顺序编号，一张工单一个文件，编号越小越先做，文件里写明它被哪些编号阻塞。真实追踪器模式下，会按同样的依赖顺序逐条创建 issue，用平台原生的阻塞关系串联起来。两种模式下工单内容是一样的，只是阻塞关系的表达形式不同。

拆分粒度需要我确认吗？会直接改我的原始 issue 吗？

会先确认。技能会先把拆分方案以编号列表的形式呈现给你，每张工单标出标题、被谁阻塞、以及它最终交付了什么行为，然后问你三个问题：粒度是否合适、阻塞关系是否正确、有没有需要合并或拆得更细的。你确认之后才会真正发布。另外，它不会关闭或修改任何父级 issue——拆分是新增，不是覆盖。