spec-plan 的用途是在方案或设计尚未定型时，通过反复访谈把每个分支逐项厘清，直到与用户形成共同理解，之后再进入 PRD 编写。
适用时机：用户想压力测试方案或设计；用户说“grill me”或“poke holes in this”；在运行 issue-to-prd 之前使用（spec-plan 负责消除歧义，issue-to-prd 负责结构化输出）；复杂功能包含大量相互影响的决策，需要按顺序解决。
不适用时机：需求已清晰且有文档，可直接进入 issue-to-prd；用户只想要快速意见而非深度访谈；实现工作已在进行中。
主要工作流程：
- 读取已有上下文。若方案来自 GitHub issue，先运行 gh issue view ISSUE_NUMBER --repo ORG/REPO --json body,title,comments，并阅读所有评论，把已问已回答的内容视为已解决分支，不再重复提问。若无 issue，则读取项目上下文，如 cat project-instructions.md 或等价的项目说明文件，以及 cat README.md。
- 一次只问一个问题。针对设计树的每个分支：提出一个问题，给出带推理的推荐答案，等待用户回复，纳入答案后进入下一个分支。规则强调“一次一个问题”，不是批量 Q1-Qn 格式，要在每个分支上深入后再继续。若问题能通过探索代码库回答，就探索代码库而非提问。
- 解决依赖。当决策相互依赖时，先识别哪个决策阻塞其他决策，先问阻塞项，再处理依赖决策。
- 可选交接给 issue-to-prd。当所有分支解决后，可询问：All branches resolved. Want me to run issue-to-prd to structure this into a PRD? 若同意，本次访谈形成的共同理解作为输入，issue-to-prd 可跳过清晰度评估直接起草。
关键规则：一次一个问题，重深度而非广度；始终给出推荐答案，不只提问；绝不重复已解决的问题，先读 issue 评论；提问前先探索代码；从对话停下的地方继续，尊重已有讨论。
限制：资料未说明具体安装方式、收费、价格、支持平台或效果保证，这些信息暂未提供。