We've evaluated 600+ agent skills at Skill123. Every one was scored in isolation — one SKILL.md, one rubric. Nobody uses them that way. This post is about what breaks when you install ten.
Every skill directory evaluates skills as individuals. That's the right way to compare them, but it's not how they're used. A real user has a loadout: a dozen skills across documents, code, and research, all live at once.
And loadouts fail in ways individual skills never do. We can't see user sessions, but we see the residue in 600+ evaluated skills: descriptions that collide, capabilities that overlap, defaults that contradict. Four patterns show up over and over.
1. Trigger collisions
Two skills claim the same trigger. The classic case in our directory: code-review (9.3) and code-reviewer (9.4) — both fire on "review this code," with different methodologies. Neither author intended a coin flip. The agent picks one anyway.
Rule: one trigger-owner per job type. If two skills both claim "review my code," keep whichever methodology matches how you work and remove the other. Ambiguity at trigger time is where loadouts go wrong first.
2. Layered overlaps that look like alternatives
One author shipped a ten-skill family around a programmatic video framework — a router skill, a composition contract, animation, media, a CLI loop. Nine of the ten score 8.7+. But the family has a designed hierarchy: the specialists assume the contract skill is loaded. Install "just the animation one" and you've installed a dependency-free skill that was never meant to run alone.
Compare the Office trio — docx, xlsx, pptx, all 9.7+ — which genuinely don't reference each other. That's the cleaner shape: alternatives that don't secretly depend on siblings.
Rule: families install whole. If a skill's description references a sibling, the sibling is a dependency, not an option.
3. Contradictory defaults
Two skills that each encode a "standard" that disagrees. We see this most between writing-adjacent skills: a tone skill enforcing concise defaults versus a brand skill enforcing elaborate ones. Each is fine alone. Together, the agent satisfies whichever fired last — and your output oscillates.
Rule: defaults come from one skill per output type. One voice owner for prose, one formatting owner per document type. Everything else in the loadout should be capability (what to make), not policy (how it should read).
4. The stale skill
Skills that reference moving targets — model IDs, API versions, CLI flags — decay. The reference skill for the Anthropic SDK scores 9.8 because its author maintains it; the same file frozen six months ago would score materially lower on content accuracy. Model IDs don't age gracefully.
Rule: for anything version-sensitive, check the skill's update date before trusting specifics. A 9.8 from last year may be a 7.5 today.
The loadout checklist
- One trigger-owner per job type
- Families installed whole
- One policy-owner per output type
- Version-sensitive skills checked against their update date
Four rules, and in our experience they eliminate most loadout failures before they happen.
The deeper point: score is a property of the skill, but usefulness is a property of the set. Pick your job types first, then take the best trigger-owner for each. Ten well-chosen skills beat forty installed on spec.
We score every skill on six dimensions with written rationale at skill123.me — 600+ evaluated, rankings updated as we re-test. The full interference post includes the specific skills referenced above.
Top comments (0)