routing
Skill37 starsChanged 4 months agoMITView on GitHub
Cost-optimised task routing. Use at the start of any coding, search, extraction, review, or multi-step task to pick the cheapest execution strategy (deterministic tool, haiku worker, sonnet worker, main model, fable worker) and to handle escalation when a worker fails. Also triggers on mentions of cost, budget, routing, or delegation.
13 other projects use a version of this.
Adopted by
Most recently taken up by
- AnyOrgName/php-skillstheir own version, first seen Nov 8, 2026
- github/replicatheir own version, first seen Nov 1, 2026
- darknecrocities/SkillBuildertheir own version, first seen Nov 1, 2026
- EONRaider/agent-routertheir own version, first seen Oct 20, 2026
- zprolab/WhaleKittheir own version, first seen Oct 13, 2026
- ypollak2/llm-routertheir own version, first seen Oct 12, 2026
Used with
Projects with it also use parallelization, prompt-chaining and 1 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
hajekimSkillparallelization
This skill should be used when the user wants to "run tasks in parallel", "concurrent LLM calls", "fan-out and fan-in", "parallel agents", "simultaneous execution", "reduce latency with concurrency", "parallel sub-tasks", "parallel processing", "concurrent agent execution", "run agents simultaneously", "speed up with parallelism", "async agent execution", "batch LLM calls", "parallel workflow", "parallelize agent tasks", or needs to execute multiple independent tasks simultaneously. Also responds to Korean: "병렬 작업 실행", "동시 LLM 호출", "팬아웃 팬인 패턴", "병렬 에이전트", "동시 실행", "동시성으로 지연 시간 감소", "병렬로 실행", "동시에 여러 작업", "병렬 처리", "동시에 돌려줘", "빠르게 병렬로", "여러 작업 동시 실행해줘". Also responds to Japanese: "並列処理", "同時実行", "並列エージェント", "並行LLM呼び出し", "ファンアウト・ファンイン", "複数タスクを同時に実行したい", "処理速度を上げたい", "非同期エージェント", "バッチ処理", "並列で動かしたい" Also responds to Chinese: "并行处理", "并发执行", "并行智能体", "同时调用多个LLM", "扇出扇入模式", "多任务并行运行", "加快处理速度", "异步智能体", "批量LLM调用", "同时运行多个任务".. Apply this skill to design or implement the Parallelization agentic design pattern.
Also in 3 projects that use this
hajekimSkillprompt-chaining
This skill should be used when the user wants to "chain prompts", "build a pipeline", "break down complex tasks into steps", "sequential LLM calls", "multi-step reasoning", "pipeline pattern", "sequential agent pipeline", "multi-step prompt pipeline", "LLM chain", "step-by-step agent", "prompt pipeline", "decompose task into prompts", "stage-by-stage processing", "chained LLM calls", or when a task is too complex for a single prompt and needs to be decomposed into sequential sub-tasks. Also responds to Korean: "프롬프트 체이닝", "체인 방식 에이전트", "단계별 LLM 호출", "복잡한 작업 분해", "순차적 프롬프트 파이프라인", "단계적 작업 처리", "단계별 처리", "순차 처리 에이전트", "파이프라인 만들어줘", "단계적으로 처리해줘", "연속 프롬프트", "체이닝 해줘". Also responds to Japanese: "プロンプトチェーニング", "ステップごとに処理", "順次LLM呼び出し", "パイプライン構築", "複雑なタスクを分解", "段階的エージェント", "連続プロンプト", "LLMパイプライン", "順番に処理してほしい", "チェーン方式エージェント" Also responds to Chinese: "提示词链", "顺序调用LLM", "构建流水线", "分解复杂任务", "逐步处理", "链式提示", "多步骤流水线", "按顺序处理任务", "提示词管道", "帮我一步一步处理".. Apply this skill to design, implement, or explain the Prompt Chaining agentic design pattern.
Also in 3 projects that use this
NVIDIASkilltesting
Run Python and Rust tests for physicsnemo-curator using uv + pytest with coverage reporting via pytest-cov, and cargo-nextest for Rust tests. Includes benchmark workflows with pytest-benchmark and criterion.
Also in 3 projects that use this
Other versions13 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 13
- github/replica★ 230same name
- ypollak2/llm-router★ 123same name
- darknecrocities/SkillBuilder★ 13same name
- flpbalada/fb-skills★ 8same name
- AnyOrgName/php-skills★ 4same name
- hajekim/agentic-design-patterns-skills★ 4same name
- jkaninda/okapi-skills★ 3same name
- ffsshhttiikk/opencode-agents-skills★ 2same name
- EmmittJ/guild★ 1same name
- hajekim/agentic-design-patterns-extension★ 1same name
3 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository3 other files it gives its agents.
- modelsSkill
- router-statsSkill
- setup-statuslineSkill
The file
We split this skill into the rules it gives an agent
5 rules. 0 are common, 3 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 12 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 12
If .claude/routing-overrides.md exists in the project, read it first.
- Distinctive: line 16
Before any delegation: if a deterministic command solves the task (grep, rg, jq, yq, sed, awk, git, terraform, kubectl, helm, docker, a …
- Distinctive: line 62
No deterministic check: spot-read the result yourself.
- Very specific: line 64
If the task still exceeds your own tier after you take over: hand it to sage with the full failure history, prefixed [frugal-escalation …
- Distinctive: line 65
Never start at an expensive tier unless the decision table sends you there.
“Common” is measured: kept by at least 6 in 10 of the 12 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Frugal routing
Route every sub-task to the cheapest strategy that can succeed. Priorities, in order: correctness, cost, latency, extensibility, simplicity.
Step 0: overrides
If .claude/routing-overrides.md exists in the project, read it first. Its rules win over everything below.
Step 1: tool first
Before any delegation: if a deterministic command solves the task (grep, rg, jq, yq, sed, awk, git, terraform, kubectl, helm, docker, a compiler, a test runner), run it. No LLM call. Reasoning models are for reasoning.
Step 1 covers one-shot commands only: you know the exact command and its output answers the question directly. The moment discovery turns iterative — a second search informed by the first, listing directories to decide what to read next, reading files to summarise them — it is no longer a tool call, it is a locate/extract task. Bright line: the third search/list/read operation on the same question means you are exploring inline; stop and hand the whole question to scout or extractor, including what you already learned. Every raw tool result you ingest is paid at main-loop rates; a haiku worker reads the same bytes at a fraction of the cost and returns a summary.
Step 1.5: sensitivity gate
Sensitivity is not a task-type signal, so it cannot live in the decision table below. Some data must never leave the main loop for a worker, however cheap the task looks. Decide this before tier selection, not by letting a worker fail into it.
If .claude/frugal-sensitivity.json exists in the project, it declares rules (content regexes and path globs) and, per rule, which workers may still receive matching data. The guard_sensitive.py hook enforces it at spawn: a matching Agent delegation to a non-allowed worker is blocked, and you handle that sub-task inline. The gate fails closed (a broken config blocks delegation), unlike the cost hooks which fail open. With no such file the gate is off. See examples/frugal-sensitivity.example.json.
This is an enforced default, not a substitute for judgement: for regulated data the human owns the final call on where it may go.
Step 2: decision table
Decompose the request into sub-tasks. For each, match signals to the cheapest capable agent:
| Task signals | Required capabilities | Route |
| "where is X", "what uses Y", map directory, grep logs | locate | scout (haiku) |
| pull fields from docs/logs, classify against given categories, summarise one file or diff, format conversion | extract | extractor (haiku) |
| rename, boilerplate, apply known pattern, config value change, test scaffold from example, with a complete spec | mechanical-edit | mechanic (sonnet) |
| implement one scoped task from an approved plan, write tests from given cases, fix a simple reproduced bug | implement-from-plan | builder (sonnet) |
| design, debugging, ambiguous requirements, reviews, trade-offs, anything regulated or risky | reasoning | main loop (you) |
| task exceeds the main loop's own tier, or Fable-level work needs an isolated fresh context (parallel deep reviews, synthesis over merged summaries) | deep-reasoning | sage (fable) |
sage is never a routing default. Check what the main loop actually runs before reaching for it: on Opus 5 (or any tier below Fable) sage is a real capability escalation and the decision table's first clause applies; if the main loop already runs Fable, use sage only for context isolation, not capability.
Generic agents are never routing targets. Explore, general-purpose, claude, and Plan are reasoning-tier and bill at main-loop rates — never spawn them for locate, extract, or summarise work, no matter how broad the fan-out. Map them down: locate/map -> scout; extract/summarise/classify -> extractor; mechanical edits -> mechanic/builder; reasoning stays in the main loop. A bare Agent call with no subagent_type defaults to general-purpose (expensive) — always name a cheap agent explicitly. The guard_expensive.sh hook blocks these at spawn time; FRUGAL_ALLOW_EXPENSIVE=1 is the deliberate, per-session override for when a task genuinely needs main-loop breadth.
Workers pin their own reasoning effort in frontmatter: low for scout, extractor and mechanic, medium for builder, high for sage. Model tier is one axis of cost and thinking is another, so a session running at high effort no longer makes a haiku scout deliberate over a grep.
Never delegate
Security-sensitive changes, destructive operations, ambiguous requirements, anything needing user judgement. These stay in the main loop, always.
Delegation rules
- Delegate only self-contained sub-tasks the prompt can fully specify. If specifying takes longer than doing: do it inline.
- Delegation has a floor. A spawn costs about the same whether the task is trivial or large, so a job too small to repay that fixed cost is cheaper done inline.
scripts/stats.pyprints the measured floor per agent ("delegating pays off above ~N tokens of reading") from your own runs; under it, read it yourself. - Context handoff: pass pointers (
path:lineranges, commit SHAs, URLs), never pasted file content. Pasting is billed as main-loop output tokens (fable$50/MTok, and generating them takes wall-clock time); a worker reads the same bytes as haiku input ($1/MTok) in one round trip. Paste only what the worker cannot retrieve itself — text that exists solely in the conversation (user message, prior tool output, fetched page) — or trivially small snippets (<~200 tokens). - Batch independent delegations in one message so they run in parallel. Large fan-outs (e.g. review 50 modules): fan out
scout/extractorworkers, merge their summaries, do one final reasoning pass yourself. - Workers end with a footer (
RESULT:/CHECKS-RUN:/UNCERTAINTIES:/ESCALATE:). A worker reporting ambiguity: resolve it yourself; never re-prompt the worker to guess.
Escalation protocol (verification first)
- A deterministic check exists for the worker's output (tests, compiler, schema validation, diff applies,
terraform validate): run it. Pass = done. Fail = re-dispatch one tier up (haiku worker -> equivalent sonnet worker; sonnet worker -> take over yourself), maximum one retry. Prefix the retry prompt with[frugal-escalation from <agent>]and include the failed attempt's footer. - No deterministic check: spot-read the result yourself. You receive it anyway; judging it costs almost nothing.
- The worker's
ESCALATE: yesis advisory input to rules 1 and 2, never the sole trigger. - If the task still exceeds your own tier after you take over: hand it to
sagewith the full failure history, prefixed[frugal-escalation from main]. One attempt, final. - Never start at an expensive tier unless the decision table sends you there.
Budget
FRUGAL_BUDGET_USD sets a per-session ceiling, counting main-loop spend as well as delegated spend. Under 80% of it nothing is said. From 80% a warning arrives with each prompt: delegate harder, keep worker replies terse, leave sage alone. At 100% stop and confirm with the user before starting new work, and reasoning-tier spawns are denied even with FRUGAL_ALLOW_EXPENSIVE=1, because they cost more than the main loop does. Cheap workers stay allowed at every level: they are how you get back under.
Unset means no ceiling and no warnings.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

