# Task Routing

> Skill for the orchestrator agent. Decision rules for assigning tasks to the correct specialist agent type. Consult before every subagent dispatch. Load at startup.

- Skill: `las-pinter/task-routing` (Agent Skill)
- Install (CLI): `npx skillmds@latest add las-pinter/task-routing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/las-pinter/task-routing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: las-pinter (https://skillmd.com/u/las-pinter)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/las-pinter/task-routing

---


# Task Routing

## Routing Decision Tree

Evaluate in sequence. Stop at the first YES.

```
Q1: Does the user explicitly name an agent type?
    ("review this", "find info about X", "test this", "plan this")
  → YES: Route to that type. User intent is definitive.
  → NO:  Proceed.

Q2: Does the task require finding or synthesizing information
    not in your context? (Includes: exploring code, locating files,
    understanding unfamiliar systems, reviewing dependencies.)
  → YES: Route to RESEARCHER
  → NO:  Proceed.

Q3: Does the task require evaluating existing work against
    quality, correctness, or standards?
  → YES: Route to REVIEWER
  → NO:  Proceed.

Q4: Is the task ambiguous, large, or does it need decomposition
    before execution? (Includes architectural decisions.)
  → YES: Route to PLANNER
  → NO:  Proceed.

Q5: Is the task for entertainment, morale, or creative breakthrough?
  → YES: Route to MASCOT
  → NO:  Proceed.

Q6: Does the task require writing or modifying code
    based on clear specifications?
  → YES: Route to IMPLEMENTER
  → NO:  Proceed.

Q7: Does the task require verifying behavior, writing tests,
    or hunting edge cases?
  → YES: Route to TESTER
  → NO:  Handle directly (see table below).
```

### Priority Summary

| Priority | Agent | Trigger |
|----------|-------|---------|
| 1 | User-named type | Explicit agent request |
| 2 | Researcher | Information needed outside context |
| 3 | Reviewer | Evaluation against standards |
| 4 | Planner | Ambiguity, scale, architectural decisions |
| 5 | Mascot | Entertainment / creative breakthrough |
| 6 | Implementer | Code with clear specs |
| 7 | Tester | Behavior verification / test writing |

---

## Tiebreaker Rules

1. **Explicit user signal overrides all** — profession-specific verbs ("review", "test", "find", "plan") are definitive.
2. **Specificity wins** — the rule with the most conceptual overlap takes priority.
3. **Pipeline order breaks remaining ties** — Researcher > Reviewer > Planner > Implementer > Tester > Mascot.
4. **If still tied** — the task is multi-type. Decompose and dispatch each subtask separately.

---

## Multi-Agent Orchestration Patterns

### Pattern 1: Research → Implement
When: Task requires learning then building.
```
Researcher → Implementer → Reviewer
```

### Pattern 2: Locate → Implement → Verify
When: Modifying unfamiliar code.
```
Researcher → Implementer → Tester
```

### Pattern 3: Plan → Build → Test
When: Large feature with no clear path.
```
Planner → Implementer → Tester → Reviewer
```

### Pattern 4: Parallel Independent Subtasks
When: Multiple unrelated subtasks in one request.
```
[Parallel] Subtask A → appropriate agent
           Subtask B → appropriate agent
[Synthesis] Orchestrator combines results
```

### Pattern 5: Parallel Review + Test
When: Completed code needs quality and behavioral verification simultaneously.
```
[Parallel] Reviewer + Tester
[Synthesis] Orchestrator reconciles findings
```

---

## Route or Handle Directly?

| Task Type | Action |
|-----------|--------|
| Synthesizing subagent outputs | Handle directly |
| Status checks, context lookups | Handle directly |
| Trivial one-line changes | Handle directly |
| Greetings, conversation | Handle directly |
| Journal operations | Handle directly |
| Non-trivial file write or edit | Route to Implementer |
| Research outside current context | Route to Researcher |
| Codebase exploration | Route to Researcher |
| Evaluation of correctness/quality | Route to Reviewer |
| Task decomposition | Route to Planner |
| Testing/verification | Route to Tester |

---

## Routing Examples

**Research-heavy feature:**
"Find the best Go rate-limiting library that supports Redis, then implement middleware for our API."
→ Researcher → Implementer → Reviewer
Why: Research first (not in context), implement second, review third.

**Ambiguous request:**
"We need a notification system."
→ Planner → Implementer → Tester → Reviewer
Why: Completely ambiguous — needs decomposition first.

**Codebase exploration:**
"I want to add a new NPC type to the game."
→ Researcher (locate existing NPC patterns) → Planner (design) → Implementer (build)
Why: Never read source files yourself. The researcher summarizes; you decide based on that.

**Direct handling:**
"What did we work on last session?"
→ Handle directly
Why: Retrievable from your own journals.

---

## Anti-Patterns

- Do not route to **Reviewer** when there is nothing concrete to review yet
- Do not route to **Implementer** for complex architectural decisions — use Planner first
- Do not route to **Researcher** when the information is already in your context
- Do not route to **Tester** before the code exists — Implementer first
- Do not route to **Planner** when the task is already clearly specified — go straight to Implementer
- Do not read source files yourself to "quickly check" something — dispatch a Researcher
- Do not glob and then read matched files — find the map, let the Researcher dig