用途：针对已有 GitHub Issues 的项目，分析一组 issue、识别依赖、提出执行顺序并定义工作单元，生成一份可在上下文丢失后继续使用的计划文档。适用于任何使用 GitHub Issues 的项目。
主要能力与流程：
- 分析 Issues：接受用户给出的父 issue 编号或一组编号，使用 gh sub-issue list <number> 递归读取层级，读取每个 issue 的标题、标签、正文和父子关系，并向用户展示摘要（编号、标题、标签、缩进树）。若读取失败则显示错误并停止；若指定父 issue 没有子 issue，则告知无 issue 可规划。
- 识别依赖并排序：依据正文中的显式引用（如 depends on #X、blocked by #X）、层级关系（父 issue 依赖子 issue 解决）、内容产出关系判断依赖；结合优先级确定执行顺序，并考虑实际收益，例如先做基础工具以便后续开发中使用。
- 定义工作单元：把相关 issue 分组，每个工作单元对应一个功能分支，包含关联紧密、适合一起实现的 issue，并配有清晰简短描述；一个工作单元可含单个或多个 issue。
- 输出计划文档：生成 Markdown 计划并保存到 .docs/plans/，内容含标题、日期、父 issue、需求文档编号（如适用）、依赖表、执行顺序表（顺序、工作单元、issue、分支、状态）、理由说明和下一步动作；计划定稿后展示第一个工作单元及其关联 issue 作为下一步。
完成前检查：确认文档可独立成立——若对话丢失仅剩计划文件，是否仍能恢复工作（每个工作单元应引用具体 issue 编号）；是否可执行——每个工作单元是否有足够细节以创建分支并开始，而无需重读完整 issue 线程。
限制：规划为只读操作，不修改 issue（不改标签、指派或状态）；不创建分支、不开始实现，只产出文档；始终把计划持久化到文件。