该技能用于把产品或工程文档拆解成面向产品、可交付的高层工单，输出可原样导入外部任务跟踪系统（Linear、GitHub Issues、Jira）。工单描述“交付什么”，而非“如何实现”。
用途与适用：适合团队需要把整篇功能文档分解成可排期、可导入看板的待办单元。与 /create-implementation-plan 的区别是：后者回答如何一步步构建单个工单，粒度更细、涉及文件，产物留在 .specs/；本技能面向产品与工程双方，粒度较粗，产物要离开仓库进入跟踪系统。
主要能力：接收 PRD、RFC、技术设计等源文档路径与功能 slug；完整读取源文档，提取可交付单元、优先级、依赖与顺序约束、验收信号、范围边界；仅在源文档信息不足时用 AskUserQuestion 询问粒度、优先级或验收信号等阻塞性问题；按规则拆解并排序（先按 P0→P1→P2，再保证依赖项在其依赖者之前），分配文件内引用编号；校验后写出 .specs/[slug]/TICKETS.md。
使用方式要点：需提供源文档显式路径；若源在 .specs/[slug]/... 则复用 slug，否则询问功能 slug；输出固定为 .specs/[slug]/TICKETS.md。拆解规则包括：一票一结果、标题不含“AND”、面向产品的可交付单元、可验证的通过/失败验收标准、依赖满足后可独立交付、尽量采用纵向切片但基础设施型工单也有效、继承源文档优先级否则推断并确认、不设内部 ID 方案、文件内 #N 仅用于导航。校验清单涵盖源文档是否完整阅读、每个工单是否具备标题/优先级/描述/至少一条验收标准、依赖引用是否可解析、排序与编号是否一致、是否编造源中不存在的工作、是否写成工程任务。
限制：不发明需求，若未提供源路径会先索要；不扩大范围，源文档未提的工作不会新增；不得把所有工单都标为 P0；不强行套用纵向切片。输出为 Markdown 文件，新建 .specs/[slug] 目录。未提供收费、价格、平台支持等更多信息。