用途
to-tickets 用于把一份计划、规格文档（spec）或当前对话内容，拆解成一组工单（tickets）。这些工单是“曳光弹”式的垂直切片，每个切片都声明了阻塞它的其他工单。
如果缺少分诊标签或追踪器约定，需要先运行 /setup-skills。但下文的目标位置解析不需要 setup。
主要能力
- 从对话上下文或用户传入的引用（规格路径、issue 编号或 URL）中收集上下文，并读取其完整正文与评论。
- 可选地探索代码库，理解代码现状，使工单标题和描述使用项目的领域词汇，并遵守相关 ADR。
- 寻找预重构（prefactor）机会，让实现更容易。
- 将工作拆解为垂直切片：每个切片贯穿所有层（schema、API、UI、测试），是垂直而非某一层的水平切片；完成的切片可独立演示或验证；每个切片大小适合放入一个全新的上下文窗口；预重构应最先完成。
- 为每个工单标注阻塞边：必须先完成的其他工单。没有阻塞的工单可立即开始。
- 对宽泛重构（wide refactor）采用 expand–contract 序列，而非强行垂直切片。
- 为每个工单评定难度等级并给出建议模型（仅作提示，非强制）。
- 展示拆解结果后直接发布，不询问确认（除非用户明确要求先审阅或批准）。
- 解析发布目标：用户明确指定则用指定目标；否则若存在 docs/agents/issue-tracker.md 并指明追踪器则用之；否则使用本地 markdown。不探测 git remote，不弹出目标选择器。
- 本地 markdown：在 .scratch/<feature-slug>/tickets/<NN>-<slug>.md 下每个工单一个文件，按依赖顺序从 01 编号（阻塞者在前）。
- 真实 issue 追踪器：按依赖顺序每个工单发布一个 issue，使用平台原生阻塞/子 issue 关系；若来源是已有 issue，则把每个工单作为其子 issue；应用 ready-for-agent 分诊标签。
- 不关闭或修改任何父 issue。
使用方式
流程分为六步：
- 收集上下文：基于对话中已有内容工作；若用户传入引用则获取并阅读其完整正文与评论。
- 探索代码库（可选）：理解代码现状，使用项目领域词汇，遵守 ADR，寻找预重构机会。
- 起草垂直切片：拆成曳光弹工单，每个切片贯穿所有层、可独立验证、适合单个上下文窗口；预重构最先做；标注阻塞边。宽泛重构例外，按 expand–contract 排序。
- 评定每个工单的难度：给出难度层级和建议模型。
- 展示拆解：以编号列表呈现，每个工单显示标题、难度、被谁阻塞、交付内容。展示后直接发布，不询问确认。
- 发布工单：静默解析发布目标并发布。
难度层级：
- Heavy：基础设施、部署、迁移、架构决策、安全边界、宽泛重构等影响跨子系统的内容。建议模型：Opus（Claude Code）/ Opus 或可用的最强推理模型（Cursor）。
- Standard：普通编程逻辑，如功能切片、端点、组件、有真实分支的 bug 修复。默认层级，大多数工单属于此。建议模型：Sonnet（Claude Code）/ Sonnet（Cursor）。
- Light：机械性、低判断工作，如配置升级、文案修改、小范围重命名、添加镜像现有测试的测试。建议模型：Haiku（Claude Code）/ claude-4.5-haiku-thinking（Cursor）。
按工单所需的判断力评级，而非 diff 大小。介于两层之间时选更高层。若一次运行中大多数工单都是 Heavy，说明切片可能太宽，应回到第 3 步。
工单文件模板包含：难度行（置于正文最前）、Spec 路径、What to build、Seams、Blocked by、Status: ready-for-agent、验收标准复选框。真实追踪器版本还包含 Parent 引用。两种形式都应避免具体文件路径或代码片段（易过时），例外是原型产生的、比文字更精确表达决策的片段（状态机、reducer、schema、类型形状），可内联并简要注明来自原型，只保留决策密集部分。
适用场景
- 把规格文档或计划转化为可执行的工单集合。
- 把当前对话中的讨论整理成有依赖关系的任务。
- 需要为智能体（agent）准备可抓取的工单时。
- 需要处理宽泛重构并保持 CI 绿色时。
限制
- 若需要分诊标签或追踪器约定且缺失，需先运行 /setup-skills。
- 目标位置解析不询问用户，也不探测 git remote。
- 难度建议仅为提示，非强制要求。
- 不关闭或修改任何父 issue。
- 工单中应避免具体文件路径或代码片段，以免过时。
- 关于收费、价格、平台支持范围等具体信息，资料中暂未提供。