Menu
仅在用户明确调用 /comet-build，或由 Comet 根 Skill/runtime 路由到 full workflow 的 build 阶段时使用；创建或恢复实施计划并执行任务。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use only when explicitly invoked as /comet-any or when the user explicitly wants to customize the /comet-classic five-phase workflow or create/upgrade a workflow Skill managed by Comet Creator. Do not use for general Skill authoring, cleanup, or review.
Use only when explicitly invoked as /comet-archive or routed by the root Comet skill/runtime to the archive phase; confirm archive, merge delta specs, and finish the branch.
Use only when explicitly invoked as /comet-build or routed by the root Comet skill/runtime to a full workflow build phase; create or recover the implementation plan and execute tasks.
Use when the user explicitly invokes /comet-classic, asks to start or resume the permanent Comet Classic workflow, or repository evidence identifies one unambiguous active Classic change; route through the intent runtime and .comet.yaml.
Use only when explicitly invoked as /comet-design or routed by the root Comet skill/runtime to a full workflow design phase; create or recover the deep technical Design Doc.
Use only when explicitly invoked as /comet-hotfix or routed by the root Comet skill/runtime to the hotfix preset; fix an existing behavior bug, not an ordinary unmanaged bugfix.
| name | comet-build |
| description | 仅在用户明确调用 /comet-build，或由 Comet 根 Skill/runtime 路由到 full workflow 的 build 阶段时使用；创建或恢复实施计划并执行任务。 |
按 comet/reference/scripts.md 使用稳定 comet CLI，然后执行入口验证；从任意入口恢复时先按 comet/reference/context-recovery.md 运行恢复检查：
comet state select <change-name>
comet state check <name> build
验证通过后继续 Step 1。验证失败时脚本会输出具体失败原因。
若上述 select / check 输出 BLOCKED，且原因是 bound_branch 与当前分支不一致，立即按 comet/reference/decision-point.md 暂停，让用户单选：切回绑定分支后重新运行入口验证，或在用户明确确认当前分支应接管该 change 后运行 comet state rebind <change-name> 并重新入口验证。不得自行切换分支，不得自行换绑。
幂等性：build 阶段所有操作可安全重复执行。读取 .comet.yaml 的 phase 字段确认仍在 build 阶段，读取 plan 文件头的 base-ref，再按文档顺序解析 tasks.md 的复选框，从第一个未勾选任务继续执行。已提交的任务不得重复提交。
通过 subagent 创建实施计划，避免 planning skill 占用主 session 上下文。计划文件和执行反馈必须使用 comet state get <name> language 读取到的 Comet 配置产物语言。
Subagent 指令：
你是实施计划专家。基于以下输入创建实施计划：
writing-plans 技能。禁止跳过此步骤。技能加载后，ARGUMENTS 必须包含：Language: 使用 comet state get <name> language 读取到的 Comet 配置产物语言输出docs/superpowers/specs/ 下的技术设计文档）openspec/changes/<name>/tasks.md（任务边界）计划要求：
docs/superpowers/plans/YYYY-MM-DD-<feature>.md---
change: <openspec-change-name>
design-doc: docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
base-ref: <git rev-parse HEAD before implementation>
---
base-ref 用于验证阶段跨提交统计改动规模。创建计划时先记录当前提交：
git rev-parse HEAD
将计划写入文件后，返回文件路径。
执行 subagent：使用当前平台的 subagent 调度机制派发上述任务。
Subagent 完成后：
writing-plans 技能创建计划（降级回退）先记录 plan 路径：
comet state set <name> plan docs/superpowers/plans/YYYY-MM-DD-feature.md
无需手动更新 phase，阶段守卫（guard --apply）会在退出条件满足后推进 phase 字段。
展示联合决策前先检查当前平台能力：确认 using-git-worktrees 是否可用、是否存在真实后台 subagent/Task/multi-agent 调度能力，以及当前仓库能否安全创建分支。只展示当前真实可执行的隔离与执行选项；某个字段只剩一个合法值时说明原因并直接采用，不为单选项制造额外停顿。
计划写入后只提供一个联合决策点，一次收集：是否现在继续、可用的工作区隔离、可用的执行方式、TDD 模式和代码审查模式。选择 branch 时，分支名也必须在 Step 2 的同一个联合决策中确认或由用户覆盖。不得先询问“继续/暂停”，继续后又创建第二个配置或命名阻塞点。
| 选项 | 行为 | 说明 |
|---|---|---|
| A | 继续执行并提交配置 | 在同一次回复中选择 Step 3 的隔离、执行、TDD 和审查配置；如选择 branch，同时提交分支名 |
| B | 暂停切换模型 | 记录 build_pause: plan-ready，本次 /comet-build 停止，用户稍后可从 /comet-classic 或 /comet-build 恢复 |
这是用户决策点。必须按 comet/reference/decision-point.md 的协议一次性展示计划摘要、暂停选项和 Step 3 全部可执行配置。用户选择继续时，必须在同一回复中给出所有配置以及条件性的分支名；不得自动选择，也不得把暂停写入 build_mode。
用户选择继续并给出完整配置时：
comet state set <name> build_pause null
用户选择暂停时：
comet state set <name> build_pause plan-ready
设置 build_pause: plan-ready 后，当前调用停止。不要选择 isolation 或 build_mode，不要加载执行技能。
如果恢复时检测到 build_pause: plan-ready 且 plan 文件存在，不要重新运行 writing-plans。重新发起 Step 2 的同一个联合决策；只有用户同时给出完整配置后才清除暂停：
comet state set <name> build_pause null
然后应用本步骤中的工作区隔离、执行方式、TDD 模式和代码审查模式。
计划已写入当前分支。以下配置必须由 Step 2 的联合决策一次性确认：
工作区隔离：
| 选项 | 方式 | 说明 |
|---|---|---|
| A | 当前分支直接工作 | 不创建新分支，如实绑定当前 Git 分支 |
| B | 创建分支 | 在当前仓库创建新分支，简单快速 |
| C | 创建 Worktree | 隔离工作区，完全独立，适合并行开发 |
推荐规则：
执行方式：
| 选项 | 技能 | 适用场景 |
|---|---|---|
| A | Superpowers subagent-driven-development | 任务独立、复杂度高；每个任务在隔离的 implementer subagent 中执行，审查由 review_mode 驱动 |
| B | Superpowers executing-plans | 任务简单、无子agent环境、轻量快速 |
执行方式推荐规则：
这些表格是 Step 2 联合决策的一部分，不再单独暂停。先移除能力预检判定为不可执行的选项；在剩余多个合法选项时，不得根据推荐规则自行选择 current、branch 或 worktree，也不得自行选择执行方式、TDD 模式或代码审查模式。推荐规则只能用于说明建议，不能替代用户确认。
用户选择后，更新 isolation、执行方式、TDD 模式和代码审查模式相关字段：
comet state set <name> isolation <current|branch|worktree>
executing-plans：运行 comet state set <name> subagent_dispatch null，再运行 comet state set <name> build_mode executing-planssubagent-driven-development：先确认当前平台存在可调用的真实后台 subagent / Task / multi-agent 调度能力；确认后先运行 comet state set <name> subagent_dispatch confirmed，再运行 comet state set <name> build_mode subagent-driven-developmentbuild_mode: subagent-driven-development。恢复状态若已记录该模式但能力不可用，回到 Step 2 的同一个联合决策并只展示可执行模式；不得另设“改选 executing-plans”停顿点TDD 模式：
| 选项 | 含义 | 适用场景 |
|---|---|---|
tdd | 每个任务先写失败测试再写实现 | 推荐。变更涉及业务逻辑、新功能、API |
direct | 实现优先，不强制逐任务 Red-Green-Refactor | 仍需运行相关测试并为 bug 修复保留回归证据；hotfix/tweak 预设默认使用 direct |
运行 comet state set <name> tdd_mode <tdd|direct>
代码审查模式：
| 选项 | 含义 | 适用场景 |
|---|---|---|
off | 不自动派发代码审查 | 文档、配置、文案、小范围低风险任务 |
standard | 默认不为每任务派发 reviewer，仅当任务命中风险信号时派发每任务 reviewer，外加一次最终轻量代码审查 | 默认推荐，适合大多数普通改动 |
thorough | 为每个任务派发每任务 reviewer（spec + quality），外加一次最终完整审查 | 高风险、多模块、架构或安全相关改动 |
运行 comet state set <name> review_mode <off|standard|thorough>
isolation 是脚本级硬约束。full workflow 初始化时可以为 null，但只允许存在到本步骤之前。若保持 null，build → verify 的 guard 和 comet state transition build-complete 都会失败。full workflow 允许 current、branch 或 worktree，但 current 必须通过用户在 Step 2 显式选择后写入，不得静默默认。
subagent_dispatch 是脚本级硬约束。build_mode: subagent-driven-development 离开 build 阶段前必须同时满足 subagent_dispatch: confirmed，否则 comet guard build --apply 和 comet state transition build-complete 都会失败。
tdd_mode 是脚本级硬约束。full workflow 离开 build 阶段前 tdd_mode 必须已选择为 tdd 或 direct，否则 comet guard build --apply 和 comet state transition build-complete 都会失败。
review_mode 是脚本级硬约束。新建 full workflow 离开 build 阶段前 review_mode 必须已选择为 off、standard 或 thorough，否则 comet guard build --apply 和 comet state transition build-complete 都会失败。旧状态文件若没有该字段，按兼容路径继续，但恢复时应补写该字段。
build_mode 默认仅 hotfix/tweak 预设使用 direct。full workflow 不得默认使用 direct。只有用户明确要求跳过计划执行技能，且你已记录显式 override 时，才允许：
comet state set <name> direct_override true
comet state set <name> build_mode direct
没有 direct_override: true 时，full workflow 的 build_mode=direct 会被 guard 和状态转换同时拦截。
执行隔离：
current：不创建新分支或 worktree，直接在当前 Git 分支执行。立即运行 comet state set <name> isolation current；该命令会把当前分支写入 bound_branch。如果当前是 detached HEAD，必须停止并让用户先切回真实分支，因为没有可审计的绑定分支。
branch：使用 Step 2 已确认的分支名，不得再次暂停。若旧状态恢复时缺少该次联合决策中的分支名，重新进入 Step 2 的同一个联合决策；不得创建第二个独立分支命名决策点。
分支命名规范：
.comet.yaml 的 workflow 字段确定前缀workflow: full → 推荐 feature/YYYYMMDD/<change-name>workflow: hotfix → 推荐 hotfix/YYYYMMDD/<change-name>workflow: tweak → 推荐 tweak/YYYYMMDD/<change-name>YYYYMMDD，不得依赖某一种 shell 的日期命令示例：如果 change 名称为 fix-login-bug，今天是 2026-06-09，则推荐 feature/20260609/fix-login-bug
分支名由 Step 2 确认后，立即执行 git checkout -b <branch-name>，然后运行 comet state set <name> isolation branch，把新分支写入 bound_branch。后续工作在新分支上进行。
worktree：必须使用 Skill 工具加载 Superpowers using-git-worktrees 技能创建隔离工作区。禁止用普通 shell 命令或原生工具绕过该技能；如该技能不可用，停止流程并提示安装或启用 Superpowers 技能。
创建隔离后，确认计划文件可访问（分支方式天然可访问；worktree 方式需确认计划已提交）。若 worktree 模式下计划文件尚未提交，先提交计划文件再创建 worktree：
git add docs/superpowers/plans/YYYY-MM-DD-feature.md
git commit -m "chore: add implementation plan"
进入最终执行分支或 worktree 后，必须在该实际工作区重新绑定当前 change。branch 模式已在切换后通过 isolation branch 绑定；worktree 模式必须在新工作区运行 comet state set <name> isolation worktree，把 worktree 的当前分支写入 bound_branch。新 worktree 不会继承原工作区的本地选择文件，因此还必须选择当前 change：
comet state select <change-name>
重新绑定成功后才能开始源码写入。
执行计划：必须按 build_mode 的真实运行位置处理。
build_mode: executing-plans：立即执行： 使用 Skill 工具加载 Superpowers executing-plans 技能。禁止跳过此步骤。若该技能不可用，停止流程并提示安装或启用对应技能，不要用普通对话替代该步骤。技能加载后，ARGUMENTS 必须包含与 Step 1 相同的 Language 约束：Language: 使用 comet state get <name> language 读取到的 Comet 配置产物语言输出。按计划执行。build_mode: subagent-driven-development：主会话只负责协调，禁止直接编写实现代码。立即执行： 使用 Skill 工具加载 Superpowers subagent-driven-development 技能。技能加载后，读取 comet/reference/subagent-dispatch.md 获取 Comet 专属扩展（真实后台调度、任务隔离、勾选验证、TDD 约束、连续执行、上下文恢复），与技能工作流配合应用。若两者发生冲突，以更具体的 Comet 扩展为准。comet state set <name> build_mode executing-plans，再按对应分支继续。TDD 模式执行约束：
若 tdd_mode: tdd：
build_mode: executing-plans：加载执行技能后、执行第一个任务前，立即执行： 使用 Skill 工具加载 Superpowers test-driven-development 技能一次。禁止跳过此步骤。技能加载后，从第一个未勾选任务开始，对每个任务遵循已加载的 TDD Red-Green-Refactor 循环执行。不得跳过失败测试验证阶段。后续任务不再重新加载该技能，直接遵循已加载流程。若上下文压缩后恢复，重新运行本步骤加载 TDD 技能一次，然后从第一个未勾选任务继续。build_mode: subagent-driven-development：主会话不加载 TDD skill；TDD 约束和证据门槛已在 comet/reference/subagent-dispatch.md 中定义，每个后台 implementer 和修复 agent 必须自行使用 Skill 工具加载 Superpowers test-driven-development 技能，并遵循 Comet 注入的 TDD 硬约束。若 tdd_mode: direct：按正常流程执行，不强制 TDD。
executing-plans review gate：
在 executing-plans 下，主会话直接执行任务（没有隔离的 implementer subagent），因此不存在 subagent-driven-development 那样的每任务 reviewer。代码审查针对已完成的 diff 进行，并按 review_mode 分级：
review_mode: off：不自动代码审查。不加载 requesting-code-review。在验证报告草稿或 tasks.md 中记录跳过原因。review_mode: standard：在所有计划任务完成后、运行 build → verify 阶段守卫前，使用 Skill 工具加载 Superpowers requesting-code-review 技能一次，请求一次轻量代码审查（正确性、安全、边界），范围覆盖整个 change。review_mode: thorough：除最终那次审查外，按任务分段每 3 个任务请求一次分段代码审查（范围限于该段的 diff）。若总任务数 ≤ 3，跳过执行中分段，只做最终审查。每次分段审查用 requesting-code-review 针对该段的提交区间进行。这是 executing-plans 下最接近 subagent-driven-development 每任务审查的等价物，因为它没有隔离的 implementer 可供逐任务审查。要求（适用于 standard 和 thorough）：
requesting-code-review 技能必须在 comet guard <change-name> build --apply 之前加载requesting-code-review 技能不可用且当前为 standard 或 thorough，必须停止并请用户选择：安装/启用后重试，或明确切换为 review_mode: off 并记录原因。用户未明确切换前不得跳过 review gate 或继续 guard执行任务期间，只要运行程序、测试、构建或手动验证时出现崩溃、异常行为、测试失败或构建失败，必须使用 Skill 工具加载 Superpowers systematic-debugging 技能。在完成根因调查前，不得提出或实施源码修复。
具体调查、最小失败测试、修复验证和保持当前 change 验证闭环的要求，按 comet/reference/debug-gate.md 执行。
实施过程中发现初版 spec 不完整时，按变更规模分级处理：
| 规模 | 触发条件 | 做法 |
|---|---|---|
| 小 | 遗漏验收场景、边界条件 | 直接编辑 delta spec + design.md，追加 tasks.md 任务 |
| 中 | 接口变更、新增组件、数据流变化 | 使用当前平台可用的用户输入/确认机制暂停并等待用户确认后，必须使用 Skill 工具加载 Superpowers brainstorming 更新 Design Doc + delta spec |
| 大 | 全新 capability 需求 | 必须使用当前平台可用的用户输入/确认机制暂停并等待用户确认拆分；用户确认后，通过 /comet-open 创建独立 change |
50% 阈值判定：以 tasks.md 初始任务总数为基准，若新增任务数超过该总数的一半，视为超出原计划范围，必须按 comet/reference/decision-point.md 的协议暂停并等待用户决定是否拆分为新 change。
创建独立 change 时必须调用 /comet-open，不得直接调用 /opsx:new。/comet-open 会同时创建 OpenSpec 产物和 .comet.yaml，避免新 change 脱离 Comet 状态机。
用户选择必须包含：
/comet-open 创建独立 change原则：
Build 是最长阶段，可能跨越大量任务。为支持上下文压缩后断点恢复：
review_mode 完成验收后再勾选对应任务并提交。subagent-driven-development 在 off 时不派发每任务 reviewer；standard 下仅当任务命中风险信号时派发；thorough 下每个任务都派发每任务 reviewer。所有模式都必须按任务唯一文本完成定向检查。通过解析 tasks.md 复选框统计剩余任务，无需反复读取与当前任务无关的正文comet/reference/context-recovery.md 执行，phase 参数为 build。comet/reference/dirty-worktree.md 协议处理未提交改动。该协议定义了检查步骤、归因分类和禁令。build 阶段的特殊处理：
isolation 已写为 current、branch 或 worktreebuild_mode 已写为 subagent-driven-development、executing-plans 或带显式 override 的 direct；若为 subagent-driven-development，subagent_dispatch 必须为 confirmedtdd_mode 已写为 tdd 或 directreview_mode 已写为 off、standard 或 thoroughreview_mode 完成"执行计划"章节中 executing-plans review gate 规定的代码审查：standard 或 thorough 下已请求代码审查且 CRITICAL review 发现已修复、非 CRITICAL review 发现已记录接受理由；review_mode: off 下已在持久产物中记录跳过自动代码审查的原因comet guard <change-name> build --apply，全部 PASS 后由守卫推进到 phase: verify（此步骤更新 phase 字段，与 auto_transition 无关）Guard 会运行自动探测到的项目构建检查（检测到时使用 npm run build、Maven 或 Cargo）。构建失败时 guard 会打印失败命令输出，作为排查证据。
若项目没有可自动探测的构建命令，用户或 Agent 必须先自行运行真实构建命令，再单独记录构建证据：
comet state record-check <change-name> build --command "<实际运行的构建命令>" --exit-code 0
--command 只记录命令文本，Comet 绝不会执行该文本。build 与 verify 证据彼此独立，不能互相替代。COMET_SKIP_BUILD=1 仅是旧流程的兼容绕过方式，不是可审计的构建证据。
退出前运行阶段守卫推进 phase（此步骤与 auto_transition 无关）：
comet guard <change-name> build --apply
状态文件自动更新为 phase: verify、verify_result: pending。
按 comet/reference/auto-transition.md 执行。关键命令：
comet state next <change-name>
NEXT: auto → 调用 SKILL 指向的 skill 进入下一阶段NEXT: manual → 不调用下一 skill，按 HINT 交还控制权并结束当前调用；不再创建确认点NEXT: done → 流程已完成，无需继续