用途：将一个宽泛的 issue 或任务拆解为边界清晰、可独立实现、可验证的子 issue，并先以依赖图形式呈现方案，把规划与写入分离，仅在明确批准后才创建或更新 issue。
主要能力：解析并完整阅读父 issue（标题、正文、附件、标签、指派人、里程碑、评论与已有子链接），审计现状（可复用实现、缺失部分、受约束区域、未决决策、验证约定），设计最小有用子集，为每个子 issue 给出标题与完整正文，包含 Goal、Context、Implementation、Acceptance criteria、Out of scope、Dependencies、Parent issue 等章节；当子 issue 多于一个时用紧凑 Mermaid 流程图展示依赖，并提供概要表、父 issue 更新预览与元数据计划（标签、指派人、里程碑、原生父子关系行为）。
使用方式：先只读检查父 issue 与相关设计、规格、仓库上下文，区分事实与假设，列出阻塞子 issue 的缺失项，此时不创建、不编辑、不指派、不链接。随后展示完整提案，依赖图用临时标签，且每条边要与子 issue 正文中的依赖章节一致。只有用户对确切拆解、子正文、父更新与元数据计划明确批准后，才按顺序写入：先创建前置子 issue，再创建可并行子 issue，最后在真实依赖编号已知后创建集成子 issue，并用真实链接替换临时引用。父正文管理区块用 <!-- subissue-plan:start --> 与 <!-- subissue-plan:end --> 标记，首轮追加，后续只替换标记之间内容，且逐字保留无关的原有内容。写入后重新抓取父与全部子 issue，核对标题、正文、依赖、元数据、父引用、原生关系或清单链接，确认无重复子 issue 与重复管理区块，并报告父 URL 及每个子 URL 与标题。
适用场景：issue 跟踪器中大型任务的任务分解、依赖排序与并行实施规划。
限制与注意事项：原始拆分请求不视为创建授权，工具权限提示不能替代对话式批准；存在未批准、变更标题范围依赖正文或元数据时须重新提案并再次请求批准。不得编造占位 URL、内容、API 或产品决策；避免重复范围与循环依赖；不要创建只生成琐碎辅助文件的微小 issue；不要把本技能编码进仓库专属知识。优先使用跟踪器结构化连接器或 API，仅在验证本地检出属于父 issue 后用于获取证据；不修改仓库文件，除非用户另行要求实施。部分创建失败时保留已成功的编号、安全重试失败操作，不创建重复项掩盖错误。关于价格、收费、平台支持等信息，资料暂未提供。