route-delegation

Routes multi-agent work between subagent fan-out, local execution, and Invoker submission based on outputs.

18|5|Updated Apr 17, 2026
One-click install
npx skills add https://github.com/Neko-Catpital-Labs/Invoker --skill route-delegation-neko-catpital-labs
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: route-delegation
Source: https://github.com/Neko-Catpital-Labs/Invoker/tree/main/skills/route-delegation
Command: npx skills add https://github.com/Neko-Catpital-Labs/Invoker --skill route-delegation-neko-catpital-labs

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve? When an agent is about to fan out work across subagents, it often defaults to parallelism without checking whether any unit will publish commits, PRs, tags, merges, or deploys. This Skill prevents unreviewed publishing swarms by forcing an explicit routing decision before any fan-out happens. ## Core Features & Use Cases - Output-based routing: Classifies each unit's declared output as publishing (commit, pull_request, tag, merge, deploy, durable_artifact) or non-publishing (report, research, review, verification) and routes accordingly. - Three deterministic routes: Returns local, delegate_invoker, or subagent_fanout with concrete handoff steps for each route. - Executable decision script: A Node.js CLI validates work kinds and outputs, exiting non-zero on undeclared or unknown outputs. - Use Case: Before spawning eight subagents for a separable refactor, run the routing check; if any unit produces a commit or PR and Invoker MCP tools are available, the work is submitted to Invoker's persisted task graph instead of an unsupervised swarm. ## Quick Start Ask the agent to run the route-delegation check with the available tools, work kind, and declared outputs before spawning any subagents.

Frequently Asked Questions about route-delegation

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide between subagents and Invoker for parallel work?

Name what each unit produces first. If nothing publishes (only reports, research, or reviews), fan out to worktree-isolated subagents. If anything publishes a commit, PR, tag, merge, or deploy, submit to Invoker when its MCP tools are available.

When should work go to Invoker instead of a subagent swarm?

Work goes to Invoker whenever any unit publishes, such as approved plans, durable parallel work, post-merge babysitting, or a named execution backlog. Invoker provides a persisted plan, retries, merge gates, and a single reviewed approval.

What happens if Invoker MCP tools are not available?

If invoker_prepare_plan_review and invoker_submit_plan are missing, publishing work stays local and the parent session executes it in its own worktree. Read-only or small one-file work also stays local regardless of tool availability.

Why does the route-delegation script exit with an error?

The script exits non-zero when produces is empty, contains an undeclared output name, or the work_kind is unknown. Every output must be named from the fixed publishing or non-publishing vocabulary before routing.

Can subagents handle work that creates commits or pull requests?

No. A swarm that commits operates outside Invoker's task graph with no persisted plan, retries, merge gate, or resumability. Publishing work must route to Invoker or stay local in the parent session.