The same install runs an A-F code review, a design pass on the screen you just shipped, and a fight with Amazon over a denied refund. That combination used to be a punchline. "Do one thing well" was good advice for the entire history of software, and a tool that claimed to do all three would have been three bad tools in a trench coat.
Suede Creator Skills is now 71 skills in one pack, and it behaves better at 71 than it did at twelve. That isn't a claim about ambition. It's the result of three design decisions, each of which sounded wrong before it worked. This piece walks through all three: where durable knowledge should live, how a pack that size routes requests, and why the old instinct to cut scope no longer applies.
Part one: your memory file is a tax you pay on every prompt
Every agent accumulates knowledge that ought to outlive the session. How this repo wants to be branched. Which build command is the real one. The correction you made three weeks ago that you never want to make again. The default home for all of it is a memory file, and a memory file has one property that quietly ruins it.
It loads on every turn.
A memory file is unconditional. It costs the same whether you asked the agent to ship a release or fix a typo. Write 5,000 tokens of hard-won operating knowledge and you have signed up to pay 5,000 tokens on every prompt for the rest of the project, including the ones where none of it applies.
That's the visible cost, and it's the smaller one. The real damage is attentional. Instructions in a long file compete with each other. Add the twentieth rule and the first nineteen get slightly harder to follow, because the model is now allocating attention across twenty things that all claimed to matter equally. A memory file that grows monotonically doesn't just get expensive. It gets less obeyed, rule by rule, and the failure is invisible: nothing errors, the agent just quietly stops honoring something you wrote down two months ago.
So memory has a perverse shape. The more diligently you maintain it, the worse it performs. Most people notice this as "the agent ignores my CLAUDE.md" and respond by adding emphasis, capital letters, and IMPORTANT tags, which is treating a capacity problem as a compliance problem.
There's one test for any durable fact you're about to write down: does this apply to every turn, or only some turns?
Every-turn facts genuinely belong in memory. Who you are. What you're standing-authorized to do without asking. Global constraints that hold no matter what the task is. These are cheap, few, and correctly unconditional.
Some-turn facts are almost everything else, and they are miscategorized by default. How to cut a release. What this project's CI conventions are. How to handle a return, a rights audit, an App Store submission. Each one is critical on the day it applies and pure overhead on every other day. Put it in memory and you pay for it constantly to use it occasionally.
A skill is the same information with a condition attached. The agent holds the name and the description. The body stays on disk until a request matches. You pay a line to have it available and the full price only when you use it.
The part that surprised me
I expected this to be a cost optimization. It turned out to be a quality one, for a reason I didn't anticipate.
Memory forces compression. Because every line is billed on every turn, you write the shortest thing that might work. "Always use worktrees." That's what fits. What you actually know is longer: why worktrees, which directory convention, the two places worktrees hide, why the session registry lies about which ones are live, what a squash-merged branch looks like when you're deciding whether to delete it. All of that gets cut, because you cannot afford six paragraphs in a file that loads unconditionally.
A skill has no such pressure. Its body is read only when relevant, so length is nearly free. You can write the failure modes, the exact commands, the counterexample that cost you an afternoon, the check that looks redundant and isn't. The knowledge doesn't just move. It gets to be complete for the first time.
And once knowledge lives in a file with a name and a boundary rather than in an undifferentiated memory blob, ordinary software practice starts applying to it. It diffs, so you can see what changed about how the agent works, and when. It reviews, so a rule can be argued with before it ships. It travels, so it installs on another machine or for another person. And it can be deleted: removing one skill removes one behavior, while removing one line from a 200-line memory file is a guess about what else depended on it.
Part two: with enough skills, the failure mode changes
Move everything into skills and a new problem appears. 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. 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 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 failure 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 45 possible pairwise collisions. Seventy-one has 2,485.
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:
suede-ship — NOT FOR: high-volume, well-specified work that splits into independent worker-sized tasks (use suede-codex-fleet); findings-only review with no code change (use suede-code-review); CI and branch-protection wiring (use suede-ci-gate).
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.
Three rules for writing one, 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.
Here's the counterintuitive part, and the whole reason a large pack is viable. Under positive-only descriptions, every skill you add dilutes the pack: one more competitor for every request, one more way to pick wrong. Under boundaried descriptions, adding a skill does the opposite. Writing a new one forces you to name which existing skills it must not steal from, and to add the reciprocal line to each of them. Every addition sharpens boundaries that were previously fuzzy. The pack gets more precise as it grows, because growth is what surfaces the ambiguity that was already there.
Part three: breadth is free now
"Do one thing well" is good advice about tools whose cost you pay whether or not you use them. That was every tool, for the whole history of the advice. It stops being automatically true the moment a capability can sit installed and dormant for a month at a cost of one line.
Under progressive disclosure, the marginal cost of the skill you never use collapses to roughly a sentence, while the marginal benefit stays whatever it's worth on the day you need it. When the cost of an unused capability approaches zero, "does this belong in the same tool" stops being the interesting question. The interesting question becomes whether the capability is worth having at all.
The far end of that range is amazon-returns-recovery, and it is the honest test of the argument, because it is the skill most obviously not a developer tool. It audited a real account and recovered $448.31 across three documented cases, including a $372.69 refund that had already been denied.
Under the old arithmetic that skill has no defense. It has nothing to do with code, it would be dead weight in the menu, and shipping it alongside a code reviewer would be a category error. Under the new one it costs a sentence until the day it pays for itself several hundred dollars over.
Look at why the returns case works and it isn't technical difficulty. Mechanically it's evidence gathering, policy research, and patient support correspondence. A person could do all of it. The reason a person often doesn't is that it's tedious, mildly adversarial, spread over days, and structured so that giving up is the path of least resistance. That describes a large category: subscription cancellations, warranty claims, billing disputes, rights paperwork, anything where the work is not hard but the process is designed to outlast you. These tasks were never worth building dedicated software for, because the software would cost more than the recovery. As a skill, one of them costs a description.
So the useful filter stops being "is this in scope for a dev tool" and becomes "is this a task I keep abandoning." Those are very different questions, and the second one has better answers.
The condition that holds it together
None of this licenses hoarding. Breadth is free in context and it is not free in routing: every added skill is one more candidate that could fire on the wrong request, which is exactly what NOT FOR boundaries exist to prevent. The two properties are load-bearing together and neither survives alone. Progressive disclosure without boundaries is a pack that costs nothing and picks wrong. Boundaries without progressive disclosure is a pack that picks correctly and costs too much to keep.
With both, the count stops being the thing to optimize. Seventy-one is just what happens when you stop deleting useful things to protect a budget you no longer spend.
These ideas started as three standalone essays: the memory tax, the NOT FOR line, and why breadth is free. The pack itself, all 71 skills, is at skills.suedeai.ai.