📊 Install count as a signal (and its pitfalls)
The most visible number on skills.sh is the install count. It’s tempting to treat it as a quality score — after all, find-skills has 1.802.925 and frontend-design has 488.299. But the catalog follows a brutal power law, and high install counts hide pitfalls.
The reality behind the numbers
From 39.366 skills in the catalog, 60.2% have fewer than 100 installs, and only 0.3% (131 skills) exceed 100k. The top 100 alone account for 43,7% of all installs.
Translation: install count is great for identifying the top of the pyramid, but terrible for comparing mid-tier skills — almost all of them are clustered near zero.
⚠️ The three pitfalls of install counts
- 1.Bias from those who arrived early: a skill published at the launch of skills.sh accumulated installs for months before competition existed. A high number may just reflect age, not merit.
- 2.Brand effect: a mediocre skill from a famous vendor gets more installs than an excellent one from an unknown author. People click the name they recognize.
- 3.Installs ≠ active use: installing takes one click. Lots of people install, try it once, and forget about it. The counter never goes back down.
Use installs like coarse filter (discard what has zero traction), never as the final decision. That’s what the other five signals are for.
🏛️ The source matters
Every skill lives in a repository owner/repo. That owner is a strong signal that's easy to assess: skills from vercel-labs, anthropics e microsoft carry institutional reputation, a review process, and a maintenance commitment. A random three-star repo does not.
✗ Random repo
- ✗Author with no history or contact
- ✗No guarantee of code review
- ✗It can disappear at any time
- ✗Risk of incorrect or malicious instructions
- ✗No one to respond to issues
✓ Vendor-backed source
- ✓Institutional reputation at stake
- ✓Review and CI process
- ✓Commitment to ongoing maintenance
- ✓Follows the official spec at agentskills.io
- ✓Answered issues, tagged releases
Reference sources you recognize on skills.sh:
anthropics/skills → frontend-design, skill-creator vercel-labs/agent-skills → vercel-react-best-practices, web-design-guidelines vercel-labs/skills → find-skills, agent-browser microsoft/azure-skills → azure-ai, azure-deploy, microsoft-foundry supabase/... → supabase-postgres-best-practices stripe/ai → stripe-best-practices
💡 Practical rule
For a critical area (database, deploy, payments), prefer the vendor’s own skill—the people who build the tool write its best practices. For general areas, the source matters less than the description.
✍️ The description as the #1 signal
If you could look at only one field before installing, it would be the description in the frontmatter. It’s not decoration—it’s the trigger the agent reads to decide whether the skill activates. A good description says WHAT the skill does AND WHEN use it. A clear description reveals an author who understood the problem.
✗ Vague description
Doesn’t say when to trigger. The agent will either under-trigger (never activate) or trigger at the wrong time. A sign of a poorly designed skill.
✓ Clear description
Says WHAT (React best practices) and WHEN (to generate/review/refactor). Triggers at the right time.
Why the description is the best predictor
In the progressive disclosure model, the description (along with the name) is the only thing that always stays in the agent’s context—about 100 words loaded all the time. If it’s well written, the rest of the skill tends to be, too.
It’s also where the most common problem lies: agents tend to sub-trigger, so good descriptions are a little "pushy," making it explicit when to activate.
💡 10-second test
Read only the description. Can you tell the exact situation in which the agent should use this skill? If so, that’s a good sign. If you need to open the SKILL.md body to understand it, the author failed at the most important field.
🎯 Scope and size
The best skill does one very. Atomic skills — with one clear responsibility — fit better into context, trigger more precisely, and compose with others. An “everything-about-X” skill tries to cover ten problems and solves none of them well. The ideal SKILL.md body is under 500 lines.
✗ "everything-about-X"
- ✗react-everything: components + tests + deploy + SEO
- ✗1,200-line body; the agent gets lost
- ✗Triggers in too many contexts and gets in the way
- ✗Hard to maintain and test
✓ Focused / atomic
- ✓react-best-practices: components/hooks only
- ✓Lean body, instructions the agent absorbs
- ✓Triggers only when relevant
- ✓Compose: react + typescript + a11y together
Composition > monolith — install several focused skills:
npx skills add anthropics/skills # frontend-design npx skills add vercel-labs/agent-skills # vercel-react-best-practices # resultado: agente frontend completo, cada skill testável em separado
💡 Discipline signal
A repo with several small, well-named skills suggests an author who understands composition. A repo with one huge skill that promises everything is a red flag—it probably has never been seriously tested.
🔄 Maintenance and Updates
A skill is living code. Frameworks change, and the spec itself evolves—and an abandoned skill starts giving the agent incorrect instructions. Since skills install by symlink (not a copy), the command npx skills update pulls improvements from the source automatically. But that only helps if the source is active.
Check the latest commit
A repo touched in recent weeks/months = alive. No commits for over a year in a fast-moving area (React, cloud) = a warning sign.
Look at the issues
Recent answered issues show an active maintainer. Dozens left open and ignored show a project adrift.
Keep everything to one command
Because the symlink points to the source, running npx skills update update all your skills at once. Make it a habit.
Keeping skills alive:
npx skills list # ver o que está instalado e de onde npx skills update # puxar melhorias de todas as fontes (symlink)
Active vs. abandoned — the summary
A maintained skill: recent commits, answered issues, tagged releases, a trusted source. An abandoned skill: last touched a long time ago, ignored issues, no clear owner. The first improves on its own through updates; the second grows stale along with you.
✅ Practical checklist before installing
Bring all the signals together in a seven-question plan. In less than two minutes, you can replace a hype-based decision with an evidence-based one.
The 7 checks (2 minutes)
- 1Description: say WHAT and WHEN in a 10-second read?
- 2Source: vendor-backed or an author with a track record, not a ghost repo?
- 3Installs: does it have real traction, or is it at absolute zero?
- 4Scope: focused and atomic, or "everything-about-X"?
- 5Maintenance: recent commits and answered issues?
- 6Content: Did you open SKILL.md, and does the body make sense (under 500 lines, of course)?
- 7Fit: does it fit YOUR stack and conventions, rather than a generic one?
✓ 5+ yeses
Install with confidence. Run npx skills add owner/repo and test it on a real task.
✗ 3 or fewer
Skip it. Look for an alternative from a trusted source—there’s almost always a better one in the same group.
💡 The check that saves the most time
Always read the description first. It eliminates 80% of candidates in seconds. Spend the other checks only on those that pass this filter.
✅ Module Summary
Next:
2.2 — 🏆 Showcase: The Best by Group — we applied these signals to six catalog groups and highlighted reference skills with real install counts and sources.