/comet plus a sentence, Comet has to answer one question: which workflow should this request use? That decision is driven by two things: intent recognition and slot extraction.
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 routing explainable, reviewable, and recoverable instead of a black-box guess./comet 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:
| Problem | What it felt like |
|---|---|
| Not explainable | Users and agents could not tell why a route was selected. |
| Not reviewable | There was no structured record of the signals that drove the decision. |
| Not recoverable | After interruption, the agent had to read the prompt again and guess again. |
Route results
| Route | Meaning | Next Skill | Requires confirmation |
|---|---|---|---|
full | Run the full open -> design -> build -> verify -> archive workflow | comet-open | No |
hotfix | Fix existing behavior quickly, skipping brainstorming | comet-hotfix | No |
tweak | Use the OpenSpec-backed medium-change path | comet-tweak | No |
resume | Resume an active change | Depends on that change’s phase | No |
ask_user | Evidence is insufficient or conflicting | None | Yes |
out_of_scope | The user is asking a question, not starting work | None | Yes |
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:
| Part | Purpose |
|---|---|
utterance | The original user request that triggered /comet. |
intent | High-level intent and confidence. |
slots | Normalized routing slots: action, workflow candidate, risk signals. |
context | Repository-derived context, not text extracted from the request. |
evidence | Source-labeled snippets that support key judgments. |
proposed_route | The agent’s candidate route. The runtime still reviews it. |
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)
| Slot | Routing tendency |
|---|---|
existing_behavior: true | Bug fix -> hotfix |
new_capability: true | New capability -> full |
public_api_change: true | External contract change -> full |
schema_change: true | Structured data change -> full |
cross_module_change: true | Cross-boundary change -> full |
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./comet builds and scores it 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 general entry point. It uses routing context to choose 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.