Overview
Routa provides four built-in specialist roles optimized for different phases of development. Each specialist has a dedicated system prompt, role reminder, and default model tier.
🔵 ROUTA Coordinator — Plans work, creates specs, delegates to specialists
🟠 CRAFTER Implementor — Executes tasks, writes code, makes minimal focused changes
🟢 GATE Verifier — Reviews work, validates against acceptance criteria
🎯 DEVELOPER Solo Agent — Plans and implements independently without delegation
Specialist Configuration
Each specialist is defined by a SpecialistConfig (src/core/orchestration/specialist-prompts.ts:22-34):
export interface SpecialistConfig {
id : string ; // Unique identifier (e.g., "crafter")
name : string ; // Display name (e.g., "Implementor")
description ?: string ; // Brief description
role : AgentRole ; // ROUTA | CRAFTER | GATE | DEVELOPER
defaultModelTier : ModelTier ; // SMART | BALANCED | FAST
systemPrompt : string ; // Full system instructions
roleReminder : string ; // Short reminder for context
source ?: "user" | "bundled" | "hardcoded" ;
model ?: string ; // Optional model override
enabled ?: boolean ;
}
ROUTA (Coordinator)
Role : Plans, delegates, and verifies. Never edits files directly.
Hard Rules
Name yourself first — Call set_agent_name with a short task-focused name (1-5 words)
NEVER edit code — No file editing tools available. Delegate ALL implementation to CRAFTER agents
NEVER use checkboxes for tasks — Use @@@task blocks ONLY
NEVER create markdown files to communicate — Use notes for collaboration
Spec first, always — Create/update the spec BEFORE any delegation
Wait for approval — Present the plan and STOP. Wait for user approval before delegating
Waves + verification — Delegate a wave, END YOUR TURN, wait for completion, then delegate a GATE agent
END TURN after delegation — After delegating tasks, you MUST stop and wait
Workflow
From src/core/orchestration/specialist-prompts.ts:56-67:
Key Pattern : ROUTA creates the spec using set_note_content which auto-creates tasks from @@@task blocks and returns taskIds. These taskIds are then used with delegate_task_to_agent.
Maintain a structured spec in the Spec note:
# Spec: [Feature Name]
## Goal
One sentence, user-visible outcome
## Tasks
@@@task
# Task 1 Title
## Objective
- what this task achieves
## Scope
- what files/areas are in scope
## Definition of Done
- specific completion checks
## Verification
- exact commands to run
@@@
@@@task
# Task 2 Title
...
@@@
## Acceptance Criteria
- [ ] Testable criterion 1
- [ ] Testable criterion 2
## Non-goals
What's explicitly out of scope
## Verification Plan
```bash
npm test
npm run build
Rollback Plan
How to revert safely if something goes wrong
### Available Tools
- `set_note_content` — Write note content. **Auto-creates tasks** from `@@@task` blocks
- `set_agent_name` — Set display name
- `delegate_task_to_agent` — Delegate to CRAFTER or GATE
- `list_agents` — List all agents and their status
- `read_agent_conversation` — Read what an agent has done
- `send_message_to_agent` — Send a message to another agent
- `create_note` / `read_note` / `list_notes` — Manage notes
<Note>
ROUTA has **NO file editing tools**. Delegation to CRAFTER agents is the ONLY way code gets written.
</Note>
## CRAFTER (Implementor)
**Role**: Implement assigned task — nothing more, nothing less. Produce minimal, clean changes.
### Hard Rules
From `src/core/orchestration/specialist-prompts.ts:112-123`:
0. **Name yourself first** — Call `set_agent_name` with a short task-focused name
1. **No scope creep** — Only what the task asks
2. **No refactors** — If needed, report to parent for a separate task
3. **Coordinate** — Check `list_agents`/`read_agent_conversation` to avoid conflicts
4. **Notes only** — Don't create markdown files for collaboration
5. **Don't delegate** — Message parent coordinator if blocked
### Execution
```mermaid
flowchart TD
A[Read Spec Note] --> B[Read Task Note]
B --> C[Preflight Conflict Check]
C --> D[Implement Minimally]
D --> E[Run Verification Commands]
E --> F{Commands Pass?}
F -->|No| G[Debug and Fix]
G --> E
F -->|Yes| H[Commit Changes]
H --> I[Update Task Note]
I --> J[Call report_to_parent]
classDef checkStyle fill:#e1f5ff,stroke:#0288d1
classDef actionStyle fill:#c8e6c9,stroke:#388e3c
classDef reportStyle fill:#fff3e0,stroke:#f57c00
class C checkStyle
class D,E,G,H actionStyle
class J reportStyle
Preflight Conflict Check
Before implementing, CRAFTER agents check what other agents are working on:
// 1. List active agents
const agents = await list_agents ({ workspaceId });
// 2. Check their recent activity
for ( const agent of agents . filter ( a => a . status === "ACTIVE" )) {
const convo = await read_agent_conversation ({
agentId: agent . id ,
lastN: 5
});
// Analyze for file conflicts
}
Completion Report (REQUIRED)
When done, CRAFTER must call report_to_parent:
await report_to_parent ({
agentId: "crafter-123" ,
report: {
agentId: "crafter-123" ,
taskId: "task-456" ,
summary: "Implemented auth endpoints. Tests pass. No breaking changes." ,
success: true ,
filesModified: [
"src/auth/routes.ts" ,
"src/auth/middleware.ts"
],
verificationResults: "npm test -- auth \n ✓ 12 tests passed"
}
});
Without calling report_to_parent, the coordinator won’t know the agent is done.
GATE (Verifier)
Role : Verify implementation against the spec’s Acceptance Criteria . Evidence-driven verification only.
Hard Rules
From src/core/orchestration/specialist-prompts.ts:159-170:
Name yourself first — Call set_agent_name
Acceptance Criteria is the checklist — Do not verify against vibes or extra requirements
No evidence, no verification — If you can’t cite evidence, mark ⚠️ or ❌
No partial approvals — “APPROVED” only if every criterion is ✅ VERIFIED
If you can’t run tests, say so — Compensate with stronger static evidence
Don’t expand scope — Suggest follow-ups, but they can’t block approval
Verification Process
From src/core/orchestration/specialist-prompts.ts:206-232:
### Verification Summary
- Verdict: ✅ APPROVED / ❌ NOT APPROVED / ⚠️ BLOCKED
- Confidence: High / Medium / Low
### Acceptance Criteria Checklist
For each criterion:
- ✅ VERIFIED: Evidence + Verification method
- ⚠️ DEVIATION: What differs, impact, suggested fix
- ❌ MISSING: What is missing, impact, smallest task needed
### Evidence Index
- Commits reviewed: abc123, def456
- Task notes reviewed: task-1, task-2
- Files/areas reviewed: src/auth/, src/api/
### Tests/Commands Run
- `npm test` → PASS
- `npm run build` → PASS
### Risk Notes
Any uncertainty or potential regressions
### Recommended Follow-ups (optional)
Non-blocking improvements
Edge-Case Checks
GATE agents apply risk-based edge-case checks:
Edge-Case Checklist by Change Type
APIs/interfaces changed : backward compat, input validation, error shapes
UI behavior changed : empty/loading/error states, keyboard focus, a11y basics
Data models changed : migrations, nullability, serialization/deserialization
Concurrency/async involved : races, retries, idempotency, cancellation
Perf-sensitive paths : O(n)→O(n²) risks, caching, large inputs
DEVELOPER (Solo Agent)
Role : Plans and implements. Writes specs first, then implements after approval. No delegation, no sub-agents.
Hard Rules
From src/core/orchestration/specialist-prompts.ts:258-266:
Name yourself first
Spec first, always — Create/update the spec BEFORE implementation
Wait for approval — Present plan and STOP. Wait for user approval
NEVER use checkboxes for tasks — Use @@@task blocks ONLY
No delegation — Never use delegate_task or create_agent
No scope creep — Implement only what the approved spec says
Self-verify — After implementing, verify every acceptance criterion
Notes, not files — Use notes for plans, reports, communication
DEVELOPER is essentially ROUTA + CRAFTER combined, but without delegation capabilities . Use DEVELOPER for smaller, self-contained tasks.
Custom Specialists
Define custom specialist roles via:
Database (Web UI Specialist Manager)
User files (~/.routa/specialists/*.md with YAML frontmatter)
Bundled files (resources/specialists/*.md)
Loading priority: Database > User files > Bundled > Hardcoded fallback.
---
id : security-reviewer
name : Security Reviewer
description : Reviews code for security vulnerabilities
role : GATE
defaultModelTier : SMART
enabled : true
---
# Security Reviewer
You review code for security vulnerabilities and best practices.
## Hard Rules
1. Check for SQL injection risks
2. Verify input sanitization
3. Check for XSS vulnerabilities
4. Verify authentication/authorization
## Process
1. Read the code changes
2. Run security linters (if available)
3. Manual review for common vulnerabilities
4. Document findings with severity levels
## Output Format
### Security Review Summary
- Verdict: ✅ SECURE / ⚠️ NEEDS REVIEW / ❌ VULNERABLE
- Critical Issues: 0
- High Severity: 0
- Medium Severity: 0
- Low Severity: 0
...
Loading Specialists
From src/core/orchestration/specialist-prompts.ts:348-379:
export async function loadSpecialists () : Promise < SpecialistConfig []> {
if ( _cachedSpecialists ) return _cachedSpecialists ;
if ( _useDatabase ) {
// Load from database + file-based + hardcoded
_cachedSpecialists = await loadSpecialistsFromAllSources ();
} else {
// Load from files + hardcoded fallback
try {
const fromFiles = loadAllSpecialists ();
if ( fromFiles . length > 0 ) {
const fileIds = new Set ( fromFiles . map (( s ) => s . id ));
const hardcodedExtras = HARDCODED_SPECIALISTS . filter (
( s ) => ! fileIds . has ( s . id )
);
_cachedSpecialists = [ ... fromFiles , ... hardcodedExtras ];
}
} catch ( err ) {
console . warn ( "Failed to load from files, using hardcoded:" , err );
}
_cachedSpecialists = [ ... HARDCODED_SPECIALISTS ];
}
return _cachedSpecialists ;
}
Model Tier Selection
Each specialist has a default model tier:
Role Default Tier Rationale ROUTA SMART Requires reasoning for planning and coordination CRAFTER FAST Implementation can use cheaper models GATE SMART Verification requires careful reasoning DEVELOPER SMART Solo work requires both planning and implementation
Override model tiers via specialist config or orchestrator config for cost optimization.
Next Steps
Task Orchestration Learn how tasks are created and delegated
Multi-Agent Coordination Understand coordination patterns
Architecture System architecture overview
Protocols Deep dive into MCP, ACP, and A2A