Your AI Workers Were Hauling The Whole Toolbox. We Fixed That.
💥 The problem: Every spawned worker inherited every installed skill and every active tool — even when the task only needed two of them.
🔧 The fix: A two-tier skill system + a pre-spawn analyzer that picks the minimum each worker actually needs.
✅ The result: Workers stay lean. Your skill collection can grow into the hundreds without bloating any single session.
The plumber problem
Imagine calling a plumber for a leaky tap. They show up — and bring the entire workshop. Every wrench, every spare boiler part, the apprentice, the van, the cat.
That was every orchestra worker until last week. Each one spawned as a fresh Claude Code session that loaded every installed skill and every active tool server. A worker writing a single haiku was opening a 50,000-token toolbox to do it.
Core insight: Context is real estate. Every token spent on tools the worker doesn't use is a token it can't spend on the task.
The Builder fixing a typo in a product description still loaded 33 globals, 5 MCPs, and the entire library catalog. The cost of "just in case it needs it" is paid in tokens, every spawn, forever.
Drag this. Watch the room fill up.
Below is a live model of a worker's context window. Drag the sliders to add skills and tool servers. Watch how fast you eat your million-token budget when nothing is scoped.
Two skill drawers
The new system splits skills across two folders, each with a different rule about who pays for them.
Globals
Live in ~/.claude/skills/. Every Claude Code session inherits them automatically. This is where your slash commands live — keep them lean.
Library
Lives in ~/.claude/skills-library/. Invisible to normal sessions. Only loaded when an orchestra worker actually needs them. Scales to thousands.
Click between the tabs to feel the difference. Hover any skill to see what it does.
~/.claude/ ├── skills/ # [ GLOBAL DRAWER always loaded ] │ ├── godmode/ │ ├── one-shot/ │ ├── blog-post-GM/ │ └── ...30 more └── skills-library/ # [ LIBRARY DRAWER cold storage ] ├── sales-page/ ├── pitch-deck/ ├── case-study/ ├── haiku-writer/ └── ...494 more
Three modes the worker can run in
Every productive worker now spawns in one of three modes. The runner picks based on what the analyzer found and whether you flagged strict-scope on the command line.
The trick: Library skills can only reach a worker when explicitly staged. That's how you can keep 500 skills on disk without paying for any of them in your main session — the narrator never sees the library at all.
Meet the analyzer
Before each productive worker spawns, the runner fires a tiny analyzer worker first. The analyzer reads the brief, looks at the catalogs, and returns a picklist: which skills, which tool servers, what thinking budget.
Watch one route a brief in real time:
It runs first, with a single job: read the brief, score every candidate, return a picklist. Costs about 1.5k tokens. Saves about 36k. The math wins on every brief that isn't already maximally scoped.
Before vs after, on a real worker
Here's what the same Builder worker actually loads, with and without the new system. Same task, same brief, two contexts.
- 33 globals + 5 MCPs always loaded
- 0 library skills loaded ever
- ~84.5k tokens before task starts
- can't grow library past ~150 skills
- workers slow on huge briefs
- analyzer keeps 1 to 3 of each
- library scoped to brief picks only
- ~12.1k tokens before task starts
- library scales to thousands
- workers stay sharp on full context
What it looks like to set up
If you already use orchestra, you have the globals tier. The library tier is opt-in by literally creating the folder.
mkdir ~/.claude/skills-library
mv ~/.claude/skills/sales-page ~/.claude/skills-library/
orchestra rebuild-manifestThat's it. The skill is now invisible to normal sessions and only loaded when an orchestra worker's brief plainly needs it.
The rules in a table
| Mode | Globals | Library | When |
|---|---|---|---|
| none | Inherited | Hidden | Default. No library picks. |
| library-stage | Inherited | Picked ones staged | Auto. Analyzer picked library skills. |
| strict | Suppressed | Picked ones staged | Opt-in via --scope-skills. |
What's next
The catalog the analyzer reads is currently inlined verbatim. Past about 150 library skills it gets chunky — the analyzer itself spends real tokens parsing the menu.
Next up: a retrieval layer so the analyzer only ever sees the top-N candidates per brief, not the full pool. That unlocks libraries with thousands of skills without paying linearly for it.
Today the analyzer reads the full catalog. At 150 skills that's fine. At 1500 it isn't. A retrieval layer ranks the top 24 candidates per brief and only those reach the picklist. The library can then grow to thousands without paying linearly for a bigger menu.
One-Shot Orchestra is in One-Shot
The orchestra runner ships inside the One-Shot tier. Massive skill libraries, lean workers, no manual juggling.
Get One-Shot More posts →// promote_godmode
Got value from this post? Become an affiliate. Auto-approved in 60 seconds, 30 to 40% recurring commission, your audience gets 10% off automatically with code AFFILIATE10. 90-day cookie, monthly payouts.