本阶段如何触发
/comet-open 通常不是你手敲的命令，而是 /comet 进入 Classic 后自动路由的结果。内部 /comet-classic 会读取 active change 列表与文件状态，整理路由上下文，再由运行时评分决定 route。
默认：用 /comet 自动识别
/comet-classic 每次调用都重新读取文件状态（不依赖对话历史），按以下条件路由到 open 阶段：
你只需要输入
/comet 并描述想做什么。配置选择 Classic 后，内部 /comet-classic 会判断是否需要新建 change，并在 open 完成后自动衔接 design。详见自动推进机制。
手动：什么时候才需要直接 /comet-open
- 关闭了自动衔接（
auto_transition: false）——此时/comet-classic推进完一个阶段会停下，你需要手动调用下一个阶段 Skill。 - 只想单独跑 open 阶段（调试、或在阶段之间插入人工审核）。
/comet；只有手动控制阶段时才直接调用阶段命令。
你会经历什么
open 阶段不是一次性生成文档，而是一段多轮对话 + 多个停顿点的流程。全程用你触发工作流时用的语言提问和产出文档。
open 阶段把模糊想法过滤成三份可执行的 OpenSpec 产物
第一步：探索想法与澄清需求
Comet 加载openspec-explore，围绕你的想法持续提问，直到能整理出一份完整的澄清摘要。它不会把一次问答当成”够了”——会一直问到这五个部分都清楚：
停顿点 1：PRD 拆分预检（条件触发）
如果你的输入是一个大型 PRD、路线图或完整产品计划，或者澄清摘要里出现了多个独立能力，Comet 会在这里暂停，给你一份候选拆分清单（每个拆分项含建议名称、目标范围、非目标、依赖顺序、核心验收场景），然后让你三选一：停顿点 2：确认需求澄清完成
在创建任何文档之前，Comet 把完整的澄清摘要（五个部分）摆给你看，等你明确确认。确认前不会创建 proposal/design/tasks，也不会用openspec-propose 一次性生成。
停顿点 3：确认 change 名称
在openspec new change 之前，Comet 让你定名字。名字必须是 kebab-case 英文（小写字母、数字、连字符，例如 refine-requirements-doc）。它会：
- 推荐 2-3 个 kebab-case 英文名，每个带一行范围说明
- 让你自行输入名称——如果你输入的是中文或非合规文本，它会转换成合规 kebab-case 并回显让你确认
- 如果名字和已有 change 冲突，报告冲突让你换一个
第二步：创建 change 结构
加载openspec-new-change。完整工作流默认不加载 openspec-propose（一次性生成全部），只有你明确要求时才允许。Comet 用标准产物循环逐个生成 proposal → design → tasks：
- 刷新状态：
openspec status --change "<name>" --json - 获取指令：
openspec instructions proposal|design|tasks --change "<name>" --json - 读取
dependencies、遵循template和instruction、应用context/rules约束（不复制到文档内容里）、写入resolvedOutputPath - 每个 artifact 后再刷新状态确认
第三步：入口状态验证 + 内容完整性检查
停顿点 4：审视三个文档并确认
Comet 把三个文档的摘要摆给你看（proposal 的背景目标范围、design 的架构决策选型、tasks 的任务数和关键任务），然后让你二选一：退出：推进到下一阶段
--apply 是必须的——没有它 .comet.yaml 会停在 phase: open，下一阶段的入口检查会失败。full workflow 推进到 phase: design；hotfix/tweak 直接跳到 phase: build（跳过 design）。
调用的 skill
产物
下图用<classic-root> 表示当前 Classic OpenSpec 根目录：新项目默认是 docs/openspec/，保留旧布局的项目是 openspec/。实际位置由 .comet/config.yaml 中的 classic.artifact_layout 决定。
<classic-root>/changes/<name>/
.openspec.yaml
.comet.yaml
proposal.md
design.md
tasks.md
specs/<capability>/
幂等性：可以安全重复
open 阶段所有操作都可以安全重复执行。如果.comet.yaml 已经在 phase: open 且三个产物都已存在，Comet 会跳过已完成步骤，从第一个缺失的步骤继续。这让你在中断后重新调用 /comet 也不会搞乱状态。
四个停顿点一览
open 阶段有 4 个停顿点（全局编号 1-4，整个五阶段工作流共 13 个，见五阶段停顿点和用户选择点）：
所有停顿点都遵循决策点协议——Comet 不能用推荐规则、默认值或”用户应该会同意”来代替你的明确选择。
常见问题
.comet.yaml 缺失怎么办
.comet.yaml 缺失怎么办
不要用
/opsx:new 绕过——它只创建 OpenSpec artifacts，不会创建 .comet.yaml，change 会落在 Comet 状态机之外。重新运行 /comet；配置进入 Classic 后会通过 /comet-open 补齐状态。change 名称有什么限制
change 名称有什么限制
必须是 kebab-case 英文（小写字母、数字、连字符）。中文或非合规名称会被转换成 kebab-case
并回显让你确认。和已有 change 冲突会报告让你换一个。
openspec instructions 失败了怎么办
openspec instructions 失败了怎么办
Comet 会立即停止 artifact 创建并报告 OpenSpec 错误，不会回退为硬编码文档结构。检查 OpenSpec CLI
是否正常、
template/instruction/dependencies 是否满足。大型 PRD 一定要拆吗
大型 PRD 一定要拆吗
不一定。拆分预检会给你三选一（拆分 / 保持一个 / 调整方案），你可以选择保持为一个 change，但要把不拆的原因记进文档。
下一步
- design 阶段 — open 完成后进入深度设计
- 五阶段停顿点和用户选择点 — open 的 4 个停顿点详解
- 大型 PRD 拆分 — Step 1a 的完整机制
- 自动推进机制 — open 完成后如何自动衔接 design