本阶段如何触发
/comet-open 通常由 /comet 进入 Classic 后自动路由。内部 /comet-classic 会读取 active change 列表与文件状态，整理路由上下文，再由运行时评分决定路由到哪个阶段。
默认：用 /comet 自动识别
/comet-classic 每次调用都重新读取文件状态（不依赖对话历史），按以下条件路由到 open 阶段：
输入
/comet 并描述想做什么即可。配置选择 Classic 后，内部 /comet-classic 会判断是否需要新建 change，并在 open 完成后自动衔接 design。详见自动推进机制。
手动：什么时候才需要直接 /comet-open
- 关闭了自动衔接（
auto_transition: false）时，/comet-classic推进完一个阶段会停下。你需要手动调用下一个阶段 Skill。 - 只想单独跑 open 阶段（调试、或在阶段之间插入人工审核）。
/comet；只有手动控制阶段时才直接调用阶段命令。
创建 Change 时选择工作区
创建 Classic change 时，Comet 会在生成 OpenSpec 产物和状态文件之前确认工作区：current：在当前分支串行工作；branch：创建独立分支，但仍使用当前目录；worktree：创建或复用独立 worktree，适合并行工作或当前目录已有改动。
/comet 的提示选择即可，不要手工复制 change 目录。
你会经历什么
open 阶段通过多轮对话 + 多个停顿点逐步生成文档。全程用你触发工作流时用的语言提问和产出文档。
open 阶段把模糊想法过滤成三份可执行的 OpenSpec 产物
第一步：探索想法与澄清需求
Comet 加载openspec-explore，围绕你的想法持续提问，直到能整理出一份完整的澄清摘要。它不会把一次问答当成“够了”。会一直问到这五个部分都清楚：
停顿点 2：PRD 拆分预检查（条件触发）
如果你的输入是一个大型 PRD、路线图或完整产品计划，或者澄清摘要里出现了多个独立能力，Comet 会在这里暂停，给你一份候选拆分清单（每个拆分项含建议名称、目标范围、非目标、依赖顺序、核心验收场景），然后让你三选一：停顿点 3：工作区决策
创建产物和.comet.yaml 之前，Comet 让你确定工作区隔离方式（这一步不能推迟到 build）：
选择结果写入
isolation，实际目录的当前分支记录为 bound_branch，后续入口检查会阻止意外切换分支。hotfix/tweak 预设默认 current。
需求澄清和命名是非阻塞的：范围和命名都明确时，Comet 从需求推导唯一的 kebab-case 英文名（如 refine-requirements-doc）并直接展示；只有存在会改变范围或 change 身份的互斥选择、或名字与已有 change 冲突时才单独询问。确认前不会创建 proposal/design/tasks，也不会用 openspec-propose 一次性生成。
第二步：创建 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 阶段有 3 个停顿点（全局编号 2-4，整个五阶段工作流共 10 个，见五阶段停顿点和用户选择点）：
需求澄清和命名默认非阻塞：范围和命名都明确时直接继续，Comet 从需求推导唯一的 kebab-case 英文名并直接展示；只有存在会改变范围或 change 身份的互斥选择时才单独询问。
所有停顿点都遵循决策点协议——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 的停顿点详解
- 大型 PRD 拆分 — 拆分预检查的完整机制
- 自动推进机制 — open 完成后如何自动衔接 design