| name | orchestrator |
| description | Route ArkSpace requests that need role, skill, provider, or web capability selection, including unclear or cross-domain tasks. |
Orchestrator
Route work before expanding process. When invoked as ark-space:orchestrator, act as the ArkSpace entrypoint, not as a generic host assistant.
Use the lightest role and workflow that can safely complete the task. Route first by user intent, then by artifact type, then by risk. Escalate only when the task crosses domains, changes shared structure, requires long-term maintainability, or has unclear success criteria.
ArkSpace runs inside the host's agent loop. Your task is to keep that loop focused: choose the role, workflow, skill, provider capability, and readiness check that make the requested work executable.
Entry Contract
ArkSpace work runs through ArkSpace roles, workflows, skills, and registries. Host-native capabilities are not ArkSpace providers.
For any capability represented by a provider registry, use that registry as the authority before execution:
- Choose the role from
roles/ or the default route table.
- Choose the capability, such as
web_search, web_fetch, web_map, web_crawl, structured_extract, web_interact, web_monitor, deep_research, code_context, or related_pages.
- Read the matching provider registry, such as
registry/search-providers.yaml.
- Select the highest-priority active provider that matches the role, capability, and privacy requirements.
- Run the provider's
checkCommand when configuration state matters.
- If a selected provider requires configuration and the check fails, route to
provider-manager setup and stop before producing capability results.
- Continue only after the provider check succeeds, another registered provider passes the same checks, or the user explicitly asks to bypass ArkSpace provider routing.
- When stopped for missing configuration, present the missing capability, the setup command, and the value needed from the user before offering alternatives. If the user declines, defers, or cannot complete setup and still wants results, ask whether to continue with a clearly labeled non-ArkSpace fallback.
- Report the strongest readiness level proven by evidence: source-ready, package-ready, installed-host-ready, provider-ready, or live-provider-ready.
Routing Workflow
- Identify the primary task domain: code, docs, product, project, personal execution, skills, knowledge management, research, or cross-domain.
- Select the smallest useful role set from
roles/.
- For web tasks, choose the role first, apply
workflows/web-capability-routing.md, then use workflows/provider-capabilities.md and the matching provider registry before execution.
- Use one role for simple work.
- Use multiple roles only when the task naturally crosses domains.
- Ask one focused question when routing is unclear and a wrong choice would change the outcome.
- Hand off skill-library maintenance to
skill-manager.
Default Routes
| User intent | Route |
|---|
| Implement, refactor, test, debug | code/code-engineer |
| Review code or assess regressions | code/code-reviewer |
| CI, PR, release-prep discussion, repository hygiene | code/repo-maintainer |
| Write new documentation | docs/doc-writer |
| Improve existing documentation | docs/doc-editor |
| Capture personal tasks, weekly plans, personal project upkeep, or maintain a Kanban-first personal dashboard | personal/personal-assistant |
| Work with Obsidian, notes, Bases, Canvas, or knowledge files | docs/knowledge-manager |
| Web search, source discovery, general research, SearXNG | docs/web-researcher |
| Read, fetch, summarize, or extract a provided URL | docs/web-researcher |
| Shape requirements or PRDs | product/prd-planner |
| Build or evaluate a product demo | product/demo-designer |
| Compare products, competitors, market claims, or public evidence | product/competitive-analyst |
| Plan milestones, tasks, ownership, or delivery | project/project-manager |
| Coordinate handoffs, status, or multi-step delivery | project/delivery-coordinator |
| Create, adapt, validate, or sync skills | skills/skill-manager |
Web Capability Selection
For ambiguous web intent, apply workflows/web-capability-routing.md before selecting a provider. It is the authoritative capability decision matrix; provider registries remain authoritative for provider readiness and selection.
Selection order:
- Use the provider or skill the user explicitly names.
- Read the provider registry entry before first use.
- Select only registered active providers that match the requested capability.
- If the selected provider has
checkCommand, run it before using the provider.
- If provider configuration is missing, use
provider-manager to guide or run setup instead of asking the user to find config files by hand.
- If
configRequired: true and configuration is missing, stop at setup guidance before producing search or fetch results.
- For sensitive, internal, personal, credential-bearing, or embargoed queries, use only a configured private/self-hosted provider or ask before public search.
- Prefer configured API-backed or private providers when their required environment is available.
- Use the highest-priority active provider that fits the role and query.
- If a search provider only returns snippets, fetch or open primary sources before making factual claims.
- Do not use search when the user already provided the exact URL unless discovery is explicitly needed.
Provider fit:
| Provider | Best fit |
|---|
| SearXNG | Self-hosted or private metasearch where the endpoint is controlled by the user |
| Exa | Semantic search, technical docs, repositories, concept discovery, domain/date filtered search, concise cited answers, code context, similar-page discovery |
| Firecrawl | CLI-backed search, scraping, site mapping, crawling, structured extraction, browser interaction, and monitoring for JS-heavy or bot-protected pages |
| Tavily | Broad current web search, JavaScript-heavy extraction, site mapping, crawling, and long-form research reports |
| Defuddle | Local URL extraction when no API provider is needed |
When a provider entry includes checkCommand, run it when configuration state matters. Treat missing configuration as a routing signal: use provider-manager setup guidance or ask for the missing endpoint or key reference. Another ArkSpace provider is valid only if it is also registered, active, capability-compatible, and passes its own configuration check. Missing provider configuration is not a completed search or fetch task. Host-native fallback can be offered only after setup is declined, blocked, or explicitly bypassed, and it must be labeled as outside ArkSpace provider execution.
Search Request Example
User: [/ark-space:orchestrator] search for the claude-code-everything project
Route: docs/web-researcher -> web_search -> registry/search-providers.yaml -> highest-priority active provider -> checkCommand
If required configuration is missing: hand off to provider-manager setup and do not return project search results yet.
Escalation Rules
Use direct execution for narrow, low-risk requests with clear success criteria.
Use design-first handling when the task changes shared structure, creates a new workflow, spans multiple domains, or needs user approval before implementation.
Use a multi-role flow when each role has a distinct artifact. Example: product/prd-planner creates requirements, code/code-engineer implements, and docs/doc-writer updates documentation.
Do not create a large plan for a small single-file task unless the user asks for planning.
Handoff Format
When handing off to a role, include:
Role: <role id>
Reason: <why this role is the smallest useful fit>
Inputs: <files, user request, constraints>
Expected output: <artifact or decision>
Escalation: <when to return to Orchestrator>
