Menü
Comet 阶段 1：开启。用 /comet-open 调用。通过 OpenSpec 探索想法、确认需求澄清，再创建 change 结构（proposal + design + tasks）。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Comet 阶段 5：归档。用 /comet-archive 调用。按 OpenSpec delta 语义合并主 spec，归档 change。
Comet 阶段 3：计划与构建。用 /comet-build 调用。制定计划并选择执行方式（subagent 或直接执行）实施。
Comet 阶段 2：深度设计。用 /comet-design 调用。通过 brainstorming 产出 Design Doc 和 delta spec。
Comet 预设路径：Bug fix / 热修复。跳过 brainstorming，直接 open → build → verify → archive。适用于行为修复、不涉及新 capability 设计的场景。
Comet — OpenSpec + Superpowers 双星开发流程。用 /comet 启动，自动检测阶段并分发到子命令。五阶段：开启 → 深度设计 → 计划与构建 → 验证与收尾 → 归档。
Comet 预设路径：非 bug 的小改动（tweak）。跳过 brainstorming 和完整 plan，直接 open → lightweight build → light verify → archive。适用于文案、配置、文档或 prompt 的局部优化。
| name | comet-open |
| description | Comet 阶段 1：开启。用 /comet-open 调用。通过 OpenSpec 探索想法、确认需求澄清，再创建 change 结构（proposal + design + tasks）。 |
传递给 OpenSpec 的所有提问和产物要求都必须包含输出语言约束：使用触发本次工作流的用户请求语言。恢复已有 change 且产物已有明确主语言时，除非用户明确要求切换，否则保持该语言。
立即执行： 使用 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。
批量拆分模式下，进入每个拆分项的 /comet-open 时必须明确标注「已确认拆分项」并携带该拆分项的目标、范围、非目标和验收场景。已确认拆分项默认跳过 PRD 拆分预检，除非该拆分项本身仍明显包含多个独立 capability。
批量拆分模式下，单个拆分项完成 open 阶段后不得自动流转到 /comet-design。拆分完毕后必须暂停询问用户开始哪一个 change；用户选择后，只推进该 change 进入 /comet-design，其他 change 保持 active，稍后通过 /comet 恢复。
最小断点恢复规则：不新增专用批量状态文件。若批量拆分过程中断，恢复时先检查已创建的 active changes；已存在且包含 .comet.yaml 的拆分项不得重复创建，未创建的拆分项按用户已确认的拆分清单继续通过 /comet-open 创建。若对话中已确认的拆分清单不可恢复，必须重新向用户确认拆分清单后再继续。
创建 OpenSpec artifacts 前，必须按 comet/reference/decision-point.md 的协议暂停并等待用户确认需求澄清完成。
暂停时必须展示澄清摘要：目标、非目标、范围边界、关键未知项、验收场景草案。
不得在用户确认需求澄清完成前创建 proposal.md、design.md 或 tasks.md，也不得使用 Skill 工具加载 openspec-propose 技能一次性生成全部 artifacts。
创建 change 目录（openspec new change）前，必须按 comet/reference/decision-point.md 的协议暂停，让用户决定 change 名称。不得自动生成或静默推断 change 名称。
OpenSpec change 名称必须是 kebab-case 英文（小写字母、数字、连字符；如 refine-requirements-doc）。中文或其他不合规名称无效。
暂停时必须展示：
决策选项必须包含：
不得在用户确认最终 change 名称前运行 openspec new change 或创建 .comet.yaml。若选定/转换后的名称与已有 change 冲突，必须报告冲突并请用户另选名称。
立即执行： 使用 Skill 工具加载 openspec-new-change 技能。禁止跳过此步骤。
完整 /comet 流程默认不得使用 Skill 工具加载 openspec-propose 技能；只有用户明确要求一次性生成提案和 artifacts 时才允许加载。
技能加载后，按其指引创建 change 骨架，但当 Step 1b 的已确认澄清摘要已存在于对话上下文时，覆盖其"STOP and wait for user direction"行为。
如果用户已确认澄清摘要（Step 1b），直接使用该摘要填充产物内容。如果不存在澄清摘要（边缘情况），回退到技能的默认行为，询问用户。
change 骨架创建后，按以下标准产物循环逐个生成 proposal、design、tasks：
标准产物循环（对每个 artifact-id：proposal → design → tasks）：
刷新状态：openspec status --change "<name>" --json
获取产物指令：
openspec instructions proposal --change "<name>" --json
openspec instructions design --change "<name>" --json
openspec instructions tasks --change "<name>" --json
对返回的 JSON 指令载荷，必须：
dependencies 中列出的每个已完成依赖产物template 作为产物结构instruction 的指引context 和 rules 作为约束条件应用，不得复制到 artifact 内容中resolvedOutputPath每创建一个 artifact 后，重新运行 openspec status --change "<name>" --json 确认状态，然后继续下一个 artifact
失败处理：如果 openspec instructions 失败、返回无效 JSON、报告未满足的 dependencies、或未提供可用的 resolvedOutputPath，必须立即停止 artifact 创建并报告 OpenSpec 错误。不得回退为硬编码文档结构，因为那样会绕过项目规则。
命名与范围守卫：change name 必须使用 Step 1c 中用户确认的 kebab-case 英文名，不得自动生成、推断或使用非 kebab-case（如中文）名称。变更范围必须与用户描述一致，不得自行扩大或缩小。
确认以下产物已创建：
openspec/changes/<name>/
├── .openspec.yaml
├── .comet.yaml
├── proposal.md # Why + What：问题、目标、范围
├── design.md # How（高层）：架构决策、方案选型
└── tasks.md # 任务清单（勾选框）
创建 .comet.yaml 状态文件：
COMET_ENV="${COMET_ENV:-$(find . "$HOME"/.*/skills "$HOME/.config" "$HOME/.gemini" -path '*/comet/scripts/comet-env.sh' -type f -print -quit 2>/dev/null)}"
if [ -z "$COMET_ENV" ]; then
echo "ERROR: comet-env.sh not found. Ensure the comet skill is installed." >&2
return 1
fi
. "$COMET_ENV"
if [ -z "$COMET_STATE" ] || [ -z "$COMET_GUARD" ]; then
echo "ERROR: Comet scripts not found. Ensure the comet skill is installed." >&2
return 1
fi
"$COMET_BASH" "$COMET_STATE" init <name> full
验证状态机已正确初始化：
"$COMET_BASH" "$COMET_STATE" check <name> open
验证通过后继续 Step 4。验证失败时脚本会输出具体失败原因。
幂等性：open 阶段所有操作可安全重复执行。如 .comet.yaml 已处于 phase: open 且三个产物文件均已存在，跳过已完成步骤，从第一个缺失步骤继续。
确认三个文档内容完整：
文件存在性验证：逐个确认三个文件路径存在且非空。任一文件缺失或为空时，不得进入 Step 5 或执行阶段守卫，必须回到创建步骤补充。
三个文档创建完成且内容完整性检查通过后，必须按 comet/reference/decision-point.md 的协议暂停并等待用户确认。不得在用户确认前执行阶段守卫或自动流转。
用户确认问题必须以单选题形式呈现，包含以下摘要和选项：
摘要内容：
选项：
用户选择「确认」后继续执行退出条件。用户选择「需要调整」时，按其说明修改对应文件，然后重新请求确认。
"$COMET_BASH" "$COMET_GUARD" <change-name> open --apply，全部 PASS 后由守卫推进到下一阶段（此步骤更新 phase 字段，与 auto_transition 无关）退出前必须使用 --apply，否则 .comet.yaml 仍停留在 phase: open，下一阶段入口检查会失败。
"$COMET_BASH" "$COMET_GUARD" <change-name> open --apply
完整流程会自动更新为 phase: design；hotfix/tweak preset 会自动更新为 phase: build。
按 comet/reference/auto-transition.md 执行。关键命令：
"$COMET_BASH" "$COMET_STATE" next <change-name>
NEXT: auto → 调用 SKILL 指向的 skill 进入下一阶段NEXT: manual → 不要调用下一 skill，按 HINT 提示用户手动运行 /<SKILL>NEXT: done → 流程已完成，无需继续hotfix/tweak preset 由对应 preset skill 控制后续流转（phase 直接进入 build），其 next 会返回对应 preset skill。