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.
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.
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:
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.
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.
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 →