> ## Documentation Index
> Fetch the complete documentation index at: https://docs.comet.rpamis.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Workflow concepts

> Understand how /comet selects Classic Spec mode from project configuration and how Classic connects OpenSpec and Superpowers across five phases.

Normally, users only invoke `/comet`. It reads `.comet/config.yaml` and deterministically enters Native or Classic according to project configuration. When Classic is selected, it forwards internally to the permanent `/comet-classic` entry point, which splits a change into open, design, build, verify, and archive. Native and Classic changes, state, and artifacts remain independent.

Classic connects OpenSpec and Superpowers into a recoverable workflow. `/comet-classic` includes intent recognition and rereads active changes, `.comet.yaml`, and actual file state to decide whether to create, resume, enter a lightweight preset, or invoke the current phase Skill. Users do not need to determine the current phase first.

Classic primarily targets model capability tiers below Fable 5 and GPT-5.6. For these models, explicit Spec, design, planning, TDD, debugging, and review phases reduce omissions and process drift. Comet's existing real-model baseline has shown that these constraints can maintain good task coverage and completion at lower capability tiers. Fable 5, GPT-5.6, and similarly capable models are generally better suited to the lighter-method [Native workflow](/en/concepts/native-workflow). Model names are selection guidance; Comet does not inspect the model and switch modes automatically.

## What matters most

| Concern                | Answer                                                                                         |
| ---------------------- | ---------------------------------------------------------------------------------------------- |
| User entry point       | Use `/comet`; project configuration selects Classic or Native                                  |
| Classic internal entry | `/comet-classic`, responsible for intent recognition, file-state inspection, and phase routing |
| Model fit              | Models below the Fable 5 or GPT-5.6 tier that benefit from finer guidance                      |
| Flow                   | `open` → `design` → `build` → `verify` → `archive`                                             |
| When you participate   | Requirements, design, execution mode, verification failure, and pre-archive confirmation       |
| Recovery sources       | OpenSpec artifacts, `.comet.yaml`, and runtime evidence                                        |
| Advanced details       | Handoff hashes, archive directories, and route decisions are mainly for troubleshooting        |

## Why connect OpenSpec and Superpowers

OpenSpec is strong at change identity: proposals, deltas, tasks, and archive history.

Superpowers is strong at execution depth: brainstorming, design docs, implementation plans, TDD, review, and verification discipline.

Comet keeps both roles explicit:

| Need                          | Owner                         |
| ----------------------------- | ----------------------------- |
| What is changing              | OpenSpec                      |
| How to implement it           | Superpowers                   |
| What phase the workflow is in | Comet state                   |
| Whether artifacts still match | Handoff hash and verification |

## The five phases

| Phase   | Purpose                                     | Typical artifact                  |
| ------- | ------------------------------------------- | --------------------------------- |
| open    | Capture WHAT and create the OpenSpec change | proposal, spec delta, tasks       |
| design  | Explore HOW and create an execution plan    | design doc and plan               |
| build   | Implement against the plan                  | code changes and task evidence    |
| verify  | Run checks and detect drift                 | verification output and decisions |
| archive | Merge the delta into long-term history      | archived spec and state reset     |

## Handoff hash

A handoff hash records the design-to-build contract. It is recalculated from selected artifacts so Comet can detect when the spec, design, or tasks changed underneath the current phase.

## Spec scope

Comet distinguishes the main spec from delta specs. Delta specs describe the current change. Archive promotes accepted deltas into long-term spec history.

## How Classic chooses a phase entry point

After `/comet` forwards to `/comet-classic`, Classic reads project files and classifies the request against current state. It can start a new change, resume the current one, route a status request, enter a lightweight preset, or ask for a decision when the next step is unsafe to infer.

## Lightweight presets

Use [hotfix](/en/presets/hotfix) for narrow urgent fixes and [tweak](/en/presets/tweak) for small low-risk changes. Either preset can upgrade into the full workflow when risk increases.