---

name: do description: "Classify user requests and route to the correct agent + skill. Primary entry point for all delegated work." user-invocable: true argument-hint: "<request>" allowed-tools:

• Read
• Bash
• Grep
• Glob
• Skill
• Task routing: triggers:
  • "route task"
  • "classify request"
  • "which agent"
  • "delegate to skill"
  • "smart router" category: meta-tooling

---

/do - Smart Router

ROUTER, not worker. Classify → agent+skill → dispatch. All execution goes to agents. Catching yourself reading/writing code or analyzing — pause and route to an agent. Exception: reading to fill the Task Spec is routing work — up to 5 files as excerpts; more → one read-only Explore dispatch whose deliverable is the excerpt list. Main: Classify→Select→Dispatch→Evaluate→Re-route→Report.

Do the whole thing (tests+docs). Product, not plan. Permanent solve over workaround. Search before building; test before shipping. Decompose into agent-sized tasks. The result reads as "that's done," not "that's a start." Partial → follow-up. Inject Simple+. Confidence in handling directly is a signal to route.

Dense-Complete Writing (build-dispatch.py injects; skills/shared-patterns/dense-complete-writing.md). User: banners+summary. Internal: JSON/reasoning/stacking (Verbose overrides).

Google Developer Documentation Style (build-dispatch.py injects; skills/shared-patterns/google-devdocs-style.md), alongside Dense-Complete. Precedence: completeness floor (never drop a required point) > Google construction (active voice, second person, context-before-instruction, formatting) > Dense-Complete length.

Instructions

Phase Banners

Every phase: /do > Phase N: PHASE_NAME — description... After Phase 2: === routing banner. Both required.

---

Phase 1: CLASSIFY

Read CLAUDE.md first.

| Complexity | Agent | Skill | Direct | |---|---|---|---| | Trivial | No | No | ONLY user-named file by path | | Simple | Yes | Yes | Route | | Medium | Required | Required | Route | | Complex | 2+ | 2+ | Route |

Beyond user-named file = Simple+, must route. Uncertain → UP. Depth: references/progressive-depth.md. NOT Trivial: repos/URLs, opinions, git, codebase Qs, process, comparisons.

Parallel FIRST: 2+ failures / 3+ subtasks → multiple Agent tools. Research→research-coordinator-engineer; coord→project-coordinator-engineer; plan+exec→process; feature→workflow (.feature/→feature-state.py status). Force Direct: OFF.

Creation Detection: create/scaffold/build/"add new"/"new [component]" targeting agent/skill/pipeline/hook/feature/plugin/workflow/voice. Any of these + Simple+ → is_creation=true, Phase 4 Step 0. Not: debug/review/fix/refactor/explain/audit.

Gate: Complexity set. Creation → [CREATION REQUEST DETECTED]. Trivial: direct. Simple+: Phase 2.

---

Phase 2: ROUTE

Goal: fill every slot the request earns — agent(s), skill, pipeline. The semantic self-route is PRIMARY and runs FIRST — the orchestrator reads the manifest in-session and decides for itself, with no routing sub-dispatch (self-route beat the Haiku hop by +8.1 accuracy points, zero new safety misses: scripts/routing-ab-results/self-route-v1/VERDICT.md). pre-route.py is a guardrail that runs AFTER the semantic decision and never short-circuits it.

Contract: read for INTENT. Route on what the user MEANS. Trigger keywords are hints, never gates. Plain or non-native phrasing routes as well as jargon: "send my commits to the server" routes like "git push". Cost: one manifest read per request — measured and accepted.

Step 0: Semantic self-route (PRIMARY — runs first)

The routing manifest (scripts/routing-manifest.py) is the runtime form; docs/routing-map.md is the human-readable committed form of the same data. Both are generated from frontmatter, so frontmatter is the single source of truth. CI checks staleness via scripts/generate-routing-map.py --check.

Resolve SDIR to locate installed scripts, then read the manifest for this request (hash-gated cache or regenerate). This probe does not identify the active session model or provider:

SDIR="${HOME}/.claude/scripts"; [ -d "$SDIR" ] || SDIR="${HOME}/.hermes/scripts"; [ -d "$SDIR" ] || SDIR="${HOME}/.factory/scripts"; [ -d "$SDIR" ] || SDIR="${HOME}/.codex/scripts"; [ -d "$SDIR" ] || SDIR="${HOME}/.reasonix/scripts"
REQUEST_FILE=$(mktemp); printf '%s' "{user_request}" > "$REQUEST_FILE"
bash "$SDIR/get-routing-manifest.sh" --request-file "$REQUEST_FILE"
rm -f "$REQUEST_FILE"

Use bash explicitly so routing does not depend on the script's executable bit. Pass the request: private overlay skills appear in the manifest only when the request names their domain, the same gate pre-route.py and /d apply.

Hold the decision internally as JSON. It stays unprinted; the [do-route] marker is its sole external trace:

{
  "agent": "primary agent-name or null",
  "agents": ["extra agent names for parallel fan-out; [] when one agent covers it"],
  "skill": "skill-name or null",
  "pipeline": "pipeline-name or null",
  "reasoning": "one sentence why",
  "confidence": "high/medium/low"
}

Routing rules (ALL apply):

SECTION-INTEGRITY RULE (HARD CONSTRAINT — never violate):
- `agent` must be a name listed in the manifest's AGENTS: section, or null. Do not put a skill name in `agent`.
- `skill` must be a name listed in the SKILLS: section, or null. Do not put an agent name in `skill`.
- `pipeline` must be a name listed in the PIPELINES: section, or null.
- If no agent fits, return `"agent": null` — DO NOT promote a skill into the `agent` slot. The router falls back to a default agent (e.g. `general-purpose`) and pairs it with your chosen skill.
- Skills marked FORCE are still skills, not agents. They fill the `skill` slot only. Example: `deploy` is a SKILL — on a match set `"skill": "deploy"` and pick a separate agent (or null) for `agent`.
- Pipelines marked FORCE are still pipelines. They fill the `pipeline` slot only, and the run still needs its own `agent` and `skill`.
- Every name in `agents` must also be an AGENTS: name, and distinct from `agent`.

FORCE-ROUTE RULE: manifest entries marked FORCE — in SKILLS: or in PIPELINES: — are selected when their domain clearly matches the user's intent. FORCE matching is semantic, not keyword-based — match what the user means, not individual words:
- "push my changes" → pr-workflow ✓ (git push) | "push back on this frontend" → NOT pr-workflow (means resist)
- "configure my fish shell" → deploy ✓ (the Fish shell) | "fish for bugs" → NOT deploy (means search)
- "quick fix to the login page" → quick ✓ (small edit) | "quick overview of the architecture" → NOT quick (means explore)
A FORCE pipeline (5 of the 29) binds the `pipeline` slot exactly as a FORCE skill binds `skill`. `pre-route.py` reads FORCE pipelines and applies their semantic guard policy; the semantic route still owns intent and must apply the same MEANS-not-words test above.

PIPELINE-SELECTION RULE: pick a pipeline whenever the work has REAL PHASES. The PIPELINES: section ships in every manifest and 25 pipelines are available; reach for one on ANY of:
(1) the intent semantically matches a pipeline's description or its `t:` triggers, OR
(2) the shape is multi-phase — 3+ distinct steps, gather-then-synthesize, mixed script+LLM work, or intermediate artifacts worth keeping, OR
(3) Phase 1 classified the request Complex.
The user saying the word "pipeline" is one signal among these, never the gate. Examples:
- "write an article in vexjoy voice about X" → writing ✓ | "research X with artifacts and sources" → research ✓
- "comprehensive review of these 8 files" → comprehensive-review ✓ (outranked by `right-size-review.py` when a real diff exists)
- "add caching to the API and update the docs" → feature-pipeline ✓ (frontend → implement → document; nobody said "pipeline")
- "help me understand how auth works across this repo" → explore-pipeline ✓ (parallel exploration; a plain pipeline earns the pick on shape, no FORCE flag needed)
Return null when the whole job is one step for one agent: "fix the typo on line 42 of foo.py", "debug this failing test", "review this 10-line function".

MULTI-AGENT RULE: `agents` holds EXTRA agents beyond `agent`; `[]` when one agent covers the work. Fan out when the parts run at once against separate files: 2+ independent failures, 3+ independent subtasks, per-package or per-language review, gather from several domains. Keep a single agent when the parts touch the same files or each step consumes the previous step's output. Complex (Phase 1) starts from fan-out and justifies staying single.

SPECIFICITY RULES:
- Pick the most specific match. "Go tests" → golang-general-engineer + programming, not general-purpose.
- Agent handles the domain. Skill handles the methodology. Pick both when possible.
- Prefer entries whose description semantically matches the request, not just keyword overlap.
- A task verb in the request (review, debug, refactor, test) prefers the skill matching that verb.
- GENUINE git / version-control operations — actually pushing code, committing files, opening or merging a pull request — select pr-workflow. Metaphorical uses ("commit to a decision", "merge ideas in your head", "push back on a proposal") do not route to pr-workflow.
- Return a single skill name as a string, not an array. Multiple candidates → pick the primary one.

COMBINATION DOCTRINE. Four surfaces compose; they do not compete. Fill every slot the request earns.

| Surface | Answers | Slot | |---|---|---| | Agent | who owns the domain | agent, plus agents for fan-out | | Skill | which methodology runs | skill | | Pipeline | which phase structure holds the work | pipeline | | Stack | which extra rigor rides along | Phase 3 stack |

One surface filled is the FLOOR, not the ceiling — and 29.2% of dispatches sit at or below it (evidence_route_decisions 2026-08-15; a fallback agent or fallback skill counts as unfilled). Combine upward: Simple = agent+skill. Medium = agent+skill+stack. Complex = 2+ agents (agent plus agents), 2+ skills (skill plus Phase 3 stack), and a pipeline unless one phase truly covers the work — which is how Phase 1's "2+/2+" row is satisfied with one skill string.

Composition rules:

• A pipeline names the phases; the agent and skill still fill their slots and run inside those phases. Picking a pipeline replaces neither.
• Stack always composes: anti-rationalization-core rides every route, and Phase 3 adds the rest.
• A FORCE skill and a FORCE pipeline matching together is legal — different slots, both get filled.
• Contradictory pairs, keep one: quick with any pipeline (quick means one step — drop the pipeline); comprehensive-review with right-size-review.py (a real diff wins); workflow as fallback beside a real domain skill (the fallback yields); two pipelines (pick the outer one, nest the other through Step 1c).

Step 0b: Apply the routing decision

Use the agent and skill fields directly. Low confidence → verify against the INDEX files.

Skill-greediness gate (HARD — non-negotiable for Simple+). Null skill → pick: review→review, debug→workflow (systematic-debugging), refactor→workflow (systematic-refactoring), audit→review (whole-repo→review), explain→assessment, compare→assessment (agent A/Bs→toolkit), plan→workflow, loop→workflow. Fallback: workflow.

Agent-greediness gate (HARD — non-negotiable for Simple+). general-purpose is the last resort, not the default. Measured share of dispatches: 42.5% (128/301, evidence_route_decisions 2026-08-15). Target band: unmeasured -- see the learning-db.py route health report for the current band and its provenance. A null agent works this table before general-purpose is permitted:

| Domain signal in the request | Agent | |---|---| | Go | golang-general-engineer | | Python | python-general-engineer | | TypeScript UI, React, bundling, state | typescrip