用途
To Tickets 用于把一份计划、规格说明（spec）或当前对话内容，拆解成一组可执行的工单。它强调“曳光弹式”垂直切片：每个工单都贯穿所有相关层（schema、API、UI、测试），是一条窄但完整的路径，而不是某一层的水平切片。每个完成的切片都能独立演示或验证，并且大小适合放进一个全新的上下文窗口。
主要能力
- 从对话上下文或用户传入的引用（规格路径、issue 编号或 URL）收集上下文，并读取其完整正文与评论。
- 可选地探索代码库，理解当前代码状态，使工单标题和描述使用项目的领域词汇，并遵守相关 ADR。
- 寻找预重构（prefactor）机会，先让改动变容易，再做容易的改动。
- 将工作拆成垂直切片，并为每个工单声明阻塞边（blocking edges），即必须先完成的其他工单；没有阻塞的工单可立即开始。
- 对宽泛重构（wide refactor）采用 expand–contract 序列，而不是强行做成曳光弹切片。
- 以编号列表形式呈现拆解方案，包含标题、被谁阻塞、交付内容，并迭代直到用户批准。
- 将批准的工单按依赖顺序发布到已配置的追踪器。
- 提交本次流程涉及的规划产物。
使用方式
该技能假定 issue tracker 和 triage 标签词汇已提供；若未提供，需先运行 /setup-utarn-skills。
流程大致为：
- 收集上下文：基于对话已有内容；若用户传入引用，则抓取并阅读其完整正文与评论。
- 可选探索代码库：理解当前代码状态，使用项目领域词汇，遵守 ADR，寻找预重构机会。
- 起草垂直切片：每个切片贯穿所有层，可独立演示或验证，大小适合单个上下文窗口；预重构优先；为每个工单标注阻塞边。宽泛重构例外，按 expand–contract 排序。
- 假定批准切片：以编号列表展示每个工单的标题、被谁阻塞、交付内容；询问粒度是否合适、阻塞边是否正确、是否需要合并或拆分；迭代直到用户批准。
- 发布工单到已配置追踪器：
- 本地文件：在
.scratch/<feature-slug>/issues/<NN>-<slug>.md下每个工单一个文件，按依赖顺序从 01 编号，每个文件的“Blocked by”列出依赖的编号/标题。 - 真实 issue tracker（GitHub、Linear 等）：按依赖顺序每个工单发布一个 issue，使用平台原生阻塞/子 issue 关系，否则设置“Blocked by”；除非另有指示，应用 ready-for-agent 标签。
- 不要关闭或修改任何父 issue。
- 本地文件：在
- 提交规划产物：运行
git status --short，将本次流程涉及的未跟踪或已修改的规划产物（如 CONTEXT.md / CONTEXT-MAP.md、docs/adr/ 文件、写入仓库的 PRD 或 spec markdown、.scratch/<feature-slug>/issues/下的本地工单文件）精确暂存并作为一个提交：docs: <feature-slug> planning artifacts。若某产物路径被 gitignore，应向用户说明而不是绕过提交。
工单模板包含：What to build（从用户视角描述的端到端行为）、Blocked by（阻塞工单引用或“None — can start immediately”）、Status（ready-for-agent）、Acceptance criteria（验收标准）、Parent（若来源是已有 issue 则引用父 issue）。避免具体文件路径或代码片段，例外是原型中编码了比文字更精确决策的片段（状态机、reducer、schema、类型形状），可内联并简要说明来自原型。
最后，使用 /implement 一次处理一个前沿工单，并在工单之间清空上下文。
适用场景
- 需要把计划、规格或对话转化为可执行、可追踪的工单时。
- 希望工单是垂直切片、可独立验证、适合智能体逐个领取实现时。
- 使用本地文件或 GitHub、Linear 等真实 issue tracker 管理任务时。
- 需要处理宽泛重构并保持 CI 绿色时。
限制
- 需要预先配置 issue tracker 和 triage 标签词汇，否则需先运行
/setup-utarn-skills。 - 工单应避免具体文件路径或代码片段，因为它们容易过时。
- 宽泛重构不能强行做成曳光弹切片，需按 expand–contract 序列处理。
- 不关闭或修改任何父 issue。
- 若规划产物路径被 gitignore，需向用户说明，不能绕过提交。
- 关于收费、价格、平台支持范围等具体信息，资料中暂未提供。