Comet

Comet — OpenSpec + Superpowers 双星开发流程

OpenSpec 与 Superpowers 如双星系统围绕同一目标运转。

OpenSpec 负责 WHAT  — 大纲、提案、spec 生命周期、归档
Superpowers 负责 HOW — 技术设计、计划、执行、收尾

核心原则：brainstorming 必不可跳过。每次变更都必须经过深度设计（hotfix 和 tweak 预设除外）。

<IMPORTANT>
本文中的“调用 `/comet-*`”“调用 OpenSpec/Superpowers 技能”均指使用当前平台的 Skill 工具加载对应 Skill，并把必要上下文作为 ARGUMENTS 传入。不得把“调用”降级为在当前 `/comet` 上下文中手工执行子 Skill 的步骤，也不得只按记忆或本文摘要模拟子 Skill。

当路由结果是 /comet-hotfix、/comet-tweak、/comet-open、/comet-design、/comet-build、/comet-verify 或 /comet-archive 时，必须立即用 Skill 工具加载对应的 Comet 子 Skill。该子 Skill 若要求 OpenSpec 或 Superpowers 技能，也必须继续用 Skill 工具加载对应依赖 Skill。Skill 工具调用是 workflow evidence 的一部分。 </IMPORTANT>

决策核心（Decision Core）

agent 做决策只需读本节，参考附录按需查阅。

输出语言规则

以触发本次工作流的用户请求语言作为默认输出语言。恢复已有 change 时，如果现有产物有明确主语言，除非用户明确要求切换，否则保持该语言。

阶段自动检测

Step 0: 活跃 Change 发现与意图判定

1. 先按 comet/reference/scripts.md 完成脚本定位，确保 $COMET_INTENT 可用。
2. 运行 openspec list --json 获取所有活跃 change。
3. 根据用户请求、active change 列表和必要仓库状态填写 CometIntentFrame。
4. 优先用 node "$COMET_INTENT" route --stdin 传入 frame JSON，获取 runtime 规范化路由。CometIntentFrame + runtime scorer 是事实源；本节自然语言规则只用于意图识别槽位提取。
5. 按 runtime route 处理：
   • hotfix → 直接调用 /comet-hotfix
   • tweak → 直接调用 /comet-tweak
   • full → 按活跃 change 表决定 /comet-open 或用户确认
   • resume → 进入 Step 1 读取对应 change 的 .comet.yaml
   • ask_user → 按 comet/reference/decision-point.md 暂停并等待用户选择
   • out_of_scope → 说明本次输入不是 Comet workflow 启动/恢复请求，不初始化 change

CometIntentFrame 最小骨架：

{
  "schema_version": "comet.intent.v1",
  "utterance": "<用户原话>",
  "intent": { "name": "start_change", "confidence": 0.8 },
  "slots": {
    "requested_action": "start",
    "workflow_candidate": "full",
    "user_explicit_workflow": null,
    "change_id": null,
    "existing_behavior": null,
    "new_capability": null,
    "public_api_change": null,
    "schema_change": null,
    "cross_module_change": null
  },
  "context": {
    "active_changes_count": 0,
    "active_change_names": []
  },
  "evidence": [],
  "proposed_route": {
    "name": "ask_user",
    "confidence": 0.5
  }
}

意图识别槽位提取： 字段完整含义见 comet/reference/intent-frame.md；正常路由只需按上方最小骨架填写。

• fix_bug + existing_behavior: true + 无新增 capability/public API/schema/cross-module 信号 → 倾向 hotfix
• 用户明确描述为可收敛为单一 OpenSpec change 的轻量/中等变更，需通过 OpenSpec apply 执行，且不需要完整 /comet 深度设计/plan → 倾向 tweak
• 文案、配置、文档、prompt 或单一 OpenSpec change 的轻中量修改 → 倾向 tweak
• 新增 capability、public API、schema 变更、跨模块协调或架构调整 → 倾向 full
• 多个 active change 且用户未明确 change → ask_user
• 置信度不足、关键 evidence 缺失或用户显式 workflow 与风险信号冲突 → ask_user

<IMPORTANT>
当用户选择「创建新变更」时，**必须调用 `/comet-open`**（禁止直接调用 `/opsx:new`）。
`/comet-open` 负责完整双初始化：OpenSpec artifacts（由内部 `/opsx:new` 创建）+ `.comet.yaml` 状态文件。
直接调用 `/opsx:new` 会缺失 `.comet.yaml`，导致后续阶段判定失败。
</IMPORTANT>

Step 1: 读取 .comet.yaml 状态元数据

优先读取 openspec/changes/<name>/.comet.yaml。不存在时回退到 openspec status --change "<name>" --json、tasks.md 和 docs/superpowers/ 文件检查。

断点恢复规则：

• 每次恢复上下文时，先重新执行 Step 0 和 Step 1，不依赖对话历史判断阶段
• 只要存在 active change 且工作区有未提交改动，必须按 comet/reference/dirty-worktree.md 协议处理。该协议定义了检查步骤、归因分类和禁令，本文件不重复
• 若 phase: build，先检查 build_pause、plan、isolation、build_mode、tdd_mode 和 review_mode（详见下方）：
  • 若 build_pause: plan-ready 但 isolation、build_mode、tdd_mode 和 review_mode 都已经设置，则视为 stale pause：先输出 [COMET] 检测到 stale pause（build_pause=plan-ready 但 isolation/build_mode/tdd_mode/review_mode 已设置），自动清除并继续，再运行 node "$COMET_STATE" set <name> build_pause null，然后读取 tasks.md 的下一个未勾选任务并按 build_mode 恢复执行
  • 若 build_pause: plan-ready 且 plan 文件存在，但 isolation、build_mode、tdd_mode 或 review_mode 尚未设置，回到 /comet-build 的 plan-ready 恢复点，提示用户继续补齐/确认工作区隔离、执行方式、TDD 模式和代码审查模式，不重新生成 plan
  • 若 build_pause: plan-ready 但 plan 文件缺失，回到 /comet-build 处理状态损坏或重新生成 plan
  • 若 isolation、build_mode、tdd_mode 或 review_mode 未设置，回到 /comet-build 对应步骤补充后再执行
  • 若均已设置，读取 tasks.md 的下一个未勾选任务，并按 build_mode 恢复执行：
    • 若 build_mode: subagent-driven-development，不得在主窗口直接执行任务；必须回到 /comet-build 的后台 subagent 调度规则，由主窗口只做协调
    • 其他执行方式按 /comet-build 的对应规则继续
• 若 phase: verify 且 verify_result: fail，进入验证失败决策阻塞点：暂停并询问用户修复或接受偏差；用户选择修复后才运行 node "$COMET_STATE" transition <name> verify-fail 并调用 /comet-build
• 若 phase: open 但 proposal/design/tasks 已完整，先运行 node "$COMET_GUARD" <change-name> open --apply 修正状态，再继续判定
• 若 phase: archive，只允许调用 /comet-archive；/comet-archive 必须先等待归档前最终确认，归档成功后 change 会移动到 archive 目录，不再对原活跃目录运行 guard

Step 2: 阶段判定（按顺序，命中即停）

1. archived: true 或 change 已移入 archive → 流程已完成
2. verify_result: pass 且 archived 不是 true → /comet-archive（先进行归档前最终确认）
3. verify_result: fail → 进入验证失败决策阻塞点（暂停询问修复或接受偏差；用户选择修复后才 verify-fail 并 /comet-build）
4. phase: verify 或 tasks.md 全部勾选 → /comet-verify
5. phase: build 或已有 Design Doc 但计划/执行未完成 → 优先按 workflow 路由：hotfix → /comet-hotfix，tweak → /comet-tweak，full → /comet-build
6. phase: design 或有 change 但无 Design Doc → /comet-design
7. phase: open 或有活跃 change 但 .comet.yaml 缺失 → /comet-open
8. 无活跃 change → /comet-open

如果元数据与文件状态冲突，以文件状态为准，修正 .comet.yaml 后继续。

预设升级判定

hotfix/tweak 的范围判定采用三层分工，避免「用纯文件数当硬性升级条件」误杀正常小改动：

1. 质变信号（agent 语义识别，命中任一即暂停交用户二选一）：跨模块协调修改、需要新增 capability、数据库 schema 变更、引入新的 public API、触及深层架构问题（各预设沿用这套核心信号，并可追加自身语境的特有信号，如 tweak 的「需要拆分为多个 OpenSpec changes」）
2. 文件数 tripwire（用户拍板，非自动升级）：改动文件数超提示阈值时，暂停交用户决定继续预设流程还是升级 full，不自动踢
3. 验证级别（scale 脚本判定）：comet-state scale 仅决定 verify_mode（验证轻重），不卡流程、不触发升级

升级决策点（用户二选一）：

• 继续预设轻量流程（用户确认范围可控）
• 升级为完整 /comet（使用 node "$COMET_STATE" transition <name> preset-escalate 合法回退到 design 阶段，补 Design Doc 和 Superpowers plan）

详细判定规则见 comet-hotfix / comet-tweak 各自的「升级判定」章节。