// Internal guidance for understanding how Unitor routes tasks. Covers coordinator-driven routing decisions, provider selection logic, and when to route vs execute directly vs use collaboration.
Automatically route tasks to optimal AI providers without user intervention. Use proactively when: user requests focused single-domain work, task clearly matches a provider's specialty, or task is delegatable and doesn't require deep architectural reasoning. Watch for collaboration signals (negotiate, discuss, multiple perspectives, review, critique) - those need /unitor:collab instead.
Multi-AI collaboration for tasks requiring multiple perspectives, discussion, or negotiation. Use when: user explicitly requests collaboration (negotiate, discuss, multiple angles, review from different perspectives, get feedback from multiple experts), task benefits from diverse viewpoints (review, critique, evaluation, brainstorming), or task needs specialist discussion. Examples: 'review this from multiple angles', 'negotiate and handle this issue', 'get different perspectives on this', 'discuss pros and cons of this approach'.
| name | task-routing |
| description | Internal guidance for understanding how Unitor routes tasks. Covers coordinator-driven routing decisions, provider selection logic, and when to route vs execute directly vs use collaboration. |
| user-invocable | false |
Internal guidance for understanding how Unitor routes tasks.
Before routing, check if task needs collaboration:
Use /unitor:collab instead of routing when:
Use /unitor:route for:
The Unitor routing uses a coordinator-driven approach:
Coordinator sees provider capabilities: Each provider has tags defining their expertise
frontend-ui, react, vue, css, htmlbackend-api, database, python, go, nodejsarchitecture, security, complex-reasoningCoordinator analyzes task: Understand what the task needs based on provider tags
Coordinator decides provider: Choose the best match based on provider capabilities
Execute with decision: Pass explicit provider to runtime or execute directly
Each provider has:
Configuration is dynamic and user-customizable.
When task is:
When task is:
The runtime handles fallback automatically:
You don't need to manage fallback logic.
// Example 1: Specialized task
"Fix the styling issue"
→ Coordinator sees Provider B has relevant expertise
→ Coordinator decides: route to Provider B
→ Executes: route --provider=provider-b "Fix the styling issue"
// Example 2: Different specialty
"Add the endpoint"
→ Coordinator sees Provider C has relevant expertise
→ Coordinator decides: route to Provider C
→ Executes: route --provider=provider-c "Add the endpoint"
// Example 3: Complex reasoning task
"Refactor the system architecture"
→ Coordinator sees this requires complex reasoning
→ Coordinator decides: execute directly
→ Claude handles the task
The runtime selects providers based on:
Important: Provider selection is dynamic and adapts to user configuration. Don't assume fixed assignments.
As Claude, you should:
You are responsible for:
The runtime handles: