Decision Router

The pattern in one phrase: classify, then dispatch.

1. What it does

Before the agent answers any real question, it figures out *what kind* of question it is and sends it to the right specialist — instead of letting one generalist guess at everything.

2. The problem it solves

When you have a bunch of expert helpers — one for design, one for money, one for architecture, one for code review — you have to remember which one to call every single time. Worse, if you just ask one all-purpose agent everything, it gives you bland, average answers because it's a jack-of-all-trades. It's like walking into a hospital and shouting your symptoms at the first person you see in the lobby. Maybe they help, maybe they're a janitor. You want a front desk that takes one look at you and says "third floor, cardiology" — *before* anyone starts treating you. Without that front desk, the wrong specialist wastes everyone's time, and you never build a record of what was decided and why.

3. The core pattern (the part you steal)

Classify, then dispatch: sort the request before you act on it.

The whole trick is putting a *decision step in front of the work step*. Most setups jump straight to "answer it." This one inserts one quick question first — "what bucket does this fall into?" — and only then hands the request to whoever owns that bucket.

Picture the front desk at a big office building. You walk in, the receptionist asks one question — "who are you here to see?" — reads your answer, and points you to the right floor. The receptionist doesn't fix your problem. They *route* you. That tiny sorting step is what makes a 40-person building usable instead of chaos.

Two things make this pattern powerful, and you can lift both:

Sort first, work second. A cheap "what type is this?" check up front saves you from sending the request to the wrong expert. The classify step is fast and throwaway; the work step is where the real effort goes. Keep them separate.
Have an off-ramp for noise. Not every message is a real decision. "Thanks!" and "looks good" don't need a specialist. The router checks for that *first* and just says "not routable, handle it normally" — so the specialists (and any record you keep) stay focused on the requests that actually matter.

That combo — *a sorting gate plus an escape hatch for trivial stuff* — is the transferable lesson. It works for support tickets, email triage, lead routing, anything where different requests need different owners.

4. How the skill is actually built

Look at the real file: ~/.claude/skills/decision-router/SKILL.md. Its shape:

Frontmatter (the top block): a name and a description that tells the agent to run this *before* handling any real decision, and to *skip* trivial chatter. That "use this first" instruction is the whole point — it's how the router gets to be the front door instead of an afterthought.
The body: a short, numbered flow. In plain English: (0) recall — check if a similar decision was already made, so you don't re-litigate it. (1) classify — what kind of request is this? (2) route — send it to the matching specialist (a single expert for a quick call, a panel for a multi-angle review, or a specific owner for things like voice or architecture). (3) load — pull in the background info that specialist needs to be sharp. (4) decide — answer, following a fixed quality bar (back up claims, actually pick a side, show the option you rejected, name the blind spot, give a confidence level). (5) log — write down what was decided.
The off-ramp: a one-line rule that says if step 1 finds "this isn't a real decision," route it to nobody, do the work normally, and don't log it. That keeps the record clean.
Helper files (by role, not by name): one file explains *how the load step pulls background info* (with a fallback source if the main one is down). One file holds *the quality contract* every specialist must answer to. And one is a generated *lookup table* that maps a topic to the right specialist, so routing isn't a guess. The skill body stays short because these side files carry the details.

5. How YOU could build your own

You don't need the fancy version. Here's the minimum:

List your buckets and their owners. Write down the 4-6 kinds of requests you get and who (or which mode) handles each. "Money questions → the finance brain. Design questions → the design brain." That list IS your router.
Write the sorting question. One line: "Before answering, decide which bucket this falls into." Make the agent say the bucket out loud before it does anything else — that forces the classify step to actually happen.
Add the off-ramp. Tell it: "If this isn't a real decision, just answer normally and skip the routing." This stops it from over-thinking a 'thank you.'
(Optional) Keep a one-line log. After each real decision, jot down what was decided. Later you can check it before deciding again — that's how you stop answering the same question twice.

That's a working router. The recall memory and the lookup table are polish you add once the basics earn their keep.

6. When to use it — and when NOT to

Use it when: you have several specialized helpers or modes and the right one depends on the request, OR you keep answering the same kinds of questions and want them consistently handled by the same expert.
Skip it when: you only have one helper (nothing to route to — the router is pure overhead), or the request is plainly trivial. Routing "what time is it?" through a five-step sorting process is theater. The off-ramp exists exactly so you don't.

7. The stripped-down version

This is a complete, working router skill. Paste it, change the buckets, done:

---
name: router
description: Sort a request to the right helper before answering. Use FIRST on any real decision; skip trivial chatter.
---

# Router

Before you answer anything that's a real decision, do this:

1. CLASSIFY — say which bucket this falls into:
   - money / cost / pricing → finance helper
   - design / UI / branding → design helper
   - architecture / "where does this go" → systems helper
   - needs many viewpoints → convene a panel
   - none of these / just chatter → nobody

2. ROUTE — answer as that helper, with its knowledge loaded.
   If the bucket is "nobody," just answer normally and STOP here.

3. (Real decisions only) LOG one line: what was decided and why.