本阶段如何触发
/comet-build 通常不是你手敲的命令，而是 /comet-classic 自动衔接的结果。
默认：用 /comet 自动衔接
design 阶段退出后（phase: build），/comet-classic 会自动衔接调用 /comet-build。下一次调用 /comet-classic 时，如果检测到 phase: build 或有 Design Doc 但执行未完成，也会路由到 build——hotfix 走 /comet-hotfix、tweak 走 /comet-tweak、full 走 /comet-build。详见自动推进机制。
手动：什么时候才需要直接 /comet-build
- 关闭了自动衔接（
auto_transition: false）——design 完成后/comet-classic会停下并打印 HINT。 - 只想单独跑 build（恢复一个
phase: build的 change 继续执行）。 - verify 失败后通过
comet-state transition verify-fail回滚，需要重新进入 build 修复。
/comet；只有手动控制阶段时才直接调用阶段命令。
你会经历什么
build 阶段有 4 个停顿点（全局编号 6-9，整个五阶段工作流共 13 个，见五阶段停顿点和用户选择点）。下面按发生顺序讲。
build 阶段把计划拆成任务卡片，逐张执行、排错、勾选并留下提交证据
Step 0：入口状态验证
base-ref，grep 找第一个未完成任务。幂等：已提交的任务不会重复提交。
Step 1：创建实施计划
Comet 派子代理加载writing-plans 写计划（这样不占主会话上下文），子代理失败时回退到主会话内联加载。计划 frontmatter 必须含：
停顿点 6：plan-ready 暂停
计划写好后，Comet 暂停等你选：停顿点 7：一次性选定四种工作模式
确认继续后，Comet 一次性问你四个选择（不是分四次问）：1. 隔离方式（isolation）
选择 branch 时，Comet 在同一联合决策里让你确认或覆盖分支名，命名规则：
feature/YYYYMMDD/<name>（full）、hotfix/...（hotfix）、tweak/...（tweak）。三种隔离方式都适用于 full、hotfix 和 tweak；选择结果会写入 isolation，并把实际执行目录的当前分支记录为 bound_branch，后续入口检查会阻止意外切换分支。
2. 执行方式（build_mode）
3. TDD 模式（tdd_mode）
4. 审查模式（review_mode）
详见代码审查机制。
Step 3：逐任务执行
选定后，按build_mode 执行。两种执行方式的体验不同：
子代理（implementer）不能自己勾选任务
——只有主会话在双阶段验收通过后才勾选。审查者拿到的是完整任务 + 实现 commit/diff + RED/GREEN
证据（TDD 时），不能只看实现者摘要就下结论。
Step 3b：异常调试协议（强制）
执行中出现崩溃、测试失败、构建失败或异常行为时，Comet 强制加载systematic-debugging：
- 先定位根因——读完整错误、查最近改动、追数据流。根因调查完成前不得提任何修复。
- 根因是源码 bug 时，先加一个最小失败测试复现，再修源码。
- 修完跑失败测试、相关测试、项目构建/验证命令确认全过。
- 失败测试、源码修复和 tasks.md 勾选都保留在当前 change 内，不要另开”写测试用例”change 替代当前验证循环。
多失败的并行排查
进入四阶段流程前，先做一个失败独立性评估，决定串行还是并行：
满足并行条件时：
- 用 Skill 工具加载 Superpowers
dispatching-parallel-agents。 - 每个独立失败派一个后台排查 agent（按问题域分组，全部派发放在同一条响应里并发执行）。每个 prompt 自包含（具体失败、错误信息、允许排查范围、禁止动其他问题域代码）。
- 所有 agent 仍受”根因定位前不得改源码”约束——它们只定位根因并返回发现，不直接提交修复。
- 所有排查返回后，主会话串行汇总发现并修复；修复仍走当前
review_mode的验证和审查循环。
Step 4：spec 增量更新
执行中发现需要改 spec 时，按规模处理：Step 5：勾选 + 提交
每个任务：按build_mode 执行 → 按 review_mode 审查（如适用）→ 主会话勾选 tasks.md → 提交。勾选用定向验证：
grep -c '\- \[ \]' tasks.md 查剩余未勾选数。
退出
phase: verify，设 verify_result: pending。
调用的 skill
产物
退出条件（guard 检查）
- tasks.md 全部勾选
- 代码已提交
- 显式运行项目 build/test 命令并通过（不要只依赖 guard 自动猜测）
isolation是current、branch或worktree，且当前 Git 分支与bound_branch一致build_mode已选（subagent 模式需subagent_dispatch: confirmed）tdd_mode已选review_mode已选（按 executing-plans review gate 完成：standard/thorough 已请求审查并修复 CRITICAL 或记录非 CRITICAL 接受原因；off 已记录跳过原因）
npm run build、Maven 或 Cargo）并把失败输出作为证据。build_command / verify_command 已移除，不再能写在 .comet.yaml 或仓库根配置里；如果需要固定团队级验证流程，请把它放进项目自己的构建脚本。
恢复
build 阶段幂等。恢复时grep -n '\- \[ \]' tasks.md | head -1 找第一个未完成任务继续。build_pause: plan-ready 的恢复见停顿点 6。上下文压缩后用 comet-state check <name> build --recover 拿恢复上下文；subagent 模式重读 .comet/subagent-progress.md 恢复当前任务和审查轮数，不能在主会话直接执行任务。full workflow 如果停在 plan-ready，恢复动作必须补齐或确认四个选择：isolation、build_mode、tdd_mode 和 review_mode。不要只补前两个就进入执行。
推荐路径
下一步
- verify 阶段 — build 完成后进入验证
- 代码审查机制 — review_mode 详解
- 状态与配置 — build_mode/isolation/tdd_mode 字段
- 五阶段停顿点和用户选择点 — build 的停顿点