用途：to-tickets 用于把一份计划、规格说明或对话内容，拆解成一组可独立交付的工单。它的核心是“曳光弹式”纵向切片——每个切片窄但完整地穿过所有层（数据库结构、API、界面、测试），完成后本身可演示或可验证，且每张工单都声明自己依赖哪些先完成的工单。
主要能力：
- 上下文收集：基于对话已有内容工作；若用户传入规格路径、工单编号或 URL 等引用，则读取其完整正文与评论。
- 可选的代码库探查：了解代码现状，工单标题与描述使用项目领域词汇表，并遵守相关 ADR（架构决策记录）；同时寻找预重构机会，遵循“先让改动变容易，再做容易的改动”。
- 纵向切片与阻塞边：每个切片是贯穿各层的完整路径，可独立演示，规模控制在单个全新上下文窗口内；每张工单标注阻塞它的其他工单，无阻塞者可立即开始。
- 宽重构的特殊处理：对于改名、改类型等影响面遍布全库、无法以纵向切片保持 CI 通过的机械改动，改用“扩展—收缩”排期：先扩展（在旧形式旁新增新形式），再按影响面分批迁移调用点（每批一票，受扩展票阻塞），最后收缩（删除旧形式，受所有迁移批阻塞）。
- 上线验收单独成票：需要实机验证的工作拆为源工单（PR 合并即关闭）与上线验收工单（受源工单阻塞，凭已部署变更在实机上的记录证据关闭，合并本身不关闭它）。
- 用户确认：以编号列表展示每张工单的标题、阻塞项和交付内容，询问粒度是否合适、阻塞边是否正确、是否需要合并或拆分，迭代至用户批准。
- 发布到跟踪器：本地文件模式下在 .scratch/<feature-slug>/issues/ 下按依赖顺序（从 01 编号）每票一个 Markdown 文件，绝不合并成单文件；真实跟踪器（GitHub、Linear 等）按依赖顺序每票一个 issue，用平台原生子工单与阻塞关系链接父子与阻塞，无法创建原生链接时停止并报告，不得只在正文中留下关系。发布时工单处于待评审状态，不含 AFK-ready 角色；就绪状态需由仓库授权的其他角色在评审后赋予。
使用方式：以命名该技能或给出简要说明的提示词即触发调用。使用前应已向技能提供问题跟踪器与分诊标签词汇；若缺少跟踪器配置且未提供跟踪器，需询问用户选择本地文件还是真实跟踪器；缺少标签配置时使用规范角色名作为标签字符串。技能默认读取 docs/agents/issue-tracker.md、docs/agents/triage-labels.md、GLOSSARY.md、docs/adr/ 下的 ADR 以及已安装规则等资料。
适用场景：把功能计划或规格转为可执行工单；把对话中形成的方案落成有依赖关系的任务序列；需要每个任务可独立演示、控制单次上下文规模的项目；包含宽重构或需要实机验收的交付。
限制：工单正文避免具体文件路径和代码片段（易过时），仅在原型片段能更精确表达决策（状态机、reducer、schema、类型形状）时内联并注明来源；就绪状态不由本技能赋予；不得关闭或修改任何父工单；工单就绪后不得编辑其内容记录进度，进度应体现在关联 PR、子工单状态与评论中。