to-tickets 用于把计划、规格说明或当前对话上下文拆解为一组工单。每个工单是一条“曳光弹”式的纵向切片：窄但完整地贯穿 schema、API、UI、测试等所有层，完成后可独立演示或验证，且规模适合放进一个全新的上下文窗口。每个工单需声明其阻塞边，即必须先完成哪些工单才能开始；无阻塞的工单可立即开始。
使用前需已提供工单追踪系统与分诊标签词汇，否则应提示用户运行 /setup-matt-pocock-skills。流程如下：
- 收集上下文：基于对话已有内容工作；若用户传入引用（规格路径、issue 编号或 URL），需抓取并阅读其完整正文与评论。
- 可选地探索代码库，了解现状；工单标题与描述应使用项目领域词汇，并遵守相关 ADR。同时寻找预重构机会，先让改动变简单，再做简单改动。
- 起草纵向切片：预重构优先；每个切片完整贯穿各层，可独立验证；每个工单标注阻塞边。宽泛重构是例外，应按“扩展—收缩”排序：先新增形式并存，再按影响面分批迁移调用点（每批各为工单，被扩展工单阻塞），最后在无调用者后删除旧形式（被所有迁移批次阻塞）。必要时可共享集成分支，最终由一个集成验证工单统一保证绿色。
- 以编号列表向用户呈现拆分，每个工单显示标题、被谁阻塞、交付什么；询问粒度是否合适、阻塞边是否正确、是否需要合并或拆分，迭代至用户批准。
- 发布到配置的追踪系统：本地文件则每个工单写一个文件到 .scratch/<feature-slug>/issues/<NN>-<slug>.md，从 01 按依赖顺序编号，每文件一个工单，绝不合并；真实追踪系统则按依赖顺序每个工单发一个 issue，使用平台原生阻塞/子 issue 关系，否则在“Blocked by”写明阻塞 issue，并打上 ready-for-agent 分诊标签。仅处理所有阻塞均已完成的边界工单，不要关闭或修改任何父 issue。
工单内容包含：标题、要构建什么（从用户视角描述端到端行为，而非逐层实现清单）、验收标准、被谁阻塞（或“无，可立即开始”）、状态、父 issue 引用（如来源为现有 issue）。两种形式都应避免具体文件路径或代码片段，因为它们容易过时；例外是原型中比文字更精确地编码了决策的片段（状态机、reducer、schema、类型形状），可内联并注明来自原型，只保留决策密集部分。