/comet again. Comet reads the project-root configuration, enters /comet-native or /comet-classic, and lets that workflow continue from its own disk-backed state. Neither side scans, guesses, or converts changes from the other.
Short path
Type this in your agent platform:.comet/config.yaml, <artifact-root>/comet/, implementation, and verification evidence. Classic rereads the same project configuration, OpenSpec, .comet.yaml, and runtime evidence.
You can also say “continue”
Starting in 0.4.0-beta.4,comet init and comet update merge Comet recovery instructions into AGENTS.md and CLAUDE.md. After context compaction or a cross-session or cross-device continuation, the agent may no longer know that the request belongs to Comet while the user has not invoked /comet again. The agent can run read-only comet resume-probe to decide whether “continue the login refactor” matches an existing change before re-entering the workflow.
The managed instructions apply only to Comet’s recovery probe and preserve existing user-authored rules in the file. The probe parses configuration first and then inspects only one workflow; malformed configuration does not fall back. Set
ambient_resume: false in .comet/config.yaml to disable probing for ordinary requests. This does not affect explicit /comet calls or bypass existing decision points.
See Resume probe.
How Native resumes
This section explains the background mechanics: after you type
/comet continue, how the Native workflow rebuilds the breakpoint from on-disk state internally. You don’t need to run any of the commands here manually./comet-native entry point. The entry point first runs status and show, reads the brief, complete target specifications, canonical specifications, repository implementation, and tests, then decides whether to continue Shape, Build, Verify, or Archive. Uncommitted changes are worksite evidence and do not by themselves block recovery; the model must still preserve unrelated changes.
comet native next advances state after phase conditions are met. It is not the Ambient Resume entry point. With multiple Native changes, an exact user-provided name takes precedence, followed by a valid selection. Otherwise, the probe asks for a choice instead of guessing from the request text.
How Classic resumes
This section is also background mechanics: it explains which files
/comet-classic re-reads internally and the rules it uses to route to the next phase. You only need to type /comet continue — the routing below is handled automatically by Comet./comet-classic can recover because of three mechanisms:
Recovery uses the first matching route, with file state as the source of truth:
With exactly one active Classic change,
/comet-classic selects it automatically. With multiple, it presents a list and asks you to choose.
Natural-language recovery never guesses among multiple active changes. The recovery probe returns ask_user until you name the target.
Resume across devices and platforms
All state is stored in repository files. Both workflows share.comet/config.yaml; Native changes use <artifact-root>/comet/ and comet-state.yaml, while Classic changes use .comet.yaml, OpenSpec, and docs/superpowers/. Open the same repository on another device or agent platform and /comet can recover from the corresponding files.
Uncommitted worktree changes do not travel with
git push. Commit and push before
switching devices, or the new device will recover from a clean worktree. Checked tasks in
tasks.md still persist when committed.Zero-context recovery across devices
The following image shows a real cross-device, zero-context recovery. As long as the repository is the same,/comet reconstructs the checkpoint from file state and continues without additional context transfer:
After context compression
If the agent platform compresses earlier conversation for a Classic change, enter/comet again. Project configuration selects Classic again, and the internal /comet-classic entry reloads state through the context-compression recovery protocol. It reads brainstorm-summary.md, the handoff package, and .comet/subagent-progress.md when needed. You do not manage these files manually.
Resume from a specific phase entry point
Normal Classic recovery uses/comet. Phase and preset entry points are for manual control or debugging: /comet-open, /comet-design, /comet-build, /comet-verify, /comet-archive, /comet-hotfix, and /comet-tweak.
This is a deterministic guarantee of the progressive loading introduced in 0.4.0-beta.1. Every Classic sub-Skill first uses comet/reference/scripts.md to locate scripts, then runs its own entry or recovery check instead of inferring a phase from conversation history.
- If the check finds that the actual phase, workflow, or evidence belongs to another Skill, follow the script output and
/comet-classicrouting rules. Do not keep writing state from the wrong phase. - If the worktree has uncommitted changes, attribute them using the rules in
comet/reference/dirty-worktree.mdfirst.
Special cases when resuming Build
Classic Build has the most complex recovery cases, but/comet-classic handles most of them automatically:
In
build_mode: subagent-driven-development, the main session does not execute tasks directly after recovery. It returns to the background-subagent dispatch protocol and acts only as coordinator.
When the worktree has uncommitted changes
Comet attributes uncommitted changes automatically; you do not need to explain them in advance:- Changes belonging to the current change are folded in and work continues.
- Unrelated changes pause the workflow and ask whether to include them, create another change, preserve them separately, or discard them.
- If origin is uncertain, Comet pauses and reports the file list and reasoning.
node_modules/ and dist/ are excluded and are not treated as user changes.
When you must intervene
/comet-classic automatically handles unambiguous transitions, but decision points require an explicit user choice. Common recovery cases include:
- Verification failed (
verify_result: fail): choose whether to repair or accept the deviation. - A genuine plan-ready pause: choose isolation and execution mode.
- Missing Build decisions: choose
isolation,build_mode, ortdd_mode. - Unattributable uncommitted changes: explain where the changes belong.
- Multiple active changes: select the target to recover.
- Other phase-specific pauses described in Five-phase decision points.
/comet-classic continues on its own.
When to use comet status or comet doctor
These are diagnostic tools, not mandatory recovery steps:runtime_eval reports whether declared step evidence actually exists on disk. On failure, it prompts you to run <command> or restore missing evidence.
Next steps
- Resume probe — Understand the read-only check before natural-language recovery
- Broken state and recovery — Troubleshoot incorrect routing or damaged state
- Project file structure — See where workflow state is stored
- Automatic progression — Understand transitions after recovery
- Five-phase decision points — See where user input is required