A catalog of 200 skills is worse than 10 skills if you have to scroll to find the right one. The catalog is hidden behind a router for exactly this reason. The router is what makes a large catalog feel like a small one.
Here is how it actually works.
The decision the router makes
For every inbound message, the router decides one of three things:
- Run a skill. The message clearly matches a skill's purpose and the skill is the right move.
- Run no skill. The message is small talk, an acknowledgement, a continuation. No skill needed.
- Ask the user to disambiguate. The message could plausibly fire two or three skills, and the cost of guessing is higher than the cost of asking.
Most messages fall into the first two buckets. Disambiguation is rare by design. When it fires, it fires with a short, plain-language question.
How the match decision is made
The router runs three filters in series:
- Intent classification. The message is classified into a closed-set of intents: pricing-question, growth-question, content-task, code-task, document-task, advice-request, follow-up, recall, off-topic. The set is intentionally narrow.
- Skill match. Each skill in the catalog declares which intents it serves. The router intersects the classified intent with the catalog and produces a candidate set.
- Cost-class gate. Light skills run automatically. Medium skills run if the user is on a tier that includes them. Heavy and premium skills run only with explicit user opt-in, or when the user is on a tier that pre-authorizes them.
The output is a single skill (most common) or a short list (disambiguation case) or nothing (no-skill case).
Why classification is closed-set
We tried open-set intent classification early on. The skill fired the right thing 70 percent of the time. The other 30 percent fired surprisingly wrong skills. The failure mode was that the classifier "creatively" matched an intent to a skill that was tangentially related but not what the user wanted.
Closed-set classification with a narrow intent vocabulary fixes the failure mode. The cost is occasional underfire (the classifier returns "off-topic" when something more specific would have worked). The benefit is that misfires drop near zero.
How the router explains itself
Every reply that fires a skill includes a small badge: "Pricing Surgeon shaped this answer." You can ask "why?" and the router will say what intent it matched, what skill it picked, and what its second-best match was.
The transparency is not cosmetic. It is the only way users build trust in routing. The first time the router picks the wrong skill, the user needs to know why so they can override.
How you override
Three ways.
- Slash explicitly.
/pricing-surgeonruns the skill directly, no routing. - Tone-down.
/tone-downreduces skill firing across the board (useful when you want to chat without skill-mediated replies). - Skip. When the router asks to disambiguate, you can say "skip" and the message routes to the no-skill path.
The override path is intentionally fast. Users who want manual control should not pay a friction tax for it.
What the router does NOT do
The router does not see your conversation history at the message-routing layer. The classifier looks at the message alone. The skill itself, once it fires, has access to the long-term memory for context (per Trust-3 surface rules). This separation matters: it prevents the classifier from drifting toward a user's most-fired skill regardless of the current message.
The router also does not learn online from your patterns. There is no per-user skill bias. We considered this and rejected it: a learned bias would create a hidden persona on top of the skill catalog, and the user would lose the ability to predict what the bot will do.
What changes when we add a new skill
When a new skill ships into the catalog, three things happen automatically:
- The classifier picks it up at next deploy (the skill declares its served intents in the manifest).
- The catalog page updates.
- The changelog page lists it. The RSS feed fires.
No router-tuning required. The skill is just live. This is why we can ship new skills weekly without a manual integration step per skill.
Where the router currently struggles
Two failure modes we know about and are working on:
- Multi-skill replies. If a single user message has two distinct asks ("audit my pricing and also draft a customer email about it"), the router picks one. The right behavior is to chain two skills. Track ⚡2 ships this.
- Conversational context. If the previous message established context ("we are talking about onboarding flow"), the router does not always carry that forward into the next classification. We have a fix in flight.
We surface these limits because trust is built by saying what you cannot do, not by pretending the system is perfect.
The principle
The router exists so the catalog can grow without the interface getting heavier. Every new skill we add does not require a new menu item, a new docs page, or a new install button. The router absorbs the complexity. The user keeps the same simple interface: send a message.
That is the bet behind Skill OS, in one sentence.