Hoy hay skills para casi todo y mucha gente habla de cuáles instalar, pero muy pocos explican cómo crear los tuyos. Yo uso skills a diario para escribir código, revisarlo, desplegar, redactar artículos, generar infografías y documentos o llenar formularios. Casi cualquier tarea que quiero automatizar termina convertida en un skill.
No hay truco mágico: el secreto para que tu IA se comporte como quieres es tener claro qué le pides. En este artículo te dejo los 7 tips que aplico, con los ejemplos del video, para que tus skills sean fáciles de entender, de mantener y de reutilizar con cualquier agente.
Qué es un skill (en una línea)
Según el estándar abierto Agent Skills, un skill es una carpeta con un archivo SKILL.md: un frontmatter con name y description y, debajo, las instrucciones en Markdown. Opcionalmente puede llevar las carpetas scripts/, references/ y assets/. Al arrancar, el agente solo lee el nombre y la descripción de cada skill. El resto se carga cuando el skill se activa.
Lo soportan Claude Code, Codex, Cursor, Gemini CLI, OpenCode y muchos más. Un skill que escribes hoy en Claude Code lo puedes llevar mañana a otro agente.
1. Hazlos simples y entendibles
El error más común es pedirle a la IA que genere el skill completo. En el video le pedí a Claude: "crea un skill para que cada vez que se implemente un cambio hagas un test con el navegador y, si pasa, hagas un commit y luego un push". El resultado fue un archivo enorme para unos pocos pasos fáciles de entender. La pregunta es: ¿vas a poder mantener eso con el tiempo?
La solución es pedirle que lo reduzca:
Reduce el skill a solo los pasos que te he pedido, no expliques cosas obvias
y haz el skill de forma genérica, sin código específico.
Evita textos redundantes.
En unos segundos queda un skill corto (verificar-y-desplegar) con tres pasos: probar el cambio en el navegador, hacer commit y hacer push a la rama actual. Si mañana quieres un cuarto paso, como actualizar el README, lo añades con tus palabras o los reordenas sin miedo a romper nada.
En el paso del navegador puedes elegir la herramienta: Playwright CLI, Chrome DevTools MCP o Claude in Chrome.
Un matiz: en el video quité la línea "úsalo cuando el usuario invoque el skill" porque era redundante, y lo era. Pero el estándar sí recomienda que la description diga qué hace y cuándo usarlo, porque es lo único que el agente lee al arrancar para decidir si lo activa. Lo que sobra es lo obvio, no el "cuándo".
2. Un skill para cada cosa
Es mejor tener varios skills pequeños que un mega-skill que lo hace todo. En el ejemplo, en vez de seguir ampliando el primero, le pedí skills separados: code-review-lite, uno para diagramas de arquitectura y otro para comprobar producción. Y como verificar-y-desplegar hacía dos cosas, lo dividí en dos: browser-test y ship (enviar el código).
Cada uno tiene un nombre que dice lo que hace y lo puedes mejorar por separado. Los skills no son para alguien que estudió diez años: son para cualquiera que sepa explicar su proceso.
Un skill puede llamar a otro, pero si quieres que sean realmente modulares, evita encadenarlos dentro de cada uno. Si necesitas el flujo completo, crea otro skill que los orqueste. En el video creé prueba-completa:
---
name: prueba-completa
description: Comprueba toda una nueva versión del proyecto.
---
1. Haz un code review con code-review-lite.
2. Haz un browser-test.
3. Envía el código con ship.
4. Genera un diagrama de arquitectura.
Con /prueba-completa se ejecuta todo y cada pieza sigue funcionando por su cuenta.
3. Úsalos para automatizar tus procesos
Si una tarea la repites y ya tienes claros los pasos, no necesitas un programa complicado: basta con un skill. Y la forma más divertida de crearlo es enseñándole.
En el video le dije: "voy a crear un skill, pero primero te voy a enseñar los pasos; solo anota mis pasos puntuales". Luego se los di uno a uno:
- Abre el navegador y ve a Hacker News.
- Filtra solo las noticias relacionadas con IA y agentes.
- Crea un reporte en HTML explicando cada noticia en términos simples.
El agente controla el navegador, abre cada noticia, la lee y arma el reporte. Al final le pedí que creara el skill con una regla más: "siempre te voy a pasar una página distinta". Así nació reporte-noticias, que ahora solo necesita la URL.
¿Por qué no hacer web scraping? Porque tendrías que escribir un scraper para cada sitio, y el modelo ya sabe leer cualquier página. Para un uso personal, un skill es más genérico. Lo mismo vale si todos los días llenas un formulario, actualizas un Excel o entras en un sitio a comprobar algo.
Si creas un skill nuevo y no aparece, Claude Code tiene /reload-skills. Normalmente ni hace falta, porque detecta los cambios en las carpetas de skills sin reiniciar. Solo lo necesitas si esa carpeta no existía al empezar la sesión.
4. Dales herramientas, pero con acceso controlado
Esto no es solo de skills, pero casi. Un agente no está para responder preguntas: está para hacer acciones. Ya escribe código porque trae herramientas para eso. Si le pides editar audio o video, o descargar un video de YouTube, te dirá que no puede, pero esas herramientas existen:
- Audio y video: FFmpeg convierte formatos, corta y extrae pistas desde la terminal. Un matiz sobre lo que dije en el video: Audacity no "se basa" en FFmpeg, sino que lo usa como librería opcional para importar y exportar más formatos.
- Edición de video: hay MCP comunitarios para DaVinci Resolve y After Effects. No son oficiales de Blackmagic ni de Adobe, y el de DaVinci necesita la versión Studio para el control externo.
- Descargar videos: usa yt-dlp, que está activo. youtube-dl, el que tenía en mis notas, no publica una versión desde 2021.
Con herramientas y pasos claros puedes armar flujos completos, como un skill editar-video: descargar, procesar con FFmpeg y cortar en DaVinci. Todavía no es perfecto, pero cada vez se acerca más. Para flujos de oficina (descargar un Excel, editarlo, subirlo a otra plataforma) puede que no necesites algo como n8n. Eso sí, n8n da siempre el mismo resultado y un skill lo interpreta un modelo: para lo crítico, lo determinista sigue ganando.
Y sin magia: usa cuentas separadas para tu IA, revisa qué permisos tiene y amplíalos solo a medida que la conozcas mejor.
5. Incluye ejemplos y plantillas
Si añades a code-review-lite un paso "genera un reporte en HTML", cada sesión te dará un HTML distinto. Si quieres que siempre se vea igual, usa la carpeta assets/ del estándar, pensada para plantillas y recursos.
En el video le pedí: "crea tres plantillas HTML para reportes y guárdalas dentro de code-review-lite/assets". Después, en una sesión nueva, pedí un reporte del CLI y el agente tomó una de esas plantillas sin que le explicara el diseño. Incluso puedes nombrarlas y referenciarlas en el skill: "si es backend, usa reporte-tabla.html; si es frontend, usa…".
Un buen ejemplo de entrada y salida enseña el formato mejor que tres párrafos de explicación.
6. Ponles límites explícitos
Define qué no debe hacer cada skill. Al tenerlos separados, cada uno lleva sus propias restricciones. En el skill de ship, por ejemplo:
## Restricciones
- Nunca hagas merge a main ni push a main.
- Haz push a la rama actual y luego crea un pull request.
- Pregunta antes de hacer push.
Esto también se lo puedes pedir a la IA, pero a veces prefiero escribirlo yo para que el archivo no crezca de más. Al final, un skill es solo un archivo Markdown: lo puedes editar en VS Code, en un bloc de notas o en Orca.
7. Guárdalos, versiónalos e itera
Los skills de un proyecto viven en .claude/skills/ y viajan con el código en cada commit. Pero ¿qué pasa con los globales, los de ~/.claude/skills/ o ~/.codex/?
Yo no los guardo directamente ahí. Tengo dos repos en mi carpeta de usuario:
- dotfiles (público): configuraciones de Claude Code, Herdr, Hyprland, i3, Neovim u OBS, y los skills que más uso para programar (commits, reviews, Docker, navegador…).
- dotfiles-private (repo privado): skills para tareas fuera de la programación, como la generación de contenido.
El instalador enlaza cada skill en ~/.claude/skills y en ~/.agents/skills. Cuando edito un skill, el cambio queda en Git y llega a todos mis agentes y máquinas. Si quieres montarlo, lo explico paso a paso en este video sobre dotfiles para agentes.
Y para crearlos, empieza copiando tu propio proceso manual, sin inventarlos desde cero. Ajústalos con el uso: cuando fallen, corrige solo esa parte. Un skill madura con el uso, no nace perfecto.
Conclusión
Todo el mundo habla de skills y de cómo instalarlos, pero el valor real está en escribir los tuyos: cortos, uno por tarea, con las herramientas adecuadas, con ejemplos, con límites claros y versionados. Así puedes automatizar desde un code review hasta un reporte diario de noticias sin montar una aplicación.
¿Qué tarea de tu día a día te gustaría convertir en un skill?