Skip to main content
本页回答 Classic 五阶段、状态恢复、Guard 和轻量预设的常见问题。

​
基础概念

Comet 不替代任何一方。OpenSpec 负责 WHAT（需求、提案、spec 生命周期、归档），Superpowers 负责 HOW（brainstorming、技术设计、计划、执行、验证）。Comet 把两者串成一条可恢复的五阶段工作流，并用状态机和守卫保证交接可靠。详见工作流概念。
用户统一调用 /comet；项目配置选择 Classic 后，内部永久入口 /comet-classic 驱动 open/design/build/verify/archive 五阶段流程。/comet 是项目配置驱动的统一别名，可能进入 Native 或 Classic。/comet-any 是 Skill Creator，用来创建、优化、组合可复用的 Skill；三者职责不同。
经典 Spec 模式依赖两者——OpenSpec 记录需求规格，Superpowers 提供设计/执行方法论。使用 comet init --workflow classic 时会安装两者；新的项目级 comet init 默认使用不依赖它们的 Native。如果你只想用 Comet 的 Skill 平台能力（用 /comet-any 组合任意 Skill，生成可验证、可评审、可分发的 Skill Bundle），可以从组合任意 Skill 快速上手开始。

​
与相似产品的区别

两者都想把 OpenSpec 和 Superpowers 结合成一条工作流，但实现形态和保障级别完全不同。superpowers-bridge 是一个 OpenSpec 原生 schema bundle：你把它拷进项目当前 OpenSpec 根目录的 schemas/（Classic 新项目默认是 docs/openspec/schemas/，保留旧布局的项目是 openspec/schemas/），用 --schema superpowers-bridge 按 change 选择。它是纯 prompt 层集成——不改 Superpowers 源码、不改 OpenSpec CLI，靠 schema.yaml 里的产物 DAG（brainstorm → proposal → design → specs → tasks → plan → verify → retrospective）和纯文字的 PRECHECK 约束顺序。它还补了一个 Superpowers 原生缺失的、以证据为先的 retrospective 产物。Comet 是一个独立的 npm 包（@rpamis/comet），带跨平台 Node runtime、.comet.yaml 状态机、hook 硬拦截、诊断和恢复。两者核心差异：
相对 superpowers-bridge 这类纯 schema 集成，Comet 的优势集中在四点：
  1. 可恢复的状态机：.comet.yaml 显式记录 phase、build_mode、tdd_mode、review_mode，长任务或上下文压缩后可以直接从这些状态精确恢复断点。
  2. 硬性执行防线：Comet 有 comet-hook-guard.mjs（PreToolUse hook）做硬拦截，加上每轮注入的 phase-guard 规则——比如 design 阶段禁止写源码、非法跳过阶段会被拦下。纯 schema 的 PRECHECK 只是文字约束，模型可以”读到但不执行”。
  3. 入口稳定且跨平台：意图路由可以从自然语言请求直接进入对应阶段，不依赖固定的 /opsx:* 触发方式；同时不强制绑定 subagent 平台。
  4. 其他产品入口：/comet-any 创建和组合 Skill，comet eval 评估本地 Skill，comet dashboard 查看 change。
如果你只想在 OpenSpec 里加一层 Superpowers 且不介意手动驱动，superpowers-bridge 更轻量；要长任务可恢复性、防漂移强约束、多平台和 Skill 平台能力，Comet 更合适。想了解 Comet 的运行时、工作流、评估和 Skill 创作分别对应哪些业界实践，可以进一步阅读 Comet 与业界实践对照。

​
状态与恢复

Comet 不依赖聊天历史。每次调用 /comet 并由配置进入 Classic 后，内部 /comet-classic 都会重新读取活跃 change 的 .comet.yaml 和 OpenSpec artifacts，判断当前阶段和证据是否一致，然后路由到正确的阶段 Skill。
这个 change 可能是用原始 /opsx:new 创建的，缺少 .comet.yaml，会被 comet status 静默跳过。在 Agent 平台调用 /comet 并由配置进入 Classic 让它接管补上状态文件。详见存量项目接入的”孤儿 change”。
用户可见字段（workflow、phase、build_mode 等）原则上通过 /comet-classic 和阶段守卫流转，不要手工改 phase。由 Comet 自动维护的运行状态字段（machine-owned，在 .comet/run-state.json 或 .comet/runs/<run-id>）绝对不要手工改。排障时可以用 comet-state 命令，详见状态管理。
design 阶段写了 brainstorm-summary.md 作为恢复检查点，build 阶段的子代理有持久化 checkpoint。恢复时调用 /comet；配置进入 Classic 后，内部路由会直接读取文件状态并定位断点。详见恢复中断的工作。

​
阶段与守卫

Comet 的核心原则是 brainstorming 不可跳过（hotfix/tweak 预设除外）。完整工作流的 guard 会检查 design_doc 是否存在，缺失会 FATAL。跳过设计会导致后续阶段缺乏技术依据。
不要直接归档。前 3 次可修复的失败会自动回 build 修复，不会问你；第 4 次失败或需要接受 WARNING/SUGGESTION 偏差时才暂停让你选择：继续修复、接受偏差（记录原因）或退回重新 brainstorming。verify_result: fail 时归档会被 guard 阻止。
阶段推进由 guard 脚本 comet-guard.mjs --apply 完成。auto_transition: true（默认）时，一个阶段完成后自动调用下一个阶段 Skill；auto_transition: false 时暂停，按 HINT 手动运行。阶段推进本身一定发生，这个设置只影响是否自动调用下一个 Skill。
说明 design 阶段生成 handoff 后，OpenSpec artifacts（proposal/design/tasks/spec）被修改了。解决方法是重新运行 comet-handoff 让 Superpowers 拿到当前 OpenSpec 上下文。详见comet-handoff 脚本与上下文压缩机制。

​
轻量预设与大需求

两者都跳过完整 brainstorming，保留 OpenSpec 状态、验证和归档。hotfix 适合复现路径明确的 bug 修复；tweak 适合范围明确的小改动。出现跨模块协调、新 public API、schema 变更时应升级 full。详见hotfix 预设。
/comet-open 会在创建产物文件前触发 PRD 拆分预检查，把大需求拆成多个可独立设计、交付、归档的 change。详见大型 PRD 拆分。
review_mode（off/standard/thorough）控制 build 和 verify 阶段的自动代码审查强度。full workflow 必须在离开 build 前选择；hotfix 默认 off。可在 .comet/config.yaml 的 classic.review_mode 设置项目默认值。

​
常见问题

自动提交是 Superpowers 自身的行为。你可以让 AI 生成一个拦截 git commit 的 hook 或 rule 来阻止它。
先让 Agent 停下，不要继续写代码。然后按你实际做过什么处理：
  • 你改了 spec、design 或 tasks：直接再次调用 /comet。配置进入 Classic 后，Comet 会重新读取 .comet.yaml 和 OpenSpec artifacts，按当前 phase 恢复到正确阶段。
  • 你自己改了代码：也再次调用 /comet，并告诉 Agent：“我改过代码，请按当前工作区恢复。” Comet 会检查工作区的未提交改动并判断它们属于哪个阶段。
如果 spec 和代码都改了，也先用 /comet 恢复。你需要说明这些改动是否代表新方案；不要手工改 .comet.yaml 的 phase 或 .comet/run-state.json。Comet 会从当前文件状态和持久化 artifacts 恢复。
Comet 的 Full 流程面向复杂需求和功能：多轮澄清、可选的 TDD 执行和 Review，过程严格，因此 Token 消耗较高。需要轻量快速交付时，使用 comet-tweak 和 comet-hotfix 预设；小需求也可以直接用 Plan 或 /loop 替代。
最后修改于 2026年9月4日