build Phase

The build stage first creates an implementation plan. You then select execution, TDD, and review modes. The workflow implements and checks each task, records spec updates, and captures debugging results.

Under normal circumstances, you only need /comet. After selecting Classic for configuration, the internal /comet-classic will read the status and automatically call after the design is completed / Comet-build . This article describes the internal stage Skill. Only thinking manually controls Direct input is only required for manual control. See How this phase is triggered.

How is this stage triggered

/comet-build is commonly connected automatically by /comet-classic.

Default: Use /comet for automatic connection

After exiting the design phase (phase: build), /comet-classic will automatically connect and call /comet-build. The next time /comet-classic is called, if phase: build is detected or there is a Design Doc but the execution is not completed, it will also be routed to build — hotfix to run /comet-hotfix, tweak to run /comet-tweak, and full to run /comet-build. For details, please refer to Automatic Propulsion Mechanism

Manual: When is direct /comet-build needed

When the auto-connection (auto_transition: false) is turned off, /comet-classic will stop and print hints after the design is completed.
I just want to run build alone (restore a change of phase: build to continue execution).
After the verify failure, if you roll back through comet-state transition verify-fail, you need to re-enter the build to fix it.

Use the unified entry /comet normally; The stage command is directly invoked only during the manual control stage. **

What will you experience

There are 2 pause points in the build phase (globally numbered 6-7, with a total of 10 in the entire five-stage workflow. See Five-stage pause Points and User Selection points ). The following is an explanation in the order of occurrence.

Little Fish advances the plan card to task-by-task execution, debugging, and evidence submission during the build phase.

During the build phase, the plan is broken down into task cards, which are executed one by one, debugged, checked, and the submission evidence is left

Step 0: Entry status verification

node "$COMET_STATE" check <name> build

Read the base-ref and grep in the head of the plan to find the first unfinished task. Idempotence: A submitted task will not be resubmitted.

Step 1: Create an implementation plan

Comet assigns a sub-agent to load the writing-plans write plan (this does not occupy the main session context), and when the sub-agent fails, it falls back to the main session for inline loading. The frontmatter plan must include:

---
change: <change-name>
design-doc: docs/superpowers/specs/...-design.md
base-ref: <git rev-parse HEAD> # The commit and verify before implementation are used to calculate the scale of the change
---

Pause point 6: Build joint decision (plan-ready)

After the plan is written, Comet ** Pause for your choice ** :

Options	”Behavior”
A continues execution	Stay in the current model and enter Step 3 to select execution, TDD and review modes
B Pause the model switching	Record `build_pause: plan-ready`. This time, `/comet-build` stops. After changing the model, you can restore it normally with `/comet`, or you can manually call `/comet-build`

The purpose of option B is to change the model to For instance, use one model to write the plan and switch to a stronger coding model for execution. When restoring, Comet will detect build_pause: plan-ready and the plan exists, it tells you to stop plan-ready, after you confirm to continue, clear the pause flag. will not regenerate plan Directly enter the work mode selection.

Pause point 7: Select three execution modes at once

After confirming to continue, Comet asks you the three execution options at once (not in three separate questions). Workspace isolation is not among them - it was already determined in the workspace decision (pause point 3) of the open phase: the choice is written to isolation, the current branch of the actual execution directory is recorded as bound_branch, and the build phase only verifies that the current directory and branch match, without silently switching directories. When branch is chosen, the branch name is confirmed in the open phase as well (the hotfix/tweak presets default to hotfix/YYYYMMDD/<name> / tweak/YYYYMMDD/<name>).

1. Execution Mode (build_mode

Options	Explanation	”Recommended
A `subagent-driven-development`	The main session is only coordinated, while the backend sub-proxy is implemented. Each task runs in an isolated implement-sub-agent, and the review is driven by `review_mode`	The number of tasks is ≥ 3, and the complexity is high
B `executing-plans`	Lightweight execution, no need for a sub-agent environment	Task ≤ 2. No cross-module dependencies; From the hotfix path
`direct`	”Direct implementation	Only hotfix/tweak defaults; full requires explicit `direct_override: true`

To select subagent-driven-development, the platform must have genuine backend scheduling capabilities - otherwise Comet will pause to allow you to choose executing-plans. By default, full workflow cannot use direct, unless you explicitly set direct_override: true.

2. TDD Mode (tdd_mode

Options	Explanation
`tdd`	Write failure tests for each task first, Red-Green-Refactor ( Recommended , involving business logic/new features /API)
`direct`	Direct implementation, no mandatory TDD (default for hotfix/tweak)

3. Review Mode (review_mode

Options	Explanation	”Recommended
`off`	No automatic review	Documents, configurations, copywriting, small-scale low-risk
`standard`	By default, no reviewer is dispatched per task; one is only dispatched when a task hits a risk signal. The final comprehensive review happens in the verify phase	Default recommendation , most common changes
`thorough`	A reviewer (spec + quality) is dispatched for every task. The final comprehensive review happens in the verify phase	High risk, multi-module, architecture/security

For details, please refer to Code Review Mechanism

Step 3: Execute task by task

After selection, press build_mode to execute. The experiences of the two execution methods are different:

“Dimension”	`executing-plans`	`subagent-driven-development`
Who writes the code?	Do it directly in the main session	The main session only coordinates , and the backend sub-agent implementation (prohibiting direct code writing in the main session)
Task advancement	Execute in sequence and check each one individually	For each task, a new sub-agent is assigned. Once it passes the acceptance inspection, the next one is immediately assigned, constantly asking if you want to continue
Review	Intensity adjusts by `review_mode` (standard = no whole-change review inside build; thorough = segmented review every 3 tasks); the final comprehensive review happens in verify	Assign each task reviewer + repair agent according to review_mode (thorough= each task; standard= only risk tasks)
Model selection	The main session is executed directly	Each distribution must explicitly specify the model (the implementer/fixer/reviewer scales separately)
The progress is visible	It can be directly seen in the conversation	Maintain the `.comet/subagent-progress.md` checkpoint

Under the subagent-driven development, after each task is accepted and selected, it will immediately dispatches the next task I won’t stop to summarize or ask you. There are only four situations when the review and repair rounds are exhausted (BLOCKED), when there is a real ambiguity, when the platform has no background scheduling, or when you explicitly want to stop. The review intensity is determined by review_mode Decision (thorough= review for each task; standard= Review only for risk tasks).

The sub-agent (implementer) cannot select the task by itself — Only the main session is selected after the two-phase acceptance is passed. The reviewer received the complete task plus its implementation commit/diff + RED/GREEN evidence (in TDD) One cannot draw a conclusion based solely on the summary of the implementer.

Step 3b: Abnormal Debugging Protocol (Mandatory)

When a crash, test failure, build failure or abnormal behavior occurs during execution, Comet forces the loading of systematic-debugging:

** First identify the root cause ** - Read the complete error, check the recent changes, and trace the data stream. No fixes shall be proposed until the root cause investigation is completed. **
When the root cause is a bug in the source code, first add a minimum failure test to reproduce it, and then fix the source code.
After completing the run failure test, related tests, and project build/verification command confirmation, all passed.
Failed tests, source code fixes, and the tasks.md checkmark are all kept within the current change. Do not open a new “Write Test Cases “change to replace the current verification loop.

Parallel troubleshooting of multiple failures

Before entering the four-stage process, conduct a “failure independence assessment” first to determine whether it is serial or parallel:

“Situation	”Processing”
Serial (following `systematic-debugging`)	Failure ≤ 2; Failure-related (fixing one might fix another); Shared status It will move the same batch of documents. Independence has not been established.
”Parallelism” (Loading Superpowers `dispatching-parallel-agents`)	≥ 3 failures from different problem domains (different test files, different root causes, independent damage of different subsystems)

When the parallel condition is met:

Load Superpowers dispatching-parallel-agents using the Skill tool.
For each independent failure, assign a background troubleshooting agent (grouped by problem domain and all dispatched in the same response for concurrent execution). Each prompt contains the complete context (specific failure, error message, allowed troubleshooting scope, and prohibition of touching other problem domain code).
All agents are still subject to the constraint that “the source code cannot be modified before the root cause is located” - they only ** locate the root cause and return the discovery **, and do not directly submit the fix.
After all the troubleshooting returns, the main session ** serially ** summarizes the discovery and fixes. The repair still follows the current verification and review cycle of review_mode.

parallelism is only used for troubleshooting, not for repair. The fix is always serial, avoiding multiple agents Simultaneously modifying the same batch of files conflicts - this is related to subagent-driven development The red line for “Do not distribute multiple implementation sub-agents in parallel” is consistent. Even if review_mode: off This is also an abnormal debugging protocol does not skip — off Only skip code review, not the debugging of real problems.

Step 4: spec Incremental update

When it is found during execution that the spec needs to be modified, handle it according to the scale:

Scale	Trigger condition	”Method”
small	Omitted acceptance scenarios and boundary conditions	Directly edit delta spec + design.md and append tasks
In the	Interface changes, new components added, and changes in data flow	Pause for your confirmation , load `brainstorming` to update Design Doc + delta spec
big	”Brand-new capability	Pause for your confirmation of the split , create a new change through `/comet-open` (`/opsx:new` cannot be used)
Over 50%	The number of newly added tasks exceeds half of the total number of initial tasks	Pause point 7: Split into a new change/Continue to complete within the current change

Step 5: Check + Submit

For each task: Execute by build_mode → Review by review_mode (if applicable) → ** Main session ** check tasks.md → Submit. Check “Use directional Verification”

node "$COMET_STATE" task-checkoff "$PLAN_FILE" "$PLAN_TASK_TEXT"

The task text must appear uniquely and be checked. If verification fails, you cannot proceed to the next task. You can use grep -c '\- \[ \]' tasks.md to check the remaining unselected numbers.

Exit

node "$COMET_GUARD" <change-name> build --apply

Advance to phase: verify, and set verify_result: pending.

The invoked skill

Skill	Purpose	When to call
`writing-plans`	Generate an implementation plan	Step 1, sub-agent execution, failure and fallback to the main session
`executing-plans`	Lightweight execution plan	Step 3，`build_mode: executing-plans`
`subagent-driven-development`	Sub-agent-driven execution	Step 3，`build_mode: subagent-driven-development`
`test-driven-development`	Forced TDD	Step 3, `tdd_mode: tdd`
`requesting-code-review`	Code review access control	Step 3, `review_mode: standard`/`thorough` (executing-plans zoom in review_mode; subagent mode zoom in reviewers per task/risk)
`systematic-debugging`	Abnormal debugging	Step 3b: Forced loading when crash/test fails/build fails
`dispatching-parallel-agents`	Parallel troubleshooting of multiple failures	Step 3b: Load when ≥ 3 independent failures (Troubleshoot only, fix serial)
`brainstorming`	Medium-scale spec update	Step 4, when discovering changes in interfaces/components/data flows

Product

Product	Location	Explanation
Implementation plan	`docs/superpowers/plans/YYYY-MM-DD-<feature>.md`	Containing `change`/`design-doc`/`base-ref` frontmatter
subagent-progress.md	`.comet/subagent-progress.md`	Sub-agent scheduling checkpoint (subagent mode only)
Check the tasks.md box	`tasks.md`	`- [ ]` → `- [x]`
Code modification	Repository code	Submit to the isolated branch /worktree

Exit condition (phase guard check)

Check all of tasks.md
The code has been submitted.
Explicitly run the project build/test command and pass (do not rely solely on guard’s automatic guessing)
isolation is current, branch or worktree, and the current Git branch is consistent with bound_branch
build_mode selected (for subagent mode, subagent_dispatch: confirmed is required)
tdd_mode has been selected
review_mode selected (for thorough, segmented reviews have been completed every 3 tasks and CRITICAL/IMPORTANT issues fixed, or non-CRITICAL acceptance reasons recorded; for standard/off, the corresponding reasons have been recorded)

guard will automatically detect the project build entry (such as npm run build, Maven or Cargo) and take the failed output as evidence. .comet.yaml and the repository root configuration no longer support build_command / verify_command; when you need a fixed team-level verification process, put it in the project’s own build script.

”Restore

Build is idempotent. When resuming, grep -n '\- \[ \]' tasks.md | head -1 finds the first unfinished task. For build_pause: plan-ready, see Pause point 6. After context compression, run comet-state check <name> build --recover to restore context. In subagent mode, reread .comet/subagent-progress.md to recover the current task and review round; do not execute tasks directly in the main session. If a full workflow stops at plan-ready, first confirm the existing workspace binding, then complete or confirm build_mode, tdd_mode, and review_mode.

Recommended path

For multi-person collaboration or high-risk changes, worktree + review_mode: thorough is preferred . For minor explicit changes, use branch + standard.

Next step

verify stage - Enter verification after the build is completed
Detailed Explanation of the Code Review Mechanism ](/en/concepts/review-mode) - review_mode
State management — build_mode/isolation/tdd_mode field
Five-stage pause points and user selection points ](/en/concepts/decision-points) - the pause points of build

Understand Comet Classic

Five-phase workflow

Presets

Recovery and troubleshooting

Practical scenarios

How is this stage triggered

Default: Use /comet for automatic connection

Manual: When is direct /comet-build needed

What will you experience

Step 0: Entry status verification

Step 1: Create an implementation plan

Pause point 6: Build joint decision (plan-ready)

Pause point 7: Select three execution modes at once

1. Execution Mode (build_mode

2. TDD Mode (tdd_mode

3. Review Mode (review_mode

Step 3: Execute task by task

Step 3b: Abnormal Debugging Protocol (Mandatory)

Parallel troubleshooting of multiple failures

Step 4: spec Incremental update

Step 5: Check + Submit

Exit

The invoked skill

Product

Exit condition (phase guard check)

”Restore

Recommended path

Next step

​How is this stage triggered

​Default: Use /comet for automatic connection

​Manual: When is direct /comet-build needed

​What will you experience

​Step 0: Entry status verification

​Step 1: Create an implementation plan

​Pause point 6: Build joint decision (plan-ready)

​Pause point 7: Select three execution modes at once

​1. Execution Mode (build_mode

​2. TDD Mode (tdd_mode

​3. Review Mode (review_mode

​Step 3: Execute task by task

​Step 3b: Abnormal Debugging Protocol (Mandatory)

​Parallel troubleshooting of multiple failures

​Step 4: spec Incremental update

​Step 5: Check + Submit

​Exit

​The invoked skill

​Product

​Exit condition (phase guard check)

​”Restore

​Recommended path

​Next step

How is this stage triggered

Default: Use /comet for automatic connection

Manual: When is direct /comet-build needed

What will you experience

Step 0: Entry status verification

Step 1: Create an implementation plan

Pause point 6: Build joint decision (plan-ready)

Pause point 7: Select three execution modes at once

1. Execution Mode (build_mode

2. TDD Mode (tdd_mode

3. Review Mode (review_mode

Step 3: Execute task by task

Step 3b: Abnormal Debugging Protocol (Mandatory)

Parallel troubleshooting of multiple failures

Step 4: spec Incremental update

Step 5: Check + Submit

Exit

The invoked skill

Product

Exit condition (phase guard check)

”Restore

Recommended path

Next step