¿Qué es una "skill"?

Piensa una skill como un módulo de conocimiento que le sumas a un agente de IA. En lugar de explicarle desde cero cómo hacer una tarea cada vez que la necesitas (revisar código, redactar una ficha, preparar una QA), instalas una skill y el agente ya viene con las instrucciones para ejecutarla. Es lo que convierte a un asistente genérico en un especialista que sabe qué pasos seguir, qué reglas respetar y en qué formato entregar el resultado.

La palabra “skill” en este contexto es bastante reciente y suele aparecer junto a agentes como Claude Code, pero la idea no es nueva. Lo que cambia es que ese conocimiento queda empaquetado en un formato estándar que el agente lee, decide cuándo aplicar y combina con lo que ya sabe.

Le rinde a cualquier persona que use agentes de IA y quiera dejar de repetirse: equipos que estandarizan revisiones de código, redactores que aplican siempre la misma guía de estilo o personas que automatizan tareas repetitivas. Si te encuentras pegando el mismo bloque de instrucciones una y otra vez, ahí hay una skill esperando.

Por qué importa

Antes de las skills, cada conversación empezaba prácticamente desde cero. Si querías que el agente revisara titulares con un límite de sesenta caracteres y un tono concreto, tenías que explicarlo cada vez o mantener un documento al margen para copiar y pegar. El resultado dependía mucho de cuánto contexto recordaras dar ese día, y dos personas del mismo equipo podían acabar pidiendo lo mismo de formas distintas, con salidas también distintas.

Con skills instaladas, el conocimiento vive junto al agente y se activa cuando hace falta. Le dices “revisa los titulares de este artículo” y el agente sabe exactamente qué comprobar, en qué orden y qué proponer cuando algo no cumpla. El equipo entero gana consistencia: la misma tarea, hecha por personas distintas en momentos distintos, sigue las mismas reglas. Además, cuando descubres que una instrucción se queda corta, la corriges en un único sitio y todo el mundo se beneficia.

Cómo se usa en la práctica

El primer paso es entender que una skill, en su versión más simple, es un texto: una carpeta con un archivo de instrucciones que describe qué hace y cuándo aplicarla. No hace falta saber programar para escribir la primera; basta con redactar bien lo que ya le explicarías a una persona nueva del equipo.

El segundo paso es identificar qué skills ya trae o admite tu agente. En Claude Code viven en una carpeta del proyecto o del sistema y se cargan automáticamente. Hay catálogos comunitarios con cientos de skills listas para descargar, desde revisión de seguridad hasta generación de documentación.

Una vez instaladas, las skills pueden activarse de dos maneras. La primera es por invocación explícita, escribiendo su nombre con una sintaxis del tipo /nombre-de-la-skill. La segunda es automática: el agente detecta por el contexto que una skill aplica y la usa sin que tengas que nombrarla. Esta segunda vía exige que la descripción deje muy claro cuándo debe activarse.

El tercer paso es probar antes de crear. Instala una skill ajena parecida a lo que necesitas y observa cómo cambia el comportamiento del agente. Verás qué nivel de detalle funciona, qué errores comete cuando las instrucciones son ambiguas y qué tono adopta.

El cuarto paso llega cuando detectas una tarea repetitiva propia. Empieza con una skill mínima: nombre, descripción de cuándo usarla y pasos a seguir. Pruébala con casos reales, anota dónde el agente se desvía y refina la descripción. Una skill que crece poco a poco con casos vividos es mucho más sólida que una redactada de golpe.

Por último, conviene tratar las skills como cualquier otro código del equipo: versionarlas en Git, revisar cambios entre compañeros y documentar para qué sirve cada una. Cuando son tres o cuatro da igual; cuando llegas a treinta, la disciplina marca la diferencia.

Casos de uso reales

Un redactor que publica fichas de producto cada semana arma una skill que comprueba que cada ficha tenga título, subtítulo, tres beneficios concretos y una llamada a la acción. Antes tardaba veinte minutos en revisar a mano; ahora le pide al agente “revisa la ficha” y recibe en segundos la lista de lo que falta o lo que conviene reescribir.

Un equipo de desarrollo crea una skill para sus revisiones de pull request. Define qué patrones de código rechazar, qué archivos requieren tests obligatorios y qué convenciones de nombres aplicar. Cada miembro del equipo, al pedir una revisión, recibe el mismo tipo de comentarios. Las discusiones dejan de girar sobre criterios y se centran en el contenido real del cambio.

Una persona que estudia oposiciones monta una skill que, a partir de un tema, genera diez preguntas tipo test con cuatro opciones y solución comentada. La skill incluye instrucciones sobre el nivel de dificultad y el formato exacto que quiere para imprimir. Ya no negocia el formato en cada sesión: pide el tema y recibe la batería lista.

Errores comunes y cómo evitarlos

• Descripciones vagas. Si la skill no explica con claridad cuándo activarse, el agente la ignorará o la usará en momentos equivocados. Sé concreto con ejemplos del tipo “cuando el usuario pida X”.
• Skills enormes que lo abarcan todo. Una skill de cien instrucciones acaba siendo difícil de mantener y de razonar. Prefiere varias skills pequeñas y enfocadas.
• Meter datos sensibles. Claves, contraseñas o tokens dentro de una skill quedan registrados como instrucciones y se comparten con quien instale el paquete. Esos datos van siempre en variables de entorno.
• Asumir que una skill compensa malas instrucciones. Si los pasos están mal pensados, el agente los seguirá fielmente y producirá resultados malos a gran velocidad.
• No probar con casos reales antes de publicarla al equipo. Una skill que funciona con el ejemplo del autor puede fallar en el primer caso ajeno.
• Olvidarse de actualizar. Una skill escrita hace seis meses puede referirse a procesos que ya cambiaron. Revísalas con la misma cadencia que cualquier otro código.

Cuándo NO usarla

No tiene sentido crear una skill para algo que harás una sola vez en tu vida. En esos casos, explicarle al agente lo que necesitas en el momento es más rápido y más flexible. Tampoco conviene encorsetar tareas muy creativas en una skill rígida: si el valor está en explorar opciones distintas cada vez, una skill estricta corta más que ayuda.

Tampoco son la respuesta para problemas de capacidad del modelo. Si el agente no entiende un dominio complejo, ninguna skill lo arregla por arte de magia: lo que hace falta es contexto, datos o un modelo más adecuado.

Combinarla con otras herramientas

Las skills brillan cuando se apoyan en herramientas externas. Una skill que revisa pull requests gana mucho si el agente puede consultar el historial de Git; una de QA, si puede ejecutar tests; una de documentación, si puede leer la base de código. La skill aporta el “qué hacer”, las herramientas aportan el “con qué”.

También se combinan bien entre sí. Una skill de planificación puede dejar el terreno preparado para una de ejecución, y otra de revisión final puede comprobar el resultado. Diseñarlas pensando en este encadenamiento es lo que permite construir flujos de trabajo serios con agentes de IA.

Mini-ejercicio

Elige una tarea que repitas al menos una vez por semana cuando trabajas con un agente de IA. Puede ser revisar un correo antes de enviarlo, generar un resumen de una reunión o comprobar que un texto cumple cierta guía de estilo. Escribe en un archivo de texto plano una skill mínima con tres apartados: nombre, cuándo usarla y pasos a seguir, en no más de quince líneas. Después, pídele al agente que ejecute esa tarea con un caso real y compara el resultado con lo que habrías hecho a mano.

Sabrás que está bien si el resultado se parece a lo que tú habrías producido sin tener que darle más explicaciones al agente y si, al repetirlo con otro caso, vuelve a salir igual de bien.