Your agent handles the Python service well, so you go looking for more of that. You find twenty skill files published together, one per language, one per cloud, one per database, and you install the lot, because covering everything looks like the careful choice. The next morning the agent hedges. It asks about the Java build in a repository that has no Java in it. None of those files is wrong; the Python procedure is still the one that worked yesterday. You did not hand the agent twenty new capabilities. You handed it twenty sets of instructions to weigh before every move.

The book stays at the house

A skill is less exotic than the word suggests. Somebody did a job once — ran a database migration, cut a release, tracked down a flaky test — wrote down the steps that worked, and left the scripts and the worked examples beside them, in a file the agent reads when that job comes around again. It can also write its own: Voyager, an agent playing Minecraft, saved the code that worked as it explored and called it back later rather than solving the same problem twice.

A fire crew keeps its procedures the same way. The full set lives at the house, written by people who have been to the calls, drilled and revised over years. What rides on the truck is the part this call needs. Nobody reads the ventilation guidance on the way to a person stuck in a lift, and the crew that tried to would arrive slower and less sure.

Loading skills works the same way, and the discipline is in the choosing. A Python project on Azure installs the Python SDK skill and leaves the Java and Rust ones where they are. The others are not withheld from the agent as a punishment. They are simply not in the room, so they cannot argue with the instructions that belong to the work in front of it.

Twenty skills installed is not twenty capabilities

Everything loaded spends the same limited room the task itself needs, so the twenty you installed for safety are charged to every job, in tokens and in attention. Worse, skills written for different stacks give conflicting advice about the same words — build, deploy, test — and the model has to decide which voice it is listening to before it can start. That is the vagueness you saw. It also has a security edge: a skill is instructions the agent will follow, so an unvetted one is a way into your workflow, which makes installing everything the least careful option available rather than the most.

The other half of the problem arrives when the collection gets big. A skill nobody can retrieve is worse than a skill nobody wrote, because you planned around it being there. And distribution proves nothing on its own. If you want to know whether a skill helps, run the same tasks with it and without it, across more than one repository, and compare outcomes — did the migration apply, did the test pass — not whether the file is well formed. The measurement is dull and it is the only thing that separates a skill from a strong opinion in a file.

Nothing enters the book without a drill

Skills change. The agent fails the same way three times, someone reads the transcript, and an edit suggests itself. This is where libraries quietly rot: an edit made to fix the incident you remember can break two you never see. The gate is what stops it. A proposed edit is a candidate, not a change, and it replaces the current version only if it beats that version on validation tasks held back for exactly this purpose. A search skill gets tightened after recurring errors, then the tightening is thrown away because precision drops on examples nobody used to write it.

That makes improvement measurable and reversible, and it is the same move as an agent that rewrites its own scaffolding — proposals are cheap, acceptance is not. The library also needs someone deciding what gets removed when it goes stale and who may edit it at all.

Which is why capability is not a thing you accumulate. It is assembled, one call at a time, out of what you chose to load and what earned the right to be loadable.