Hay una tendencia muy clara ahora mismo: instalar skills para todo. Y tiene sentido, porque los skills pueden mejorar la salida del modelo, ahorrar tokens y servirte para explicarle a tu agente cómo trabajas para no repetírselo cada vez. El problema es la otra tendencia: instalar packs enormes con decenas de skills que nadie lee, que llenan tu proyecto de archivos Markdown y que, en vez de ayudar, pueden estar limitando a tu modelo.
En este artículo te cuento cómo uso yo los skills, por qué me llamó tanto la atención este tema y qué te recomiendo hacer si estás empezando a programar con agentes como Claude Code o Codex.
Famosos por subir archivos Markdown
Hace unos días vi este post de Markus Eisele que decía, más o menos: "todavía no me entra en la cabeza que la gente se haga famosa escribiendo archivos Markdown, llamándolos skills de ingeniería y subiéndolos a GitHub".
Se refería a proyectos como gstack de Garry Tan, pstack de Cursor o los skills de Matt Pocock (@mattpocockuk). Si no los conoces, son conjuntos de skills que traen toda una metodología de desarrollo, y seguramente has visto a algún creador de contenido o a medio Twitter recomendándolos.
Antes, en GitHub se subían aplicaciones, librerías o hasta el código de un sistema operativo como Linux. Hoy aparecen repositorios que son, básicamente, carpetas de Markdown, porque de eso se trata un skill.
Las estrellas no miden la utilidad
Y estos repos tienen una cantidad enorme de estrellas. Al momento de escribir esto, gstack tiene unas 135.000, los skills de Matt Pocock pasan de 279.000 (más del doble) y Superpowers, otro conjunto gigante de skills para hacer brainstorming, ejecutar planes o revisar código, ronda las 296.000.
Eso refleja popularidad, pero no utilidad. Hay proyectos muy populares en estrellas que casi nadie usa en el día a día, y proyectos mucho mejor trabajados que no tienen tanto apoyo.
La ingeniería convertida en skills
Hace unas semanas también se volvió viral el video de lauren (@poteto) sobre cómo envió 2.500 pull requests a producción en un mes (en el video dije 2000, pero el post habla de 2.500). Son recomendaciones para que tus agentes hagan más trabajo: reglas, guías de diseño, skills y contexto.
Es decir, hoy "hablar de ingeniería" se traduce muchas veces en cómo ordenar tus ideas y cómo escribirlas en skills, porque el modelo hace todo o gran parte del trabajo.
Los skills no son un truco
La idea del skill es buena. Lo que veo continuamente es que mucha gente busca skills como si fueran un truco para que el agente responda mejor, y por eso estos repositorios no resultan tan útiles como uno esperaría.
El modelo inteligente es el que hace la mayor parte del trabajo. Un skill es solo una guía sencilla para que haga un trabajo concreto como tú quieres. Si instalas un pack entero y das por hecho que tu agente "mejoró" porque cargó un montón de archivos Markdown, probablemente te estás engañando.
Los modelos mejoran más rápido que los workflows
Los modelos actuales son tan buenos que un skill que cargas sin leer puede estar empeorando la salida o limitando al modelo. Y no lo digo solo yo. Dax, el creador de OpenCode, lo resumió así en este post: con los LLM pasa algo raro, los modelos mejoran más rápido que la gente que los trastea; cuando ve workflows y configuraciones personalizadas, casi todos están resolviendo problemas que ya no existen, y quien usa Codex "vainilla" probablemente está más cerca del estado del arte.
He visto proyectos con tantos archivos y restricciones que el modelo era incapaz de hacer una modificación simple. Quien los armó quería rendimiento, escalabilidad y seguridad, y terminó llenando el proyecto de skills que ni siquiera entiende.
Es el bucle de siempre: al principio no sabes nada, pides algo simple y funciona. Luego descubres MCPs, subagentes, custom harness, archivos de contexto… y tu entorno se vuelve cada vez más complejo sin que el resultado mejore. Al final empiezas a quitar cosas y el modelo responde mejor, simplemente porque dejas de restringirlo.
Cómo uso yo los skills en Claude Code
Yo uso mucho Claude Code y, si listo mis skills, verás que tengo varios. La diferencia es que sé qué hace cada uno, o al menos lo uso a menudo. Esto importa porque, cuando pides algo, algunos se cargan solos.
Mis recomendaciones:
- No instales packs enteros. Si un skill te sirve, instala ese. Y ni siquiera hace falta instalarlo: puedes copiar la idea. Mi skill
fx-question-meestá inspirado en elgrill-mede Matt Pocock (uno de los más instalados en skills.sh), pero simplificado para que no pregunte infinitamente. - Instala por proyecto lo que vas a necesitar. Si necesito testing, instalo el de Playwright CLI; si necesito revisión de código, uso uno de revisión que publicó Cursor.
- Léelos. Abre el editor y lee el skill. Aunque no lo entiendas todo, al menos sabrás qué se está cargando. Y si está en inglés, tradúcelo: al final son instrucciones.
La descripción decide cuándo se carga
Mucha gente cree que un skill solo se usa cuando lo llamas por su nombre. No es así. Según la documentación de Anthropic, Claude carga al arrancar el nombre y la descripción de cada skill (unos 100 tokens por skill) y, cuando tu petición encaja con esa descripción, lee el SKILL.md completo y lo mete en el contexto.
Por eso la descripción es lo más importante del skill. Y por eso instalar decenas de skills tiene dos riesgos:
- Que se activen cuando no los necesitas y ocupen contexto.
- Que no sirvan para la tarea que estás haciendo y el modelo los siga como si sí.
Crea tus propios skills
Si estás empezando y sabes algo de desarrollo, crea tus propios skills. Y si los usas para algo que no es código, también, siempre que sepas qué hacen y qué pasos siguen.
En mi caso, a los skills que creo les pongo un prefijo para reconocerlos. No son nada sorprendentes: son guías sencillas. Por ejemplo, como trabajo mucho con Docker y tengo tantos proyectos que no sé qué puertos están libres, mi skill de Docker le dice que primero verifique el puerto, que no use volúmenes (yo trabajo con backups) y que busque la última imagen del servicio.
Puedes pedirle a la IA que te genere uno, pero ojo: suele devolverte un texto gigante con ejemplos de código y demás, y si no lo lees, estás yendo a ciegas. Además, si cargas muchas restricciones escritas para un modelo anterior, cuando se actualice tu modelo puede que siga esas reglas al pie de la letra en lugar de aprovechar lo que ya sabe hacer mejor.
Cuidado con instalar skills al azar
La última recomendación: no instales skills al azar. Un skill popular, con muchas descargas y estrellas, da algo más de confianza, pero uno desconocido puede ejecutar código o meter un prompt injection para que el modelo filtre información o la envíe a otro sitio.
La propia documentación de Anthropic lo dice claro: usa skills solo de fuentes de confianza y, si vienen de otro lado, revísalos a fondo (el SKILL.md, los scripts y los recursos), tratándolos como cuando instalas software.
Conclusión
Si bien llenar tu entorno de skills puede parecer favorable, ten solo los que necesitas y borra el resto:
- ✅ Las estrellas en GitHub no miden la utilidad de un pack de skills.
- ✅ Los skills se cargan solos a partir de su descripción, así que cada uno que instalas cuenta.
- ✅ Crea los tuyos, cortos y leídos, y deja que el modelo actual haga su trabajo.
Y tú, ¿qué skills usas de verdad en tus proyectos? Te leo en los comentarios del video en YouTube.