用途：把计划、规格说明或对话内容拆分成可独立领取的工单（tickets），采用 tracer-bullet 垂直切片方式，每张工单声明其阻塞依赖关系。
主要能力与流程：
- 收集上下文。基于对话已有的上下文工作；若用户传入引用（spec 路径、issue 编号或 URL），则获取并阅读其完整正文与评论。
- 可选地探索代码库，理解现状；工单标题与描述使用项目的领域词汇表，并遵守相关 ADR，寻找可以让实现更容易的 prefactor 机会。
- 起草垂直切片。每张工单是贯穿所有集成层的薄垂直切片，而非单一层的水平切片。切片可为 HITL（需人工交互，如架构决策或设计评审）或 AFK（无需人工交互即可实现并合并），尽量优先 AFK。为每张工单标注阻塞边；无阻塞的工单可立即开始。宽泛重构例外：按 expand-contract 排序——Expand 添加新形式并列旧形式，Migrate 按影响范围分批迁移调用点（每批各为一张被 expand 阻塞的工单），Contract 在无调用者后删除旧形式（被所有 migrate 批阻塞）。若单批无法保持绿，共享集成分支并最终由一个 integrate-and-verify 工单统一保证绿。
- 向用户确认。以编号列表呈现拆分结果，逐张显示标题、类型（HITL/AFK）、被谁阻塞、交付内容、覆盖的用户故事；询问粒度是否合适、阻塞边是否正确、是否需合并或拆分、HITL/AFK 标记是否正确，迭代至用户批准。
- 发布工单。按依赖顺序（阻塞者优先）创建新 issue，使用工单正文模板，并打上 needs-triage 标签；优先使用平台原生阻塞/子 issue 关系。
工单模板字段：父 issue 引用（若来源为既有 issue）、What to build（从用户视角描述端到端行为）、Acceptance criteria（验收标准清单）、Blocked by（阻塞工单引用，或 None - can start immediately）。避免具体文件路径或代码片段，除非原型中的片段（状态机、reducer、schema、类型形状）比文字更精确地编码决策，需注明来自原型并裁剪至决策关键部分。不要关闭或修改任何父 issue。逐个处理 frontier 工单，工单之间清空上下文。
issue tracker 为 GitHub，repo 中的 issue 与 spec 都在 GitHub issues 中，用 gh CLI 操作。约定：创建 gh issue create --title "..." --body "..."（多行正文用 heredoc）；读取 gh issue view <number> --comments（用 jq 过滤评论并获取标签）；列出 gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]' 配合 --label 与 --state 过滤；评论 gh issue comment <number> --body "..."；加/删标签 gh issue edit <number> --add-label "..." / --remove-label "..."；关闭 gh issue close <number> --comment "..."。repo 由 git remote -v 推断，gh 在克隆内运行会自动处理。
适用场景：需要把规格或对话转成可并行领取的实现工单、并管理与 GitHub issue 的依赖关系时。限制：依赖 GitHub 与 gh CLI；工单质量依赖代码库与领域上下文；发布前需用户批准拆分。