/comet plus a request. After project configuration selects Classic, the internal /comet-classic entry decides which Classic profile applies using intent recognition, slot extraction, and actual file state.
Intent recognition answers “what do you want to do”: start a new change, fix an existing bug, make a light adjustment, resume an in-progress change, or just ask a question? Slot extraction breaks your utterance and repository state into structured routing signals — action, workflow candidate, risk flags — each labeled with its source, ready for the runtime to score with a fixed priority order.
Starting in 0.4.0, this mechanism (implemented as CometIntentFrame) replaces the natural-language heuristics in Skill text and makes routing explainable, reviewable, and recoverable. In our baseline tests, this also improved Comet’s recovery behavior for interrupted workflows.
Routing context turns the request and repository evidence into a decision the runtime can review.
Why routing context exists
In one sentence: routing context makes
/comet-classic routing
explainable, reviewable, and recoverable instead of a black-box guess./comet-classic relied on prose rules such as “if this is a bug, use hotfix; if this is a copy tweak, use tweak.” That created three problems:
Routing context turns “what the user wants” into structured data with fields, evidence, and confidence. The runtime does not blindly trust the agent’s proposed route. It rescores the context, returns the final route, and writes disagreements into diagnostics.
Route results
Comet asks when it cannot prove a path is safe. It does not force an uncertain request into
full, hotfix, or tweak.
Intent recognition and slot extraction
The two core inputs to the routing decision areintent (intent recognition) and slots (slot extraction), together with supporting fields in CometIntentFrame — the structure the runtime scores to produce a final route:
Intent recognition (intent)
intent has two sub-fields:
name: intent type.start_new_change/fix_bug/make_tweak/resume_change/ask_question/unknownconfidence: a 0-1 score. When confidence falls below 0.7, the runtime routes directly toask_user— it will not gamble on an ambiguous intent.
Slot extraction (slots)
Runtime scoring order
This fixed-priority order is the core of explainable routing. Each step has a clear condition,
and disagreements are written to diagnostics for later review.
- Low confidence ->
ask_user. - Multiple active changes with no target ->
ask_user. - Valid resume target ->
resume. - Question-only request ->
out_of_scope. - Explicit workflow conflicts with risk signals ->
ask_user. - Risk signals ->
full. - Existing bug with evidence ->
hotfix. - Tweak with evidence ->
tweak. - Not enough evidence ->
ask_user.
hotfix but the runtime normalizes to full.
What this means for users
You do not write routing context by hand. Invoke/comet; after configuration selects Classic, /comet-classic builds and scores the context internally. Describe the work clearly, expect Comet to ask when evidence is weak, and use diagnostics to understand why a route was selected.
Advanced users can route a context JSON directly:
Relationship to /comet-tweak
/comet is the normal user entry. /comet-classic is the permanent internal Classic entry point it forwards to when configuration selects Classic; that router chooses full, hotfix, tweak, resume, or a pause.
/comet-tweak is the dedicated OpenSpec action path for medium changes when you already know tweak is the correct workflow.