Más allá del hype: Ejecutamos 1416 skills de Claude para ver cuántas funcionan

Probablemente hayas visto las cifras: titulares y directorios que anuncian más de 23,000 skills de Claude disponibles para instalar. Esta cifra sugiere un ecosistema vasto y maduro de herramientas listas para aumentar las capacidades del modelo base. Es un número impresionante, pero plantea una pregunta técnica crucial: ¿qué significa realmente "disponible"? En la mayoría de los casos, significa que se encontró un manifiesto SKILL.md en un repositorio de código público. Es un recuento basado en el descubrimiento de archivos, no en la verificación funcional.

Este enfoque es simple, escalable y, en última instancia, engañoso. No dice nada sobre si una skill se instalará, se ejecutará sin errores o realizará su función anunciada de manera efectiva. No te informa si es un proyecto abandonado, una prueba de concepto rota o si incluso funciona peor que no usar ninguna skill.

En SkillProof, adoptamos un enfoque diferente. No contamos repositorios; instalamos y ejecutamos skills contra un conjunto estandarizado de tareas del mundo real. Este artículo presenta nuestros hallazgos tras probar 1416 skills. Es una respuesta directa y respaldada por datos a la pregunta de cuántas skills de código de Claude funcionan realmente, y un análisis sobre si los marketplaces de skills de Claude son fuentes fiables para herramientas listas para producción.

El problema de contar archivos

El problema fundamental de un recuento de más de 23,000 skills es que trata el descubrimiento como validación. Hacer scraping en plataformas como GitHub en busca de archivos SKILL.md es una tarea trivial. El número resultante sirve para un buen texto de marketing, pero es una métrica de vanidad que ignora la realidad del desarrollo de software.

Un repositorio que contiene un manifiesto de skill es solo un punto de partida. Es una afirmación, no una garantía. Cuando comenzamos nuestro proceso de probar skills sistemáticamente, identificamos rápidamente patrones de fallo comunes que el simple conteo de archivos ignora por completo:

• Manifiestos incompletos o malformados: Al archivo SKILL.md le faltan secciones requeridas, apunta a definiciones de herramientas inexistentes o es sintácticamente incorrecto. Es imposible instalar la skill sin una corrección manual.
• Dependencias rotas: El código de la skill depende de librerías externas que están desactualizadas, tienen breaking changes o ya no están disponibles. La instalación podría completarse, pero la skill fallará en tiempo de ejecución.
• Requisitos de entorno no documentados: Una skill puede requerir variables de entorno específicas, un servicio local en ejecución o tokens de autenticación que no se mencionan en su documentación. Una skill que probamos requería una versión específica de una base de datos ejecutándose en localhost:5433, un detalle descubierto solo al leer su código fuente en Python. Sin esto, no era funcional.
• Proyectos abandonados: El repositorio no ha sido actualizado en años. El código fue escrito para una versión anterior de la API de Claude y ya no es compatible.
• "Prompt-como-Skill": Algunas skills no contienen herramientas reales. Son simplemente prompts elaborados empaquetados en formato de skill. Aunque potencialmente útiles, no representan una extensión funcional de las capacidades del modelo y a menudo no funcionan mejor que un prompt bien escrito.

El simple hecho de contar estos repositorios infla el tamaño y la salud percibidos del ecosistema. Crea un panorama donde encontrar una herramienta funcional y fiable es una cuestión de prueba y error. Nuestra metodología de prueba fue diseñada específicamente para eliminar este ruido, haciendo de la ejecución la medida principal de la validez de una skill.

Nuestros hallazgos: una mirada sobria a la cifra real

Instalamos e intentamos ejecutar 1416 skills obtenidas de varios directorios y repositorios públicos. Cada skill fue sometida a una serie de pruebas automatizadas diseñadas para invocar su funcionalidad principal. Los resultados ofrecen una imagen mucho más clara del estado del ecosistema.

De las 1416 skills que probamos, solo 889 (63%) pasaron nuestras pruebas de ejecución iniciales sin ninguna intervención manual.

Aquí hay un desglose completo de nuestros hallazgos:

Estado	Cantidad	Porcentaje del total
Pasa (Funciona sin configuración)	889	63%
Requiere configuración (Necesita config. manual)	467	33%
Falla (Funciona peor que el modelo base)	60	4%
Total probado	1416	100%

Analicemos qué significa cada una de estas categorías para un desarrollador que intenta usar estas herramientas.

Pasa (63%): Estas skills se instalaron correctamente y se ejecutaron en nuestro banco de pruebas sin errores. Esta es la "cifra real del directorio de skills de Claude" de nuestra muestra: el subconjunto de skills que son inmediatamente utilizables. Esta es la línea base de lo que un usuario debería esperar de cualquier skill listada en un directorio. Sin embargo, como discutiremos, "funcionar" no significa automáticamente "alta calidad".

Requiere configuración (33%): Esta es una categoría significativa y a menudo pasada por alto. Estas 467 skills no estaban rotas, pero no eran plug-and-play. Las razones comunes incluían:

• Requerir que las claves de API se establezcan manualmente como variables de entorno.
• Necesitar conectarse a una base de datos o servicio de terceros proporcionado por el usuario.
• Depender de archivos locales o configuraciones del sistema que no se especificaron en el SKILL.md.

Por ejemplo, una skill para interactuar con una API de gestión de proyectos es inútil sin una clave de API y una URL de endpoint. Estas skills no son fallos, pero listarlas sin instrucciones de configuración claras y directas es un mal servicio para el usuario. Un directorio que no diferencia entre una skill que "Pasa" y una que "Requiere configuración" presenta una imagen poco fiable.

Falla (4%): Esta es la categoría más preocupante. Estas 60 skills no solo no lograron realizar su función, sino que produjeron resultados que fueron activamente peores que usar el modelo base sin ninguna skill instalada. Esto sucede cuando la lógica de una skill es defectuosa, causando que el modelo:

• Se quede atascado en un bucle, intentando llamar repetidamente a una herramienta rota.
• Alucine el uso de herramientas que no existen en su propia definición.
• Interprete mal la intención del usuario y aplique una herramienta incorrectamente, lo que lleva a errores o resultados sin sentido.

Una skill que probamos estaba diseñada para formatear fragmentos de código. Cuando se le dio una función simple de Python, intentó llamar a una herramienta format_javascript, falló y devolvió un mensaje de error. La misma solicitud a Claude sin skills habría resultado en un fragmento de Python correctamente formateado. Estas 60 skills no son solo inútiles; son perjudiciales. Ningún directorio de buena reputación debería listarlas sin una advertencia clara. Publicamos estos fallos porque son una parte crítica de los datos.

Más allá de la ejecución: ¿Qué define la calidad de una skill?

Los datos muestran que aproximadamente dos de cada tres skills que encuentres funcionarán. Pero esto solo responde la primera parte de la pregunta. La segunda parte, más importante, es sobre la calidad. La "calidad de las 23000 skills de Claude" no es una cuestión de cantidad, sino de rendimiento.

Una skill que se ejecuta pero realiza su tarea de manera deficiente es poco mejor que una que no se ejecuta en absoluto. Es por eso que, después de que una skill pasa nuestra prueba de ejecución inicial, la puntuamos en una escala de 1 a 10 según su rendimiento en una batería de tareas del mundo real. Nuestra rúbrica de puntuación completa se detalla en nuestra metodología, pero se centra en algunos principios clave:

• Fiabilidad: ¿La skill tiene éxito consistentemente en su tarea declarada? ¿Usa las herramientas correctas para el trabajo?
• Precisión: ¿El resultado es correcto y libre de errores? Si interactúa con una API, ¿maneja los datos correctamente?
• Eficiencia: ¿Resuelve el problema sin pasos o llamadas a herramientas innecesarias?
• Manejo elegante de fallos: Cuando encuentra un caso extremo o una entrada no válida, ¿devuelve un mensaje de error útil o se bloquea?

La diferencia entre una skill de alta puntuación y una de baja puntuación es abismal.

Una skill de alta puntuación, como una herramienta de infraestructura en la nube bien construida, interpretará correctamente una solicitud como "listar todas las instancias EC2 en us-east-1", usará su herramienta list_instances con el parámetro region correcto, manejará la respuesta paginada de la API y presentará al usuario una lista limpia y precisa.

Una skill de baja puntuación podría tener el mismo objetivo pero fallar en la ejecución. Por ejemplo, otra herramienta en la nube que probamos ignoraba la región especificada y listaba instancias de su región predeterminada. "Funcionó" en el sentido de que no se bloqueó, pero produjo la respuesta incorrecta, lo que la hace poco fiable.

Las 60 skills que puntuaron por debajo del modelo base representan el nivel más bajo. Son una demostración tangible de que una skill mal diseñada es peor que ninguna skill. Este es un dato crítico que se pierde cuando los directorios priorizan el tamaño del catálogo sobre el rendimiento verificado.

Encontrando la señal en el ruido

La disparidad entre las más de 23,000 skills anunciadas y nuestra tasa de aprobación del 63% en las pruebas resalta el problema principal: el ecosistema está lleno de ruido. El verdadero número de skills funcionales y de alta calidad es una pequeña fracción del total anunciado.

Probar manualmente cada skill que encuentras no es una solución práctica para ningún desarrollador. El proceso consume mucho tiempo y recursos. Nuestra prueba de 1416 skills requirió un esfuerzo de ingeniería significativo para construir el arnés de pruebas (test harness) y recursos de cómputo sustanciales para ejecutar las evaluaciones. Esta es precisamente la razón por la que la mayoría de los directorios no lo hacen. Es mucho más fácil ejecutar un scraper y publicar un número grande y no verificado.

El objetivo de un directorio de skills debería ser filtrar la señal del ruido. Debería hacer el trabajo de validación en nombre del usuario. Esto significa:

1. Ejecutar cada skill: Una skill no está "verificada" hasta que se ha ejecutado.
2. Probar la corrección: La skill debe ser evaluada contra tareas reales para ver si funciona como se anuncia.
3. Publicar los fallos: Un directorio que no te muestra lo que falló está ocultando la mitad de la historia. Los datos de fallos son tan importantes como los datos de éxito.

Al probar skills en docenas de categorías, desde análisis de datos hasta desarrollo web, construimos un mapa de lo que funciona, lo que necesita ajustes y lo que se debe evitar por completo.

Este enfoque basado en datos es la única forma fiable de responder a la pregunta, "¿son fiables los marketplaces de skills de Claude?" La respuesta es: solo son tan fiables como su proceso de verificación. Un marketplace que es solo una lista de repositorios no es una fuente fiable para herramientas profesionales. Un directorio que ejecuta, prueba y puntúa cada entrada proporciona una base de confianza.

Lecturas relacionadas: cuántas superan realmente el rendimiento base · nuestra metodología de prueba.

Hemos hecho este trabajo en todo nuestro catálogo. Las 889 skills que pasaron nuestras pruebas están disponibles para consultar, con sus puntuaciones y un veredicto sobre su rendimiento. Para los desarrolladores que necesitan un conjunto central de herramientas probadas, ofrecemos un paquete curado de nuestras skills mejor valoradas por $10, todas con la garantía de que se ejecutarán y funcionarán como se espera. Esta es nuestra solución al problema de la señal y el ruido: un subconjunto pequeño, verificado y de alta calidad del masivo y no verificado ecosistema público.