/comet。
系统会读取项目配置 .comet/config.yaml。当 default_workflow 为 classic 时，请求会转发到内部入口 /comet-classic，再按 open、design、build、verify、archive 五个阶段执行。
Classic 与 Native 工作流 是两套独立工作流，各自维护自己的 change、状态与产物。
Classic 把 OpenSpec 和 Superpowers 接在同一条可恢复流程里。
OpenSpec 负责 WHAT（需求、提案、spec 生命周期、归档），Superpowers 负责 HOW（brainstorming、技术设计、计划、执行、验证），Comet 负责记录阶段和交接状态。
阶段 Skill 每次都会重读活跃 change、.comet.yaml 与实际文件状态，所以即使对话中断，也能判断当前处于 open、design、build、verify 还是 archive。
Classic 主要适配 Fable 5、GPT-5.6 以下的模型能力档。
这类模型通常更依赖明确的 Spec、设计、计划、TDD、调试和审查步骤。Comet 的基线评估显示，这些约束能更稳定地覆盖任务并完成交付。
如果模型能力达到 Fable 5、GPT-5.6 或更高，一般更适合执行方式更轻的 Native 工作流。
下文用 <classic-root> 表示当前 Classic OpenSpec 根目录：新项目默认是 docs/openspec/，保留旧布局的项目是 openspec/。
实际位置由 classic.artifact_layout 决定，见项目文件结构。
谁该用 Classic
当变更会引入新能力、修改 public API 或 schema、或涉及跨模块协作时，优先使用完整五阶段。
改动小且目标明确时，可优先使用轻量预设：修 bug 走
/comet-hotfix，配置、文档或 prompt 类轻中量修改走 /comet-tweak，两者都跳过 design。
预设执行中命中升级信号时，Comet 会暂停，让你选择继续预设还是升级 full，见下文“轻量预设与升级”。
如果你需要保留可回顾的需求、设计与验证记录，Classic 的五个阶段和归档产物更合适。
如果模型已到 Fable 5、GPT-5.6 档位，并且你希望它自主决定实现与测试方法，Native 工作流 会更轻。
一次 change 你会经历什么
下面以一条完整 full 流程为例，从入口走到归档。 需要你停下做选择的地方都有编号：路由阶段是 1，open 是 2/3/4，design 是 5，build 是 6/7，verify 是 8，archive 是 9，hotfix/tweak 的升级评估是 10。完整清单见五阶段停顿点和用户选择点。 各阶段之间由/comet-classic 自动衔接（auto_transition: false 时改为逐阶段手动推进，见自动推进机制）。
入口：说出目标，路由决定走哪条流程
输入/comet 加一句想做的事。
内部根据你的原话、活跃 change 列表和风险信号，把这次调用路由到六种结果之一：full（完整五阶段）、hotfix、tweak、resume（继续已有 change）、ask_user、out_of_scope（只是在提问）。
几个常见走向：
- 新能力、public API、schema 或跨模块变更多半路由
full，进入/comet-open； - 修已有 bug 且没有新增能力或接口变化，路由
hotfix，进入/comet-hotfix； - 可收敛的轻中量修改，路由
tweak，进入/comet-tweak； - 明确要继续某个 active change，路由
resume，下一步由该 change 当前停在哪一阶段决定。
full、hotfix、tweak、resume 会直接开始。
只有在证据不足、存在多个活跃 change，或你口头指定的流程与风险信号冲突时，才会路由到 ask_user 并在入口等待你选择。
路由的判定依据、风险信号与典型场景见 意图识别与路由。
open：把想法变成 OpenSpec change
路由到full 且没有需要恢复的活跃 change 时，/comet-classic 调用 /comet-open。
Comet 加载 openspec-explore 反复澄清需求，再逐个生成 proposal → design → tasks，遵循项目的 template、instruction 与 dependencies。
过程中你会依次遇到停顿点：
- 输入是大型 PRD 或包含多个独立能力时，停顿点 2 让你选择拆成多个 change、保持一个 change 还是调整拆分方案；
- 停顿点 3 选择工作区隔离方式：
current（当前分支）、branch（新建分支）还是worktree（独立工作区，明确要并行时直接用）； - 停顿点 4 审视产物：确认 change 名称、范围和 proposal/design/tasks 是否符合预期。
<classic-root>/changes/<name>/，包括 .comet.yaml、proposal.md、design.md、tasks.md，以及涉及能力变更时的 delta spec（specs/<capability>/spec.md）。
完整流程禁止一次性 one-shot 生成提案，也禁止跳过 brainstorming。
范围与命名都明确时，需求澄清和命名默认不阻塞，停顿点只出现在真正需要你选择的地方。
open 的逐步操作与产物结构见 open 阶段。
design：确认技术方案（仅 full）
open 完成后，full 流程自动衔接/comet-design。
Comet 先用脚本把 open 阶段的产物整理成 handoff 交接包（不允许 agent 手写摘要代替），再加载 brainstorming，以真实上下文和你探讨实现方案、风险与测试策略。
停顿点 5 请你确认采用的技术方案；确认后生成 Design Doc（docs/superpowers/specs/...-design.md），guard 才推进到 build。
design 阶段不允许 Agent 写第二份需求 spec。
delta spec 缺少验收场景时，只能写 Spec Patch 回写 OpenSpec；改动超出 Spec Patch 边界（接口变化、新组件、数据流变化等）时，回到 brainstorming 重新对齐或另开新 change。
设计细节见 design 阶段。
build：写计划、逐任务实现
/comet-build 先派子代理加载 writing-plans 生成实施计划，然后停顿点 6（build 联合决策）让你一次性决定：立即继续执行还是暂停、换成更强的模型再继续，同时选定执行方式、TDD 模式和审查模式。
之后按你选的方式逐任务实现：
subagent-driven-development：主会话只协调，后台子代理逐任务实现；按review_mode派任务级审查与修复，通过后主会话勾选 tasks.md 并提交；executing-plans：主会话直接执行的轻量路径；- 执行中出现崩溃、测试失败或构建失败时，强制走
systematic-debugging，先定位根因再修复。
verify：验证实现与 spec
/comet-verify 按任务规模跑 light 或 full 检查，通过后把结论保存为验证报告。
可客观修复的失败会自动回 build 修复，前 3 次不打断你；需要你介入的情形都收敛到停顿点 8：第 4 次失败、接受带权衡的 WARNING/SUGGESTION 偏差、或 full 检查发现 delta spec 与 Design Doc 漂移。
漂移时三选一：在 Design Doc 追加 Implementation Divergence 记录偏差、verify-fail 回 build 重新对齐、或接受偏差并继续验证。
验证通过后 guard 推进到 archive，此时 branch_status 保持 pending，是否推送或建 PR 留到归档前再确认。
验证强度与失败处理见 verify 阶段。
archive：确认交付方式并归档
进入 archive 后先做停顿点 9 的最终确认，选项有五个：仅本地归档、归档并推送、归档并推送且创建 PR、回去调整（回 verify 重新验证）、暂不归档。 选“暂不归档”时 change 保持活跃并留在 archive 阶段，不会写任何归档状态。 不放心时可以先用comet archive --dry-run 预览，只报告结果、不执行合并。
确认后 comet archive 委托 OpenSpec CLI 把 delta spec 合并进主 spec，把 change 目录移到 <classic-root>/changes/archive/YYYY-MM-DD-<name>/，为 Design Doc 和计划加归档标注，再创建唯一的归档提交并按所选方式推送或创建 PR。
归档完成后该 change 不再是活跃 change，comet status 不再列出它。
归档步骤见 archive 阶段，命令细节见 comet archive。
五阶段速查表
写入放行：默认情况下，项目内（产物区之外）的写入受 Classic 阶段守卫约束。想让实现代码目录在任意阶段都可修改，在
.comet/config.yaml 配置共享的 hook.allow_paths。详见 Classic 配置 — Hook 写入放行。机制细节与对应页面
Classic 的交接、spec 处理、路由、归档与恢复都有对应页面。 日常使用先看上面两节即可。需要追查具体机制时，再从这里进入对应页面：- 产物交接（handoff 与上下文压缩）：如果你要看交接包和 handoff_hash 的计算方式与阶段作用，先看 comet handoff。如果你要看 off/beta 两种格式和启用时机，再看 上下文压缩机制。handoff 交接包、brainstorm-summary、subagent-progress、验证报告等中间产物的作用，见 工作流中间产物。
- spec 范围与漂移：delta spec 的
ADDED/MODIFIED/REMOVED/RENAMED是 OpenSpec 原生概念，Comet 会使用这些类型，但不做去重。build 中按规模处理 delta spec（小改直接编辑、中改重新对齐、大改开新 change），见 build 阶段 和 中途修改 Spec 或回退工作流。verify 发现 spec 漂移时，对应停顿点 8，见 五阶段停顿点和用户选择点 与 verify 阶段。 - 归档流程：如果你要看 delta 合并、目录移动和产物标注，见 archive 阶段。如果你要看
comet archive命令和--dry-run预览，见 comet archive。 - 路由与阶段判定：六种路由结果如何判定、风险信号如何影响结果，见 意图识别与路由。阶段推进、自动衔接和
auto_transition，见 自动推进机制。 - 你在哪些地方参与：停顿点 1-10 的完整清单、选项和规则，见 五阶段停顿点和用户选择点。
- 阶段 Skill：五阶段由
/comet-classic路由到/comet-open、/comet-design、/comet-build、/comet-verify、/comet-archive。轻量预设走/comet-hotfix、/comet-tweak。正常使用只调用/comet。手动调用这些入口的条件和恢复方式，见各 phases 页面与 恢复中断的工作。
轻量预设与升级
hotfix 与 tweak 都走 open → build → verify → archive（跳过 design），仍保留 OpenSpec 状态、验证与归档。 共同前提是变更能装进单个 OpenSpec change，且不需要 Superpowers 深度设计。/comet-hotfix 适合快速修 bug，无需 Design Doc。
/comet-tweak 适合配置调整、文档或提示词优化，以及 delta spec 驱动的中等变更。在 tweak 里，delta spec 是正式产物，单凭需要 delta spec 不构成升级理由。
两者各自的前提、流程与限制见 hotfix 预设 与 tweak 预设。
预设版的走查是同一流程去掉 design：open 的 guard 完成后直接进入 build 阶段，verify 的失败处理和归档前确认仍然保留。
差异只在两者各自的 build 方式：hotfix 手动逐任务修复（build_mode 默认 direct），tweak 用 OpenSpec 原生的 apply 路径执行。
当变更无法收敛到单个 change，或执行中出现跨模块协调、新 public API、schema 变更、深层架构问题等升级信号时，Comet 会在停顿点 10 暂停，让你选择继续预设还是升级 full。
升级只能走 preset-escalate 这一条合法通道。
升级与中途回退的操作见中途修改 Spec 或回退工作流。
下一步
- 五阶段停顿点和用户选择点 — 你在哪里需要停下决策
- 恢复中断的工作 — 中断、上下文压缩或换设备后继续
- 大型 PRD 拆分 — 把大需求拆成多个可独立交付的 change
- 状态管理 —
.comet.yaml字段与状态守卫 - comet skill — 安装、查看和调试项目 Skill