📊 Cantidad de instalaciones como señal (y sus trampas)
El número más visible en skills.sh es la cantidad de instalaciones. Es tentador tratarlo como una calificación de calidad; al fin y al cabo, find-skills tiene 1.802.925 y frontend-design tiene 488.299. Pero el catálogo sigue una brutal ley de potencia, y las cifras altas de installs esconden trampas.
La realidad de los números
De las 39.366 skills del catálogo, el 60,2% tiene menos de 100 instalaciones y solo 0,3% (131 skills) superan los 100k. Las 100 principales concentran por sí solas 43,7% de todas las instalaciones.
Traducción: el install count es excelente para identificar la cima de la pirámide, pero pésimo para comparar skills medianas: casi todas están agrupadas cerca de cero.
⚠️ Las tres trampas del número de instalaciones
- 1.Sesgo de quienes llegaron temprano: una skill publicada en el lanzamiento de skills.sh acumuló instalaciones durante meses antes de que existiera la competencia. Un número alto puede deberse solo a la antigüedad, no al mérito.
- 2.Efecto de marca: una skill mediocre de un proveedor famoso consigue más instalaciones que una excelente de un autor desconocido. La gente hace clic en el nombre que reconoce.
- 3.Instalaciones ≠ uso activo: instalar es cuestión de un clic. Mucha gente instala, prueba una vez y se olvida. El contador nunca retrocede.
Usa instalaciones como filtro general (descartar lo que no tiene tracción), nunca como decisión final. Para eso sirven las otras cinco señales.
🏛️ La fuente importa
Toda skill vive en un repositorio owner/repo. Ese owner es una señal clara y fácil de evaluar: las skills de vercel-labs, anthropics e microsoft aportan reputación institucional, un proceso de revisión y un compromiso de mantenimiento. Un repo aleatorio con tres estrellas, no.
✗ Repo aleatorio
- ✗Autor sin historial ni contacto
- ✗Sin garantía de revisión de código
- ✗Puede desaparecer en cualquier momento
- ✗Riesgo de instrucciones incorrectas o maliciosas
- ✗Nadie que responda los issues
✓ Fuente respaldada por el proveedor
- ✓La reputación institucional está en juego
- ✓Proceso de revisión y CI
- ✓Compromiso de mantenimiento continuo
- ✓Sigue la spec oficial de agentskills.io
- ✓Issues respondidas, releases publicadas
Fuentes de referencia que reconoces en 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
💡 Regla práctica
Para un área crítica (base de datos, deploy, pagos), prefiere la skill del propio vendor: quien crea la herramienta escribe sus mejores prácticas. Para áreas genéricas, la fuente importa menos que la description.
✍️ La description como señal n.º 1
Si solo pudieras mirar un campo antes de instalar, sería la description del frontmatter. No es decoración: es el activador que el agente lee para decidir si la skill se activa. Una buena description dice QUÉ la skill hace Y CUÁNDO usarla. Una description clara revela a un autor que entendió el problema.
✗ Descripción vaga
No indica cuándo activarla. El agente la activará menos de lo debido (nunca) o fuera de momento. Es señal de una skill mal pensada.
✓ Description clara
Dice QUÉ (buenas prácticas de React) y CUÁNDO (generar/revisar/refactorizar). Se activa en el momento adecuado.
Por qué la description es el mejor predictor
En el modelo de progressive disclosure, la description (junto con el name) es lo único que siempre permanece en el contexto del agente: unas 100 palabras cargadas todo el tiempo. Si está bien escrita, todo lo demás de la skill suele estarlo también.
También es donde reside el problema más común: los agentes tienden a subdisparar, así que las buenas descriptions son un poco "pushy" y dejan claro cuándo activarlas.
💡 Prueba de 10 segundos
Lee solo la description. ¿Puedes decir en qué situación exacta debería usar el agente esta skill? Si puedes, es buena señal. Si necesitas abrir el cuerpo del SKILL.md para entenderlo, el autor falló en el campo más importante.
🎯 Alcance y tamaño
La mejor skill hace una cosa bien. Las skills atómicas —con una responsabilidad clara— se asimilan mejor en el contexto, se activan con precisión y se combinan con otras. Una skill «todo sobre X» intenta abarcar diez problemas y no resuelve bien ninguno. Lo ideal es que el cuerpo del SKILL.md tenga menos de 500 líneas.
✗ "todo-sobre-X"
- ✗react-everything: componentes + pruebas + deploy + SEO
- ✗Cuerpo de 1.200 líneas; el agente se pierde
- ✗Se activa en demasiados contextos, molesta
- ✗Difícil de mantener y probar
✓ Enfocada / atómica
- ✓react-best-practices: solo componentes/hooks
- ✓Cuerpo conciso, con instrucciones que el agente asimila
- ✓Se activa solo cuando es relevante
- ✓Se combinan: react + typescript + a11y
Composición > monolito — instala varias especializadas:
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
💡 Señal de disciplina
Un repo con varias skills pequeñas y bien nombradas indica que su autor entiende la composición. Un repo con una única skill gigante que promete hacerlo todo es una señal de alerta: probablemente nunca se probó en serio.
🔄 Mantenimiento y actualización
Una skill es código vivo. Los frameworks cambian, la propia spec evoluciona y una skill abandonada empieza a darle instrucciones incorrectas al agente. Como las skills se instalan por symlink (no una copia), el comando npx skills update obtiene automáticamente las mejoras de la fuente. Pero eso solo ayuda si la fuente sigue activa.
Revisa el último commit
Repo actualizado en las últimas semanas/meses = activo. Sin commits desde hace más de un año en un área que cambia rápido (React, cloud) = señal de alerta.
Revisa las issues
Las issues recientes con respuestas muestran que hay un mantenedor presente. Decenas abiertas e ignoradas muestran un proyecto a la deriva.
Mantén todo en un solo comando
Como el symlink apunta a la fuente, ejecutar npx skills update actualiza todas tus skills de una vez. Haz de esto un hábito.
Cómo mantener las skills vigentes:
npx skills list # ver o que está instalado e de onde npx skills update # puxar melhorias de todas as fontes (symlink)
Activa vs. abandonada: el resumen
Skill activa: commits recientes, issues respondidos, versiones publicadas y una fuente confiable. Skill abandonada: último cambio de hace mucho tiempo, issues ignorados y sin un responsable claro. La primera mejora por sí sola con update; la segunda envejece contigo.
✅ Lista práctica antes de instalar
Reúne todas las señales en una guía de siete preguntas. En menos de dos minutos, cambia una decisión basada en hype por una basada en evidencia.
Los 7 checks (2 minutos)
- 1Description: ¿dice QUÉ y CUÁNDO en una lectura de 10 segundos?
- 2Fuente: ¿respaldada por un proveedor o creada por un autor con trayectoria, y no un repositorio fantasma?
- 3Instalaciones: ¿tiene tracción real o es cero absoluto?
- 4Alcance: ¿enfocada y atómica, o «todo sobre X»?
- 5Mantenimiento: ¿commits recientes e issues respondidas?
- 6Contenido: ¿abriste el SKILL.md y el cuerpo tiene sentido (<500 líneas, claro)?
- 7Compatibilidad: ¿encaja con TU stack y tus convenciones, y no con algo genérico?
✓ 5+ sí
Instala con confianza. Ejecuta npx skills add owner/repo y pruébala en una tarea real.
✗ 3 o menos
Omítelo. Busca una alternativa de una fuente confiable: casi siempre hay una mejor en el mismo grupo.
💡 La verificación que más tiempo ahorra
Lee siempre la description primero. Elimina el 80% de las candidatas en segundos. Solo dedica las otras comprobaciones a las que superen este filtro.
✅ Resumen del módulo
Próximo:
2.2 — 🏆 Muestra: las mejores por grupo — aplicamos estas señales a seis grupos del catálogo y mostramos las skills de referencia con instalaciones y fuentes reales.