用途：把一份规格说明（spec）或实现计划（implementation plan）转换为用户任务追踪器中的工作项，并按用户需要的粒度、字段和链接关系组织。
主要能力：支持写入 GitHub issues（gh）、GitLab issues（glab）、Jira、Azure DevOps（az boards）、Linear，或项目内基于 git 的任务清单文件（项目已有任务文件，否则为 docs/<slug>-tasks.md）。粒度可选每个计划步骤一项、每条验收标准一项，或一个 epic 加子任务。字段支持标签、里程碑、负责人、估算、父项或 epic、迭代。依赖关系可来自计划顺序或父子关系。
使用方式：先一次性询问目标位置、粒度、字段和链接需求，并检查可用工具（gh auth status、glab auth status、az account show、MCP servers）；若均不可用则生成 Markdown 文件并说明导入方式。每个工作项包含标题（<feature slug>: <祈使句步骤或能力>）、上下文（链接到 docs/<slug>-spec.md 与 docs/<slug>-plan.md）、验收标准（复制标准文本而非仅 ID）、完成定义、依赖项，并附加 feature slug 标签。生成后展示全部工作项表格和将执行的命令或 API，征得明确确认后再创建；在外部追踪器中按依赖顺序创建以便关联真实 ID，并把映射保存到 .scratchpad/<slug>/work-items.md；仓库内任务清单需随计划提交，不能只放在 .scratchpad/。最后报告链接，创建失败需列出错误，不盲目重试。
适用场景：需要把计划落地为可执行任务、在团队追踪器中保持需求与计划可追溯、或统一工作项格式与验收标准的研发协作流程。
限制：创建共享追踪器中的条目对他人可见，必须先预览并获得明确同意；工具不可用时仅能输出 Markdown 文件。