---
name: route
description: Use when starting any piece of prompt work — drafting, evaluating, generating test data, probing, or judging — before dispatching any agent or choosing any tier. The entry point that classifies the task into a task type, reads the routing table, and dispatches the pinned agent. Triggers on /route, "work on this prompt", "run the evals", "which model should this use", or any prompt task whose tier hasn't been routed yet.
---

# Route — classify, look up, dispatch

The model decision belongs to the routing table in `CLAUDE.md` § The Routing Policy, not to you and not to the user. This skill is the single entry point that applies it.

## Procedure

1. **Classify the task into exactly one task type** from the routing table's rows. Classification is mechanical work — do it inline at the cheapest capable tier, never by dispatching a frontier agent to think about it. When a task spans types (e.g. "draft a prompt and evaluate it"), decompose: each leg routes separately.
2. **Read the row**: task type → tier → executing agent.
3. **Dispatch the named agent.** The agent's own pin enforces the tier — never override the model at dispatch time. Work with no matching row is new: route it provisionally to the standard tier, do the work, and record the missing row as an out-of-scope discovery so the table gains it.
4. **Never route around a failing eval.** If the routed tier's output fails its evals, the answer is the `escalate` skill (evidence-gated promotion), not a quiet re-dispatch on a stronger agent.

## What this skill refuses

- Naming a model. Tiers only; the mapping lives in `.claude/rules/model-tiers.md` and the agents' pins.
- Frontier dispatch for mechanical work (eval runs, data generation, classification) — the routing guardrails in `CLAUDE.md` prohibit it regardless of who asks.
- Skipping the table because the task "obviously" needs the strongest model — that intuition is exactly what the escalation ladder exists to test.