Las skills de un agente de IA se parecen más a un manual de trabajo que a un plug-in. Le dicen qué revisar primero, qué pasos no puede saltarse y cuándo debe devolver una decisión a una persona. Una lista enorme de herramientas impresiona. Una sola instrucción bien escrita puede aportar más si evita que el agente repita el mismo error caro.
Para comprobar qué colecciones están llamando la atención, comparé sus estrellas de GitHub el 12 de agosto de 2026. No es una lista de descargas ni una nota de calidad. Algunos repositorios contienen unos pocos archivos; otros instalan un entorno entero. Aquí las estrellas solo sirven como rastro de interés.
1. obra/superpowers: obligar al agente a parar antes de programar
Superpowers es la propuesta más estricta de la lista. Lleva al agente por descubrimiento, diseño, división de tareas, implementación, pruebas y revisión. Lo importante no es la cantidad de skills. Una regla de arranque elige la adecuada y, si la tarea encaja, impide ignorarla.
Es útil cuando el agente convierte una petición ambigua en código sin hacer preguntas. Para una corrección de dos líneas puede resultar excesivo. Yo lo reservaría para tareas donde una suposición equivocada tenga un coste real.
2. affaan-m/ECC: un entorno completo, con su carga incluida
Everything Claude Code, o ECC, es más una distribución que un paquete de skills. Reúne agentes, comandos, reglas, hooks y skills para planificación, desarrollo, revisión, pruebas, investigación y seguridad. Permite adoptar un flujo ya montado en lugar de construirlo desde cero.
El coste aparece en el contexto permanente. Instalarlo todo obliga al agente a revisar muchas reglas en cada sesión. Empezaría con uno o dos comandos, mediría el consumo y solo añadiría otra pieza cuando aparezca una carencia concreta.
3. mattpocock/skills: preguntar mejor antes de responder
La colección de Matt Pocock es pequeña y fácil de leer. Su patrón más conocido, grill-me, funciona como una entrevista: el agente hace una pregunta cada vez, guarda las decisiones y sigue preguntando hasta que el plan se puede ejecutar.
Su valor está en cambiar el comportamiento, no en producir otra plantilla bonita. Hay un detalle práctico: el archivo de la skill y el comando que la activa pueden estar separados. Antes de copiar una carpeta conviene comprobar cuál es el punto de entrada.
4. multica-ai/andrej-karpathy-skills: principios conocidos, en formato corto
Este repositorio resume consejos asociados a Andrej Karpathy: pensar antes de programar, mantener la solución simple, corregir la causa y dejar un resultado verificable. El archivo es corto y no intenta imponer un segundo framework sobre el proyecto.
El nombre requiere contexto. Karpathy no es propietario ni colaborador del repositorio. Es una interpretación comunitaria de comentarios públicos, no un producto oficial ni una recomendación suya.
5. anthropics/skills: la referencia oficial
El repositorio oficial de Anthropic incluye ejemplos para documentos, hojas de cálculo, presentaciones, PDF, frontend y creación de skills. Incluso si se utiliza otro agente, merece la pena estudiar cómo combina instrucciones con scripts, ejemplos y pasos de evaluación.
La licencia debe revisarse carpeta por carpeta. Hay componentes abiertos y skills documentales source-available. Estar publicado en GitHub no significa que todo pueda redistribuirse o monetizarse con las mismas condiciones.
La característica común no es la potencia, sino el control
Estos proyectos no se limitan a dar más herramientas al agente. Le ponen frenos. Superpowers evita saltar directamente al código, ECC intenta hacer repetible el proceso, grill-me mantiene abiertas las preguntas, el documento inspirado en Karpathy nombra errores recurrentes y los ejemplos de Anthropic unen instrucciones, pruebas y artefactos.
Por eso no instalaría los cinco. Las reglas solapadas consumen contexto, pueden contradecirse y dificultan saber qué cambió el resultado. Empezaría por un error repetido, una skill pequeña y una tarea que pueda ejecutar antes y después. Si baja el tiempo de revisión, se queda. Si solo produce respuestas más largas, la quitaría.
Fuentes
Lo que comprobaría antes de instalar cualquiera
Las estrellas de GitHub sirven para detectar dónde se concentra la atención, pero no demuestran que un skill vaya a mejorar nuestro trabajo. Un repositorio puede crecer por su nombre, por abarcar muchos casos o por tener una comunidad muy activa. Nada de eso garantiza que las instrucciones sean precisas, encajen con el proyecto o reduzcan el tiempo de revisión.
Yo empezaría con un solo skill en un proyecto desechable. Antes de darle acceso a un repositorio real, comprobaría qué archivos lee, qué comandos propone, dónde guarda los cambios y si pide permiso antes de una acción difícil de revertir. Esa prueba corta suele contar más que otra hora leyendo el README. También deja claras las diferencias: Superpowers impone un proceso, ECC ofrece un entorno amplio, la colección de Matt Pocock trabaja hábitos concretos, el documento de Karpathy reúne criterios de programación y el repositorio de Anthropic aporta flujos orientados a documentos y diseño.
La prueba necesita una referencia. Haría la misma tarea una vez sin el skill y otra con él. Después anotaría cuántas preguntas de aclaración fueron necesarias, cuántas correcciones quedaron tras la primera revisión y cuánto tardó la verificación final. También miraría el consumo de tokens. Un contexto inicial largo puede compensar en un proyecto de varios días y ser una carga innecesaria en un cambio de quince minutos.
Los permisos requieren una revisión aparte. Si el skill ejecuta comandos, controla el navegador o llama a servicios externos, no debería recibir más acceso del que exige la tarea. Conviene leer los scripts de instalación, comprobar las dependencias y decidir cómo se revisarán las actualizaciones. En un equipo, guardaría en control de versiones los archivos elegidos en vez de instalar automáticamente una rama que cambia a diario.
La licencia es otro filtro práctico. Que el repositorio sea público no significa que todas sus plantillas, recursos o servicios conectados tengan las mismas condiciones. Esto importa cuando el resultado se vende, se entrega a clientes o se incorpora a una plataforma interna.
Usaría este ranking para elegir candidatos, no ganadores. Mantendría un skill si evita un error repetido, acorta la revisión o conserva una decisión que el equipo tendría que explicar una y otra vez. Lo quitaría si pelea con las reglas del proyecto, oculta decisiones importantes o convierte una tarea pequeña en una ceremonia. El mejor skill no suele ser el que tiene la cifra más grande, sino el conjunto mínimo de instrucciones que justifica el contexto que consume.
Fuentes y referencias
- obra/superpowersGitHub
- affaan-m/ECCGitHub
- mattpocock/skillsGitHub
- multica-ai/andrej-karpathy-skillsGitHub
- anthropics/skillsGitHub
