Issue Planner 把一句“我要完成什么”，变成一条完整、可执行、没有被悄悄抢占的 GitHub Issue 链。
它不是 Issue 生成器，也不直接写代码。它负责在工作开始前回答这些问题：
- 为了完成目标，到底需要哪些 Issue？
- 现有 Issue 是否完整覆盖目标？
- 哪些 Issue 缺内容、缺决策或缺依赖？
- 哪些任务已经有人在做？我现在安全地能推进到哪里？
- 用户确认开始后，哪些 Issue 可以被领取并标记为处理中？
| 角色 | 责任 |
|---|---|
| Issue Planner | 理解目标、搜索 Issue、检查覆盖、构建依赖链、检查就绪状态、识别占用冲突、协调领取 |
| Issue Creator | 编写、拆分并创建确认缺失的 Issue；创建前仍需要用户授权 |
| 架构决策者 | 决定系统契约、数据隔离、安全边界、迁移策略等长期选择 |
| Issue-to-PR | 根据已经就绪的 Issue 实现代码并创建 PR |
默认的规划模式是只读的。只有用户确认了准确的变更预览后，Issue Planner 才会修改负责人或项目状态。
用户说：
我要上线移动端结账，帮我找出完整的 Issue 链。
仓库里已经有：
#101定义结账 API#102接入移动端支付 SDK，依赖#101#103完成结账页面，依赖#102#104增加端到端回归测试，依赖#103
Issue Planner 会给出：
覆盖结论
完整 — API、支付接入、页面和回归验证均有 Issue 覆盖。
Issue 链
#101 -> #102 -> #103 -> #104
就绪状态
#101 READY
#102 READY
#103 READY
#104 READY
下一步
从 #101 开始；当前只是规划，没有修改负责人或状态。
关键点：它不会因为用户只提到了 #103，就假设 #103 足以完成整个目标。
用户说：
我要让管理员可以批量禁用用户。
搜索结果只有：
#201批量禁用 API#202管理后台批量操作界面
但合规要求规定所有批量禁用操作必须写入审计日志，而现有 Issue 都没覆盖。
Issue Planner 会判断：
覆盖结论
缺失 — 审计日志没有对应 Issue。
缺口或决策
需要新增一个“记录批量禁用审计日志”的普通 Issue。
下一步
询问是否授权调用 Issue Creator 创建该 Issue。
只有用户授权后，它才会暂停规划、调用 Issue Creator 创建 Issue，然后重新读取仓库状态并规划完整链路。它不会自己偷偷执行 gh issue create。
用户说：
我要支持企业租户导出全部业务数据。
分析时发现团队还没有决定：导出任务使用共享队列，还是每个租户使用隔离队列。这个选择会改变安全边界、成本和后续 Issue 集合。
Issue Planner 会返回：
覆盖结论
等待决策 — 队列隔离方式尚未确定，会改变所需工作。
缺口或决策
由已配置的架构决策者确认共享队列或租户隔离队列，并记录决定。
下一步
决策记录完成后重新运行 Issue Planner。
它不会自行选择一种架构，再把这个未经确认的选择写进 Issue。
已确认的链路是：
#301 结账基础接口
├─> #302 风控校验（@alice 处理中） -> #303 支付提交
└─> #304 埋点统计（无人领取）
如果当前用户想开始整条链，Issue Planner 会报告：
占用冲突
当前可做: #301，完成后可做 #304
阻塞点: #302 — 处理中，负责人 @alice
受阻下游: #303
选择: 等待 #302 完成，或只领取已确认的不冲突工作
它不会移除 @alice、抢占 #302，也不会把依赖 #302 的 #303 伪装成“已经开始”。
用户在看过完整链后说：
开始做这条链。
Issue Planner 会先展示准确的变更：
| Issue | 当前负责人/状态 | 计划负责人/状态 |
|---|---|---|
#401 |
无 / Todo | @current-user / 处理中 |
#402 |
@current-user / Todo |
@current-user / 处理中 |
用户确认后，它会立即重新读取状态：
#401无人领取：添加当前用户，并设置仓库已有的“处理中”状态。#402已分配给当前用户：只更新状态，不重复修改负责人。- 如果预检发现任何 Issue 已变化：取消旧授权，重新计算并展示新预览。
- 如果写入中途失败：停止后续操作，重新读取全部 Issue，分别报告成功、未变化、失败和未尝试项。
它不会凭空创建 in-progress label，也不会把一次宽泛的“开始做”理解为授权修改尚未展示的 Issue。
执行 #501 时，用户临时补充：
顺便再支持导出 CSV 吧。
如果 CSV 导出改变了原 Issue 的目标或验收范围，Issue Planner 会要求把它记录为新 Issue，或通过仓库明确支持的 Issue 更新流程补充原 Issue，然后重新计算覆盖和链路。
当前 PR 仍以已记录的 Issue 为准。这样以后只看 Issue 和 PR，也能追溯需求为什么出现、在哪个周期被实现。
每次规划都会用相同的七段结构：
目标理解覆盖结论：完整、部分、缺失、冲突或等待决策Issue 链缺口或决策就绪状态占用与可推进边界下一步
规划结果不会包含实现步骤；实现细节由后续的 issue-to-PR 流程根据 Issue 和当前代码决定。
使用 $issue-planner：我要完成管理员批量禁用用户，帮我找出完整的 Issue 链。
使用 $issue-planner：检查 #101、#102、#103 是否足以完成移动端结账，并告诉我现在能推进到哪里。
使用 $issue-planner：开始做刚才确认的 Issue 链。
issue-planner/
├── SKILL.md
├── agents/
│ └── openai.yaml
└── references/
├── planning-workflow.md
└── start-work.md