Your Skill Library Is a Context Tax

There is a thriving cottage industry right now in collecting skills. Curated packs, awesome-lists, and lately entire management systems for organizing the hundreds of skill files people have accumulated, with search and tagging and version control for what amounts to a library of instructions the agent might someday need. I understand the impulse. We went through it too. And after running benchmarks across every model tier, we can name exactly what it is: the same mistake as always reaching for the biggest model, wearing a different costume.

Our benchmark data keeps repaying one lesson: you don't need the best model for most tasks. The smallest model in the Claude family matches or beats its expensive siblings on the bounded work that makes up most of a development day. The skill-hoarding version of that lesson is one step further down and even less intuitive: you don't need a model at all for things code already does. Every skill that describes a procedure a deterministic tool could execute is paying a model to approximately do what software does exactly.

Every Skill Is a Tax on Every Session

A skill file is not free at rest. It loads into context, where the model must read it, weigh it against the actual task, and successfully not be distracted by it. That cost recurs on every session that might touch the skill, whether or not it does. Collect three hundred skills and you have not built a capability library; you have built a standing tax on the attention of every agent you run, paid before any work happens.

The tax compounds through drift. A skill describes your tooling as it existed the day someone wrote the skill. The tooling moves; the prose does not. Now the context carries instructions that are confidently, specifically wrong, and a model's failure mode on wrong instructions is not to flag them. It is to follow them faithfully.

We know because it happened to us, in the project that exists to prevent exactly this. A drift audit found our own task-management skill still documenting a --force flag the CLI no longer has. The history of that flag is the whole argument in one artifact: --force existed because it was how the model bypassed a problem we hadn't yet solved deterministically. Then we solved it, the flag was pulled, and the code moved on. The skill didn't. The prose kept teaching agents a workaround for a problem that no longer existed, alongside a priority level the planner had stopped accepting and command counts two releases stale. An agent following that skill to the letter would have failed, politely and precisely, doing exactly what we told it. The CLI's own --help output was correct the entire time, because generated reference doesn't drift from the code that generates it. Code deletes its workarounds. Prose embalms them.

If It's Deterministic, It's Code. If It's Judgment, It's a Recipe.

The sorting rule we run now is simple. Anything with one correct outcome gets pulled out of prose and into software: a command, a gate, a hook. The agent doesn't need three paragraphs on how we like tests run; it needs a command that runs them and a gate that fails closed when they don't pass. It doesn't need guidance about architectural limits; it needs a check that blocks completion when a file outgrows the limits this project set for that kind of file. The limits themselves are configuration, not commandments: a rendering module earns different caps than a CLI handler, and the numbers we started with are not the numbers we run today. The point is never the threshold. The point is that a threshold enforced by code moves when you decide it should, while a threshold written in prose gets quoted forever. That chain of deterministic checks has caught confidential files staged for public packaging, verifiers that failed open, and destructive cleanup paths. A skill would have caught none of it, because catching things is not what prose does.

What remains after you extract everything deterministic is genuinely small: the judgment-shaped workflows, like how to approach a design or what a review should weigh. Those stay skills, and even they are written as strict recipes that point at commands, not as knowledge bases. We enforce the diet mechanically. Our skill validator caps every skill at 500 lines and fails closed past it. It has blocked our own release skill, which had crept to 518 lines of accumulated helpfulness. We cut it to 482. Nothing of value was lost, and that's the point: it never is.

The current tally in our own project is eleven skills, every one under the cap, sitting next to a CLI with 286 commands. That ratio is the thesis in numbers. The knowledge lives in software that executes and enforces; the skills are a thin layer of judgment on top. When behavior needs to change, we change code and regenerate reference, and the agent's context stays small, current, and honest.

The Test Is Deletion

Minimal is not zero. Strip every skill and agents re-derive your workflow from scratch each session, differently each time. That failure mode is real too, and it's why the judgment layer exists at all. The line between the two isn't a philosophy; it's a test you can run today: pick a skill and ask what would change if you deleted it. If the answer is that a deterministic step might get skipped, that step was never safe as prose: build it as a gate and delete the skill anyway. If the answer is that judgment would get worse, keep it, and cut it to the bone. And if you honestly can't tell what would change, you already know.

You don't need the best model for most tasks. You don't need a model at all for what code already does. The best skill library is the one small enough that every file in it would be missed.