用途：当一个 issue 对单个任务来说过大时，用此技能将其拆解为相互关联的子 issue，确保每个子 issue 可在一次专注会话内完成。核心原则是：如果 issue 太大，应在开始工作前先分解。
判断标准：出现以下任一情况即视为过大——验收标准超过 5 条、涉及超过 3 个不相关代码区域、预估工作量超过一个上下文窗口、包含多个独立功能、内部依赖顺序复杂。有疑问时倾向于分解，小 issue 优于大 issue。
主要流程：先通读父 issue，识别独立工作单元、依赖关系、自然边界与验收标准的归属；再制定分解计划，列出每个子 issue 的标题、来自父级的标准、依赖与交付物；随后使用 gh issue create 创建子 issue，正文包含描述、验收标准、验证步骤、依赖、父 issue 引用，并给出子 issue 质量检查清单；接着用 gh issue edit 为子 issue 和父 issue 打标签；更新父 issue 正文列出全部子 issue；用 gh project item-add 将子 issue 加入项目并设置状态；最后在知识图谱中记录分解结果与 has_sub_issue、blocks 等关系。
依赖处理：无依赖的子 issue 状态设为 Ready 可立即开始；被阻塞的设为 Backlog，待阻塞完成后移回 Ready；会阻塞其他子 issue 的优先处理。
限制与注意：每个子 issue 必须有清晰标题、父 issue 引用、自身验收标准与验证步骤，需记录依赖、加入 GitHub Project 并打上 sub-issue 标签。常见错误包括子 issue 过于模糊、遗漏依赖、未更新父 issue、跳过项目设置、标准重复错误。资料未提供具体平台限制或收费信息。