done-0/unitor/task-routing

Task Routing Skill

Internal guidance for understanding how Unitor routes tasks.

Routing vs Collaboration Decision

Before routing, check if task needs collaboration:

Use /unitor:collab instead of routing when:

• Task spans multiple domains (frontend + backend, API + database)
• Task needs multiple perspectives (review, critique, discussion)
• User uses collaboration keywords: negotiate, discuss, multiple angles, review from multiple perspectives
• Task benefits from specialist discussion

Use /unitor:route for:

• Single-domain focused tasks (frontend-only, backend-only, database-only)
• Clear technical scope without need for multiple viewpoints

How Routing Works

Coordinator-Driven Decision System

The Unitor routing uses a coordinator-driven approach:

1. Coordinator sees provider capabilities: Each provider has tags defining their expertise

• Frontend: frontend-ui, react, vue, css, html
• Backend: backend-api, database, python, go, nodejs
• Architecture: architecture, security, complex-reasoning

1. Coordinator analyzes task: Understand what the task needs based on provider tags

1. Coordinator decides provider: Choose the best match based on provider capabilities

1. Execute with decision: Pass explicit provider to runtime or execute directly

Provider Configuration

Each provider has:

• Tags: Expertise areas with weights (0.0-1.0)
• Priority: Tiebreaker value (1-10)
• Model: Specific model to use
• Enabled: Whether provider is active

Configuration is dynamic and user-customizable.

When to Route vs Execute Directly

Route to Runtime

When task is:

• Focused and delegatable
• Has clear domain indicators (frontend, backend, database)
• Not security-critical
• Not requiring deep architectural reasoning

Execute Directly (Don't Route)

When task is:

• Architecture or system design
• Security-critical (auth, encryption, tokens)
• Complex debugging requiring deep reasoning
• Multi-system refactoring

Fallback Strategy

The runtime handles fallback automatically:

1. If selected provider fails → Retry 3 times
2. If still failing → Fallback to Claude
3. Claude executes the task

You don't need to manage fallback logic.

Example Routing Decisions

// 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

Understanding Provider Selection

The runtime selects providers based on:

• Current configuration: User can add/remove/configure any provider
• Tag weights: Each provider's expertise areas
• Priority: Tiebreaker when scores are close
• Enabled status: Disabled providers are skipped

Important: Provider selection is dynamic and adapts to user configuration. Don't assume fixed assignments.

Your Role

As Claude, you should:

1. See provider capabilities: Check provider tags via status command
2. Analyze and decide: Choose the best provider based on task needs
3. Execute with decision: Pass --provider parameter or execute directly
4. Present results: When other providers execute successfully

You are responsible for:

• Understanding provider capabilities (tags)
• Analyzing task requirements
• Making routing decisions
• Passing decisions to runtime

The runtime handles:

• Provider execution
• Retries and timeouts
• Fallback to Claude if provider fails