用途
to-tickets 用于把一个计划、规格文档或当前对话内容，拆解成一组可独立推进的工单（tickets）。这些工单采用“曳光弹”纵向切片：每个切片贯穿 schema、API、UI、测试等所有层，是一条窄但完整的路径，完成后可单独演示或验证，并控制在一个全新的上下文窗口内可完成的规模。每个工单都会声明阻塞边（blocking edges），即哪些工单必须先完成。
主要能力
- 上下文收集：基于对话已有上下文工作；若用户传入规格路径、问题编号或 URL 等引用，会抓取并阅读其正文与评论。
- 代码库探索（可选）：了解代码当前状态，使工单标题和描述使用项目领域术语表词汇，并遵循相关 ADR。还会寻找预重构（prefactor）机会，让后续实现更简单。
- 纵向切片：将工作拆为曳光弹工单，每个切片贯穿所有层、可独立验证、规模适合单个上下文窗口；预重构排在最前。
- 阻塞关系：为每个工单标注必须先完成的其它工单；无阻塞的工单可立即开始。
- 宽重构例外处理：对于波及全代码库的机械性变更（如改列名、改共享符号类型），不强行纵向切片，而采用“扩展—收缩”（expand–contract）序列：先并行添加新形式，再按影响范围分批迁移调用点，最后删除旧形式；必要时各批次共享集成分支，由最终“集成并验证”工单统一保证绿色。
- 与用户确认：以编号列表展示拆解方案，逐项列出标题、被谁阻塞、交付内容，并就粒度、阻塞边正确性、是否合并或拆分向用户提问，迭代至用户批准。
- 发布到跟踪器：按 /setup-matt-pocock-skills 配置的跟踪器发布，工单内容一致，仅阻塞边形式不同。
使用方式
- 确保已配置跟踪器与分诊标签词汇；若未配置，提示用户运行 /setup-matt-pocock-skills。
- 提供计划、规格或引用，或直接基于当前对话。
- 技能生成纵向切片草案并征求确认。
- 批准后按依赖顺序发布（阻塞者在前）。
发布形式：
- 本地文件：在
.scratch/<feature-slug>/issues/<NN>-<slug>.md下每个工单一文件，按依赖顺序从 01 编号，每文件列出“Blocked by”。禁止合并为单文件。 - 真实跟踪器（GitHub、Linear 等）：按依赖顺序每个工单发布一个 issue；优先使用平台原生阻塞关系，否则在工单中写明“Blocked by”。若来源是已有 issue，则将各工单作为其子 issue。默认应用 ready-for-agent 分诊标签，不关闭或修改父 issue。
- 工作前沿：所有阻塞者均完成的工单即可开始；纯线性链即从上到下推进。
每工单文件/issue 模板包含：What to build（从用户视角描述的端到端行为，而非逐层实现清单）、Acceptance criteria（验收标准清单）、Blocked by（阻塞工单引用或“None (can start immediately)”）、Status（ready-for-agent），以及来源为已有 issue 时的 Parent 引用。应避免具体文件路径或代码片段（易过时）；例外是原型中能比文字更精确表达决策的片段（状态机、reducer、schema、类型形状），可内联并注明来自原型，只保留决策相关部分。
适用场景
- 将规格或计划转化为可执行、可追踪的开发任务。
- 需要任务具备明确依赖顺序和可独立验证的交付物。
- 团队使用 GitHub、Linear 或本地文件管理 issue 的工作流。
- 涉及跨代码库宽重构时，需要结构化的分批迁移序列。
限制
- 依赖预先配置的跟踪器与分诊标签；未配置时需先运行 /setup-matt-pocock-skills。
- 工单应避免具体路径与代码片段，以免快速过时。
- 宽重构场景下，各批次单独可能无法保持绿色，仅在最终集成验证工单处承诺绿色。
- 不关闭或修改父 issue。
- 关于价格、平台支持范围等其它信息暂未提供。