用途：把计划、规格（spec）或当前对话拆解成一组工单（tickets），采用 tracer-bullet 垂直切片：每个切片贯穿所有层（schema、API、UI、测试），本身可演示或验证，且能放进一个全新的上下文窗口。每张工单需声明阻塞它的其他工单，无阻塞者立即可开工。
主要能力与流程：
- 收集上下文：以对话中已有内容为基础；若用户传入引用（spec 路径、issue 编号或 URL），则获取并阅读其正文与评论。
- 可选地探索代码库：了解当前代码状态，标题与描述使用项目的领域术语表，遵守相关 ADR，并寻找 prefactor 机会（先让改动变简单，再做简单改动）。
- 起草垂直切片，并标注阻塞边。宽泛重构是例外：用 expand–contract 顺序处理，先增加新形式，再按影响范围分批迁移调用点，最后删除旧形式。
- 向用户确认：以编号列表展示拆分结果，逐项给出标题、Blocked by、What it delivers，并询问粒度是否合适、阻塞边是否正确、是否需要合并或拆分，迭代至用户批准。
- 发布到已配置的跟踪器：本地文件则写到 .scratch/<feature-slug>/issues/<NN>-<slug>.md，按依赖顺序从 01 编号，每张工单一个文件；真实跟踪器（GitHub、Linear 等）则按依赖顺序逐张发布 issue，优先使用平台原生阻塞/子任务关系，否则在 Blocked by 中写明阻塞 issue，并默认应用 ready-for-agent 分诊标签。不要关闭或修改任何父 issue。
使用方式：需先由环境提供问题跟踪器与分诊标签词表；若未提供，应提示用户运行 /setup-issue-tracker。
限制：工单描述应避免具体文件路径或代码片段（易过时）；例外是原型中能更精确表达决策的片段（状态机、reducer、schema、类型形状），可内联并注明来自原型，只保留决策相关的关键部分，而非可运行 demo。