Essay · August 7, 2026

NOT FOR: the two words that make a big skill pack work

With enough skills installed, the failure mode stops being "the skill didn't work" and becomes "the wrong one ran."

A skill's description is the only thing the router sees. It is not documentation, it is the entire basis for a decision the agent makes before reading anything else. Once a pack passes roughly a dozen skills, most descriptions are wrong in the same way: they say what the skill does and stay silent about what it isn't for. That silence is where broad packs go bad.

The most eager description wins

Picture five skills whose descriptions all truthfully mention "code." A review skill, a grading skill, a CI skill, a debugging skill, and a full shipping pipeline. Every one of them is a plausible match for "can you look at this code." Nothing is broken. Nothing errors. The agent picks whichever description sounds most enthusiastic about the request, and the tiebreaker is essentially prose style.

That's the actual failure mode of a large pack, and it doesn't look like failure. It looks like a fifty-agent shipping pipeline running against a one-line typo fix, or a quick review skill being handed a change that needed the full gate. Both produce output. Both feel like the system worked. Only one of them was the right call, and you have no signal telling you which.

Adding skills makes this worse on a curve, not a line. Ten skills have forty-five possible pairwise collisions. Seventy have well over two thousand. You cannot fix that by writing better positive descriptions, because the problem isn't that any description is inaccurate. They're all accurate. The problem is that accuracy about what a skill does says nothing about whether it should beat its neighbor.

Negative space is routing information

The fix is to make every description carry its own boundary, and to make that boundary point somewhere specific:

Read what that line is doing. It isn't a disclaimer and it isn't hedging. It's a routing table, written from the perspective of the skill most likely to steal the request. Three near-misses, each one named, each one handed to the sibling that should have it.

The generic version of this is worthless. "NOT FOR: other tasks" tells the router nothing. The line only works when it names the specific neighbor and the specific condition under which that neighbor wins, because the router's actual question is never "is this skill relevant." It's "is this skill more relevant than that one," and only a named comparison answers it.

The counterintuitive part

Here's the property that makes a broad pack viable at all.

Under positive-only descriptions, every skill you add dilutes the pack. One more competitor for every request, one more way to pick wrong. Growth is a liability, and the honest advice for a pack that size is to split it up.

Under boundaried descriptions, adding a skill does the opposite. Writing a new skill forces you to name which existing skills it must not steal from, and to go add the reciprocal line to each of them. Every addition sharpens a set of boundaries that were previously fuzzy. The pack gets more precise as it grows, because growth is what surfaces the ambiguity that was already there.

That's the whole reason a seventy-one skill pack can behave better than a twelve-skill one. Not despite the size. The size is what forced every boundary to get written down.

Writing one that works

Three rules, learned by getting them wrong:

• Name the sibling, not the category. "Use suede-code-review" routes. "Use a review tool" does not.
• Name the condition, not the vibe. "Findings-only review with no code change" is testable against a request. "Smaller jobs" is not.
• Write it from the near-miss, not the far-miss. Nobody confuses a shipping pipeline with a rights audit. The dangerous neighbor is always the one that does almost the same thing, and that's the only one worth a line.

The test is mechanical. Take a request that should go to a neighboring skill, hand it to this one, and see whether the description alone sends it away. If it doesn't, the boundary isn't written yet, and it isn't the router's fault.

How routing works in the pack Browse all 71 skills