关于 to-tickets
to-tickets 是一项技能，可将计划、规格或对话整理为带依赖关系的端到端工单，供 Agent 拆分和推进开发工作。它面向使用本地文件或已配置问题跟踪器的工作流，并说明了纵向切片与大型重构的安排方式。
主要功能
- 01起草 tracer-bullet 纵向切片
- 02定义工单阻塞关系
- 03以扩展—收缩方式安排大型重构
- 04从规格和代码库收集上下文
- 05向已配置跟踪器发布工单
适用场景
- 01将功能计划拆为可供 Agent 执行的工单
- 02梳理实现任务间的依赖关系
- 03规划大型重构并避免调用方受阻
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/to-tickets确认已加载。
附带文件agents/openai.yaml
详细介绍
转换为工单
将计划、规格说明或对话拆分为一组工单：示踪弹式的垂直切片，每个工单都声明阻塞它的工单。
应该已经向你提供了问题跟踪器和分诊标签词汇。如果没有，请告诉用户运行 /setup-matt-pocock-skills。
流程
1. 收集上下文
根据对话中已有的上下文开展工作。如果用户传入了参考资料（规格说明路径、问题编号或 URL）作为参数，请获取并阅读其完整正文和评论。
2. 探索代码库（可选）
如果你还没有探索过代码库，请先这样做，以了解代码的当前状态。工单标题和描述应使用项目的领域词汇表，并遵循你要修改区域的 ADR。
寻找预先重构代码的机会，让实现更容易。“先让改动变容易，再进行容易的改动。”
3. 草拟垂直切片
将工作拆分为示踪弹式工单。
- 每个切片都要贯穿每一层（架构、API、UI、测试），形成一条范围狭窄但完整的路径：垂直切片，而非只涉及某一层的水平切片
- 每个已完成的切片都能独立演示或验证
- 每个切片的规模都应适合在一个全新的上下文窗口中完成
- 任何预先重构都应先完成
为每个工单标出其阻塞边：必须先完成哪些其他工单，它才能开始。没有阻塞项的工单可以立即开始。
宽范围重构是垂直切片的例外。 宽范围重构是指一种机械性改动（例如重命名列、重新设置共享符号的类型），其影响范围会扩展到整个代码库，导致单次编辑就会一次性破坏数千个调用点，且无法通过垂直切片保持绿色。不要强行将它拆成示踪弹式切片；应按扩展–收缩顺序进行。首先扩展：在旧形式旁边添加新形式，确保不会破坏任何内容。然后分批迁移调用点，每批的规模应与影响范围相匹配（按包、按目录）；每批单独作为一个被扩展阶段阻塞的工单，并且旧形式仍然存在，因此每批完成后 CI 都保持绿色。最后收缩：在没有剩余调用者后，通过一个被所有迁移批次阻塞的工单删除旧形式。如果连这些批次也无法单独保持绿色，则保留这一顺序，但让它们共用一个集成分支，并全部阻塞最终的集成与验证工单；只有到那时才能保证绿色。
4. 向用户确认
以带固定表情符号锚点的编号列表呈现建议的拆分，方便用户浏览标题和依赖边：
🎫 **Proposed tickets** · N slices
1. 🎫 **<Title>**
🔗 Blocked by: <titles or "None — can start immediately">
✨ Delivers: <end-to-end behaviour>
2. 🎫 **<Title>**
...
然后确认三项内容（保持简短；可以合并成一组提问）：
👇 Before I publish:
1) Granularity — too coarse / too fine / about right?
2) Blocking edges — does each ticket only wait on what genuinely gates it?
3) Merge or split any?
反复迭代，直到用户批准拆分方案。
5. 将工单发布到已配置的问题跟踪器
发布已批准的工单。具体方式取决于 /setup-matt-pocock-skills 配置的问题跟踪器；无论哪种方式，工单内容都相同，只有阻塞边的形式会有所不同：
- 本地文件 → 在
.scratch/<feature-slug>/issues/<NN>-<slug>.md下为每个工单写一个文件，按依赖顺序（先写阻塞项）从01开始编号。每个文件中的“Blocked by”列出其依赖项的编号/标题。使用下面的单工单文件模板：每个文件只放一个工单，绝不能放在一个合并文件中。 - 真实的问题跟踪器（GitHub、Linear 等） → 按依赖顺序（先发布阻塞项）为每个工单创建一个问题，以便其阻塞边可以引用真实标识符。如果平台有原生阻塞关系，请使用；否则，在每个工单的“Blocked by”中填写阻塞问题。如果来源是一个已有问题，请将每个工单设为它的子问题（使用跟踪器文档中的操作）。除非另有说明，否则应用
ready-for-agent分诊标签；这些工单按设计即可由 Agent 领取。
处理前沿：阻塞项全部完成的任何工单。如果依赖关系完全是线性链，则按从上到下的顺序处理。
不要关闭或修改任何父问题。
# ：要构建的内容： 从用户的角度描述此工单实现的端到端行为，而不是逐层罗列实现内容。
阻塞项： 阻塞此工单的工单编号和标题，或“无（可立即开始）”。
状态： ready-for-agent
- 验收标准 1
- 验收标准 2
父工单
跟踪系统中父工单的引用（如果来源是现有工单；否则省略此部分）。
要构建的内容
描述此工单实现的端到端行为，从用户的角度出发，而不是逐层描述实现。
验收标准
- 标准 1
- 标准 2
阻塞项
- 引用每个阻塞工单，或填写“无（可立即开始）”。如果阻塞项已通过原生依赖关系设置，则省略此部分。
无论采用哪种形式，都应避免使用具体文件路径或代码片段：它们很快就会过时。例外情况：如果原型生成的代码片段比文字描述更准确地表达了某项决策（状态机、reducer、架构、类型结构），则可将其内联，并简要注明其来自原型。只保留与决策相关的内容，不要提供可运行的演示，只保留重要部分。