Menu
仅在用户明确调用 /comet-open，或由 Comet 根 Skill/runtime 路由到 open 阶段时使用；创建或恢复 OpenSpec change，并补齐 proposal/design/tasks/.comet.yaml。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use only when explicitly invoked as /comet-any or when the user explicitly wants to customize the /comet-classic five-phase workflow or create/upgrade a workflow Skill managed by Comet Creator. Do not use for general Skill authoring, cleanup, or review.
Use only when explicitly invoked as /comet-archive or routed by the root Comet skill/runtime to the archive phase; confirm archive, merge delta specs, and finish the branch.
Use only when explicitly invoked as /comet-build or routed by the root Comet skill/runtime to a full workflow build phase; create or recover the implementation plan and execute tasks.
Use when the user explicitly invokes /comet-classic, asks to start or resume the permanent Comet Classic workflow, or repository evidence identifies one unambiguous active Classic change; route through the intent runtime and .comet.yaml.
Use only when explicitly invoked as /comet-design or routed by the root Comet skill/runtime to a full workflow design phase; create or recover the deep technical Design Doc.
Use only when explicitly invoked as /comet-hotfix or routed by the root Comet skill/runtime to the hotfix preset; fix an existing behavior bug, not an ordinary unmanaged bugfix.
| name | comet-open |
| description | 仅在用户明确调用 /comet-open，或由 Comet 根 Skill/runtime 路由到 open 阶段时使用；创建或恢复 OpenSpec change，并补齐 proposal/design/tasks/.comet.yaml。 |
传递给 OpenSpec 的所有提问和产物要求都必须包含解析后的 Comet 产物语言，并使用 en、zh-CN 这类规范化 ID。.comet.yaml 尚不存在时依次读取项目 .comet/config.yaml 和全局 ~/.comet/config.yaml 的 classic.language；change 初始化后使用 comet state get <name> language 读取。没有配置语言时才回退到当前用户请求语言。生成的 proposal.md、design.md、tasks.md 必须以该语言为主语言。
恢复已有 change 时先检查 openspec/changes/<change-name>/.comet.yaml：
comet state init <change-name> full，再选择 changestate set 覆盖损坏文件comet state select <change-name>
创建新 change 时，必须先完成 .comet.yaml 初始化，再立即运行同一命令；状态文件不存在前不得伪造选择。
在任何 OpenSpec 状态或指令命令前运行：
openspec --version
本流程要求 OpenSpec >= 1.5.0。版本低于 1.5.0、无法解析版本、命令不可用或返回非零退出码时立即停止，并提示运行 npm install -g @fission-ai/openspec@latest 后重试；不得继续使用缺少 applyRequires、artifactPaths、changeRoot 或 resolvedOutputPath 契约的旧 CLI。
立即执行： 使用 Skill 工具加载 openspec-explore 技能。禁止跳过此步骤。
技能加载后，按其指引探索问题空间，但不得把一次问答视为足够澄清。必须围绕下列内容继续提问、对齐并形成澄清摘要：
澄清摘要必须包含：目标、非目标、范围边界、关键未知项、验收场景草案。
当用户输入是大型 PRD、路线图、完整产品方案，或澄清摘要显示包含多个独立能力、模块、用户路径或里程碑时，必须在创建 OpenSpec artifacts 前评估是否需要拆分为多个 change。
拆分预检必须基于已澄清的信息，输出候选拆分清单。每个候选拆分项必须包含：
满足任一条件时，应推荐拆分：
如推荐拆分，必须按 comet/reference/decision-point.md 的协议暂停并等待用户选择。
用户选择必须包含：
每个被接受的拆分项都必须通过 /comet-open 创建独立 change，不得直接调用 /opsx:new。/comet-open 负责同时创建 OpenSpec artifacts 和 .comet.yaml，确保每个 change 都进入 Comet 状态机。
不得在用户完成 PRD 拆分选择前创建 proposal.md、design.md 或 tasks.md。若用户选择创建多个 change，当前 /comet-open 调用只负责完成拆分确认与调度，随后按用户确认的顺序分别进入每个拆分项的 /comet-open。
用户确认创建多个 changes 后，必须立即把确认结果持久化到 .comet/batches/<batch-id>.json。batch-id 使用稳定的 kebab-case 标识；文件至少记录 version、原始目标摘要、创建时间、按顺序排列的 change 名称，以及每项的目标、范围、非目标、验收场景和 pending|open-complete|selected 状态。每创建或完成一个拆分项后原子更新该文件。它只是批量编排清单，不替代各 change 的 .comet.yaml。
批量拆分模式下，进入每个拆分项的 /comet-open 时必须明确标注「已确认拆分项」并携带该拆分项的目标、范围、非目标和验收场景。已确认拆分项默认跳过 PRD 拆分预检，除非该拆分项本身仍明显包含多个独立 capability。
批量拆分模式下，单个拆分项完成 open 阶段后不得自动流转到 /comet-design。拆分完毕后必须暂停询问用户开始哪一个 change；用户选择后，只推进该 change 进入 /comet-design，其他 change 保持 active，稍后通过 /comet-classic 恢复。
批量完成硬性检查（不得跳过）：全部拆分项完成各自的 open 阶段后，对用户确认清单中的每个 <name> 逐个运行：
openspec status --change "<name>" --json
comet state check <name> design
解析 OpenSpec JSON 时必须同时确认：
changeRoot 解析后必须等于仓库内 openspec/changes/<name>；不匹配时停止，Classic runtime 不支持仓库外 change rootproposal、design、tasks；允许存在额外 artifacts，但核心 ID 缺失时停止并报告不兼容 schemaapplyRequires 列出的每个 artifact 在 artifacts 中都必须为 doneartifactPaths.<artifact-id>.existingOutputPaths（或 instructions 返回的 resolvedOutputPath）对应的实际输出必须存在且非空isComplete 仅作诊断信息；不能替代 applyRequires 的实现就绪判定，也不能要求非必需 artifact 阻塞阶段推进任一拆分项未通过检查时，不得宣告拆分完成，也不得询问用户开始哪个 change；必须停止并从该 change 的第一个 ready 或 blocked artifact 恢复 /comet-open。OpenSpec 检查通过但 Comet state 检查失败时，必须先修复 .comet.yaml 初始化或 phase，再重新执行整批检查。
只有所有拆分项都通过两项 CLI 检查后，才暂停询问用户开始哪一个 change；用户选择后，把批量清单中的该项标记为 selected，只推进该 change 进入 /comet-design，其他 change 保持 active，稍后通过 /comet-classic 恢复。
断点恢复时先读取 .comet/batches/<batch-id>.json，再对清单中已创建的 active changes 运行上述 CLI 检查；已完整通过的拆分项不得重复创建，未通过的拆分项从 OpenSpec 返回的第一个 ready artifact 继续。未创建项按持久清单继续创建。清单缺失或损坏时停止并请求用户重建/确认，不能从目录列表猜测原始批次边界。
创建 OpenSpec artifacts 前，把 Step 1 的澄清结果整理为 resolved brief：目标、非目标、范围边界、关键未知项和验收场景草案，并基于它派生一个能准确表达范围的 kebab-case 英文 change 名称。
comet/reference/decision-point.md 提出一个联合问题；命名偏好本身不是独立阻塞点OpenSpec change 名称必须是 kebab-case 英文（小写字母、数字、单连字符）。若名称冲突但目标仍明确，派生一个不冲突且语义稳定的名称并继续；只有无法判断应复用现有 change 还是创建新 change 时才交给用户选择。
resolved brief 或 change 名称仍不明确时不得运行 openspec new change，也不得创建 proposal/design/tasks；继续澄清或处理真正的用户决策后再进入 Step 2。
立即执行： 使用 Skill 工具加载 openspec-new-change 技能。禁止跳过此步骤。
完整 /comet-classic 流程默认不得使用 Skill 工具加载 openspec-propose 技能；只有用户明确要求一次性生成提案和 artifacts 时才允许加载。
技能加载后，按其指引创建 change 骨架；当 Step 1b 已形成范围明确的 resolved brief 时，覆盖其"STOP and wait for user direction"行为，避免重复询问。
直接使用 Step 1b 的 resolved brief 填充产物内容。只有 brief 仍有会改变范围的歧义时，才回退到技能的提问流程。
change 骨架创建后立即初始化可恢复状态，不能等 artifacts 全部生成后再写 .comet.yaml：
comet state init <name> full
comet state select <name>
comet state check <name> open
任一命令失败都停止。随后运行一次 openspec status --change "<name>" --json 并执行兼容性预检：
changeRoot 解析后必须等于当前仓库的 openspec/changes/<name>，planningHome（如存在）也必须位于当前仓库；不支持仓库外 artifact 路径artifacts 必须包含核心 ID proposal、design、tasks，额外 artifacts 允许存在applyRequires 必须是可解析的 artifact ID 列表，且每个 ID 都存在于 artifacts预检通过后，按 OpenSpec CLI 返回的 schema 和依赖图生成实现所需 artifacts：
OpenSpec 状态驱动产物循环：
运行 openspec status --change "<name>" --json 并解析完整 JSON。
若 applyRequires 中每一项都已是 done，退出循环；isComplete 只记录为诊断信息，不作为阶段阻塞条件。
从尚未完成且为 status: "ready" 的 artifacts 中，优先选择能够推进 applyRequires 依赖闭包的项，并按 CLI 返回顺序处理。不得硬编码生成顺序，也不得假设 schema 只有 proposal/design/tasks。
对每个 ready 的 <artifact-id> 获取实时指令：
openspec instructions <artifact-id> --change "<name>" --json
对返回的 JSON 指令载荷，必须：
dependencies 中列出的每个已完成依赖产物template 作为产物结构instruction 的指引context 和 rules 作为约束条件应用，不得复制到 artifact 内容中resolvedOutputPath；通配输出必须按 instruction 创建每个实际文件每创建一个 artifact 后，重新运行 status，并再次校验 changeRoot、核心 ID 和 applyRequires。已经变为 done 的项不得重复生成；新变为 ready 的项进入下一轮。
阻塞与失败处理：applyRequires 尚未全部完成但没有任何可推进其依赖闭包的 ready artifact 时，必须报告相关 blocked artifact 的 missingDeps 并停止，不得猜测顺序或跳过依赖。如果 openspec status / openspec instructions 失败、返回无效 JSON、路径逃逸仓库、或未提供可用的 resolvedOutputPath，也必须立即停止并报告 OpenSpec 错误。不得回退为硬编码文档结构。
命名与范围守卫：change name 必须使用 Step 1b 解析出的 kebab-case 英文名，不得使用非 kebab-case（如中文）名称。变更范围必须与 resolved brief 和用户描述一致，不得自行扩大或缩小。
确认以下产物已创建：
openspec/changes/<name>/
├── .openspec.yaml
├── .comet.yaml
├── proposal.md # Why + What：问题、目标、范围
├── design.md # How（高层框架）：架构决策、方案选型（深度技术设计在 design 阶段 Design Doc 细化）
└── tasks.md # 任务清单（勾选框）
验证状态机已正确初始化：
comet state check <name> open
验证通过后继续 Step 4。验证失败时脚本会输出具体失败原因。
幂等恢复算法：open 阶段所有操作可安全重复执行。恢复时按以下顺序处理：
comet state init <name> full；格式异常时停止并修复，不得覆盖。随后选择 change 并运行 comet state check <name> open。openspec status --change "<name>" --json，重新验证 changeRoot、核心 ID、applyRequires、artifacts 和 missingDeps。done：该 artifact 已完成，保持原文件不变，不重复生成。ready：依赖已经满足，可以生成。先运行该 artifact 的 openspec instructions，按返回内容写入；写完后立刻重新运行 status。blocked：读取 missingDeps，先完成属于 applyRequires 依赖闭包的依赖 artifact；每完成一个依赖都重新运行 status，不能直接生成 blocked artifact。applyRequires 全部为 done。如果必需依赖图无法推进，必须列出相关 blocked artifact 及其 missingDeps 后停止并报告。目录或固定三个文件存在不能替代 CLI 判定；反过来，非 applyRequires 的可选 artifact 也不能仅因 isComplete: false 阻塞进入实现阶段。
再次运行 openspec status --change "<name>" --json，确认核心 ID 存在、applyRequires 每项均为 done，且这些必需 artifacts 的 artifactPaths.<id>.existingOutputPaths 返回的实际输出文件存在且非空。任一条件不满足时，不得进入 Step 5 或执行阶段守卫。
随后检查关键 artifact 内容：proposal 覆盖问题、目标、范围和非目标；design 覆盖高层决策与数据流；tasks 包含明确任务；schema 返回 specs 等其他 artifact 时，也必须按其 instructions 检查内容，不能因固定三件套存在而跳过。
全部 OpenSpec artifacts 完成且内容完整性检查通过后，必须按 comet/reference/decision-point.md 的协议暂停并等待用户确认。不得在用户确认前执行阶段守卫或自动流转。
最终审视同时确认 change 名称、范围和产物内容；不得因 Step 1b 已完成解析而省略，也不得在此之前再增加一次常规摘要/命名确认。
用户确认问题必须以单选题形式呈现，包含以下摘要和选项：
摘要内容：
选项：
用户选择「确认」后继续执行退出条件。用户选择「需要调整」时，按其说明修改对应文件，然后重新请求确认。
openspec status --change "<name>" --json 的兼容性预检通过，applyRequires 全部为 done 且必需输出非空comet guard <change-name> open --apply，全部 PASS 后由守卫推进到下一阶段（此步骤更新 phase 字段，与 auto_transition 无关）退出前必须使用 --apply，否则 .comet.yaml 仍停留在 phase: open，下一阶段入口检查会失败。
comet guard <change-name> open --apply
完整流程会自动更新为 phase: design；hotfix/tweak 预设会自动更新为 phase: build。
按 comet/reference/auto-transition.md 执行。关键命令：
comet state next <change-name>
NEXT: auto → 调用 SKILL 指向的 skill 进入下一阶段NEXT: manual → 不调用下一 skill，按 HINT 交还控制权并结束当前调用；不再创建确认点NEXT: done → 流程已完成，无需继续hotfix/tweak 预设由对应预设 Skill 控制后续流转（phase 直接进入 build），其 next 会返回对应预设 Skill。