Pull the Google Trends breakout list for Claude Code skills this week and the demand does not match the discourse.
The loud posts are still about the 132-agent mega-stack: dozens of subagents, a wall of MCP servers, nested orchestration, a CLAUDE.md the length of a short novel. But the skills that are actually breaking out in search, and the ones developers are actually installing, lean the other way. They are about restraint. About taste. About making the model do less, more predictably.
That gap between what gets talked about and what gets installed is the whole story.
What developers are actually installing
Here is the shortlist from the live catalog, refreshed daily from skills.sh, GitHub and MCP registries and ranked by real installs. Every one of these makes the output better and quieter rather than handing the agent more power.
- caveman - forces blunt, literal, no-hedging output; strips the filler and the "as an AI" throat-clearing. Skillselion · GitHub - 343k installs.
- ui-ux-pro-max - a taste layer for interfaces: spacing, hierarchy, restraint, the things a model gets wrong by default. Skillselion · GitHub - 263k installs.
- design-taste-frontend - opinionated frontend taste so generated UI stops looking generated. Skillselion · GitHub - 250k installs.
- improve (shadcn) - a tight "make this better" pass that refines what you already have instead of regenerating it. Skillselion · GitHub - 22.4k installs.
- karpathy-guidelines - Andrej Karpathy's coding taste, distilled into a skill the agent can follow. Skillselion · GitHub - 17.8k installs.
- ponytail - minimal-code discipline: ship the smallest change that works, not the cleverest one. Skillselion · GitHub - 14.2k installs.
- stop-slop - a filter that cuts the AI writing tells: the hedges, the rule-of-three, the "as an AI" tic. Skillselion · GitHub - 6.9k installs.
None of these add a tool. None of these spawn a subagent. Every one narrows what the model is allowed to do and how it is allowed to sound.
Why the quiet skills are winning
A more powerful setup gives you more surface area to go wrong. Another MCP server is another routing decision the agent can fumble. Another subagent is another context window to keep coherent. The marginal agent you bolt on rarely earns the coordination cost.
caveman is the clearest case. It adds no capability at all. What it does is govern the output, and 343k developers decided that governor was worth more to them than another agent. Most people, most of the time, will make the same call, and the install numbers say a lot of them already have.
There is a search signal underneath this too. When someone types "taste" or "stop slop" or "minimal" into Google, they are not looking for capability. They already have capability. They are looking for a governor on it. The breakout terms are the tell: the demand is for judgment, not horsepower.
Two things worth taking away
- The install-ranked list disagrees with the discourse. The viral setups optimize for how impressive a screenshot looks. The installs optimize for what people keep using on Tuesday. When those two diverge, trust the installs.
- Taste is now a distributable artifact. A year ago good taste lived in a senior engineer's head. Now it ships as a skill file that 250k people can install. That is a genuinely new thing, and it is the most underrated category in the ecosystem right now.
If you are stacking agents to feel productive, try deleting most of them and adding one taste skill instead. The install-ranked catalog says you will not miss the agents.
Skillselion is an independent directory of Claude Code, Codex and Cursor skills, MCP servers and marketplaces, ranked by real installs. Not affiliated with Anthropic, OpenAI or Cursor.
Top comments (8)
Taste is a good word for the missing layer.
A more powerful skill is not automatically a better one. Developers want routines that know when to act, when to stay quiet, what evidence to gather, and what a good result should feel like in that specific workflow.
The best skills are opinionated in the useful sense: they reduce decisions without hiding judgment.
"Reduce decisions without hiding judgment" is a better definition of skill taste than anything in my article. What the install data adds is that the discipline shows up at the routing layer first: the minimal skills that keep winning have narrow, honest trigger descriptions, so they fire only inside the workflow they understand and stay silent everywhere else. Knowing when to stay quiet is mostly trigger-scope hygiene. The interesting tension is your "what a good result should feel like" criterion, because that is the one thing a SKILL.md cannot fully encode: it can carry checklists and success criteria, but the felt sense of "this is right for THIS codebase" still comes from whoever wrote the skill having shipped real work in that shape. Which is probably why this week's breakout searches are people's names: developers trying to import that judgment by proxy.
Yes, the trigger layer is where taste becomes operational. A skill can have great internal guidance and still be bad if it fires in the wrong moments. The best ones feel almost boring from the outside: narrow promise, clear silence outside scope, and enough examples to show what a good result should feel like without pretending every repo is the same.
Boring from the outside is a good acceptance test for a skill. Examples do double duty there: they calibrate the output, and they narrow the trigger, since a description plus three concrete examples reads as a much more specific promise than the description alone. The opposite failure exists too: a skill so narrow it never fires and quietly rots. I have no clean heuristic for that boundary yet beyond watching per-skill fire counts in session logs over a few weeks.
Per-skill fire counts over time feels like the right first instrument. I would probably pair it with a small “missed trigger” review too, because silence can mean either “not needed” or “the agent never recognized the moment.” The boundary is hard because both failures look quiet from the outside.
The way out of the two-quiet-failures problem is giving silence a denominator. Fire counts alone are a numerator. If you also log candidate moments, even with a crude net like "the request contained this skill's domain vocabulary," the ratio splits the cases: candidates with no fire pile up when the trigger is broken, and stay near zero when the skill genuinely was not needed. The net can be sloppy on precision because a human only reviews a handful of misses, but it has to be generous on recall or broken triggers keep hiding in the unsampled part.
The other cheap instrument is a canary set: five fixed prompts the skill must fire on, replayed after every description edit. Most missed-trigger regressions I have seen came from someone tightening a description for readability, and a canary catches that the same day instead of three quiet weeks later.
Giving silence a shape is the right move. A skill that never fires, a skill that should have fired, and a skill that fired but did nothing are three different product problems. Treating them as one metric hides the fix.
A denominator for silence is exactly the missing piece. Candidate moments do not have to be perfect to be useful; they just need to reveal whether the skill had chances to fire. That changes quiet from ambiguous absence into something you can debug.