Skills de IA: qué son y 5 ejemplos para mejorar tu agente

Los modelos de IA cada vez saben hacer más cosas: escriben código, navegan por internet, generan interfaces, razonan sobre datos. Y sin embargo, si trabajas a diario con un agente, seguro que reconoces esta sensación: le repites las mismas instrucciones una y otra vez.

Le explicas otra vez cómo quieres que diseñe una interfaz para que no parezca “hecha por IA”. Le recuerdas otra vez que antes de tocar un componente compruebe el rendimiento. Le dices otra vez que escriba primero el test y después el código. Le pides otra vez que abra el navegador y compruebe visualmente el resultado en lugar de darlo por bueno a ciegas.

El modelo no ha perdido esa capacidad entre una conversación y la siguiente — simplemente nunca la tuvo empaquetada. Sabe programar, sabe razonar, pero no sabe, por defecto, cómo quieres tú que se haga una tarea concreta.

Ahí es donde entran los skills.

Un agente de IA puede saber programar, navegar por internet o generar interfaces, pero un skill le da algo distinto: una forma concreta de hacer una tarea. No es una capacidad nueva en sentido estricto — es procedimiento, criterio y experiencia empaquetados para que el agente los reutilice cada vez que los necesita, sin que tengas que volver a explicarlos.

Qué es exactamente un skill de IA

El nombre no es casualidad, y es el atajo más rápido para entender el concepto: skill significa, literalmente, “habilidad”. Y la comparación no funciona solo porque la traducción coincida, sino porque la idea es la misma. Cuando decimos que alguien “tiene la habilidad de negociar” o “tiene skill para hablar en público”, no hablamos de un don innato, sino de una técnica concreta que esa persona aprendió en algún momento y que ahora sabe aplicar de forma consistente cada vez que la situación lo pide. Un skill de IA es exactamente eso trasladado a un agente: no es una capacidad nueva del modelo, es una forma aprendida y reutilizable de aplicar las capacidades que ya tiene — como una persona que ya sabía escribir y, además, aprendió a escribir de una manera determinada.

Hasta ahora, cuando hablamos de cómo trabajar con agentes solemos hablar de modelos, prompts, herramientas (tools) y protocolos como MCP. Los skills añaden una pieza distinta: conocimiento procedimental reutilizable.

Una forma sencilla de verlo:

• Un prompt le dice a la IA qué quieres hacer.
• Una tool le da a la IA la capacidad de hacer algo (llamar a una API, ejecutar un comando, tocar un archivo).
• Un skill le enseña una forma determinada de hacerlo.

La separación no es técnicamente absoluta — un skill puede incluir tools, y un prompt bien escrito puede acercarse a lo que hace un skill en una sola conversación —, pero como marco para entender el concepto funciona muy bien: el skill es el nivel donde se guarda el “cómo”, para no tener que reescribirlo cada vez.

En la práctica, un skill suele consistir en:

• Un archivo SKILL.md con las instrucciones que el agente carga cuando detecta que la tarea encaja con ese skill.
• Recursos adicionales: scripts, plantillas, documentos de referencia, ejemplos.
• Reglas sobre cuándo activarse y cuándo no.

Existen directorios de terceros que permiten buscar, instalar y gestionar skills mediante una CLI, de forma parecida a como se gestionan paquetes de npm o extensiones de un editor. Hay varios donde elegir; cuál usar es una decisión tuya, no algo que este artículo vaya a decidir por ti.

¿Vienen integrados en el modelo o hay que instalarlos?

Aquí conviene deshacer un malentendido habitual: ningún skill vive dentro del modelo. Ni los que publica Anthropic, ni los que publica OpenAI, ni los que publica un desarrollador independiente. Un skill es siempre una carpeta con un archivo SKILL.md que se carga en el contexto de la conversación cuando el agente detecta que encaja con la tarea — no forma parte del entrenamiento ni de los pesos del modelo. Lo que sí cambia de un skill a otro es quién lo publica y si tu agente lo trae ya disponible o tienes que instalarlo tú:

• Skills oficiales de primera parte. Anthropic mantiene su propio repositorio público, anthropics/skills , con skills como el propio Frontend Design del primer ejemplo, o los que usa Claude para generar documentos Word, PDF, PowerPoint o Excel. OpenAI mantiene el equivalente para Codex en openai/skills . Siguen sin estar “en el modelo”, pero en algunos productos (Claude.ai, por ejemplo) vienen activables de serie sin que tengas que tocar una terminal.
• Skills de terceros. La inmensa mayoría — incluidos cuatro de los cinco ejemplos de este artículo — los publican empresas o desarrolladores fuera de Anthropic y OpenAI: equipos como Vercel Labs, o desarrolladores independientes como Matt Pocock. Se instalan igual que los oficiales, solo que apuntando a otro repositorio.

Y hay un dato relevante si vienes de otros ecosistemas de IA: Agent Skills no es un formato exclusivo de Claude. Anthropic lo publicó como estándar abierto (especificación en agentskills.io ) y desde entonces lo han adoptado, entre otros, Codex CLI de OpenAI, Cursor, GitHub Copilot y Gemini CLI. En la práctica, el mismo SKILL.md que instalas para Claude Code suele funcionar sin cambios en Codex o en Cursor — cada agente simplemente lo busca en su propia carpeta (.claude/skills/, .cursor/skills/, ~/.agents/skills/ en Codex…).

Cómo se instalan, en general. En el fondo, instalar un skill es poner una carpeta con un SKILL.md dentro en el sitio que lee tu agente. La forma más directa es un git clone del repositorio del skill dentro de esa carpeta. También existen varias CLIs e instaladores de terceros que automatizan ese paso —descargan el skill desde su repositorio y lo copian al directorio correcto—; cuál usar depende del agente que tengas y de tus preferencias, así que no vamos a recomendar uno en concreto. Uno de los patrones de comando más habituales es este:

  npx skills add <usuario-u-organización>/<repositorio> --skill <nombre-del-skill>
    

En cada uno de los cinco ejemplos que siguen indicamos quién publica el skill y cómo se instala exactamente, para que sepas de dónde viene y puedas reproducirlo con el instalador que prefieras.

Por qué están empezando a ser importantes

Antes de entrar en los cinco ejemplos, merece la pena parar un momento en por qué esto no es una curiosidad técnica más.

Reutilización. No necesitas volver a explicar las mismas reglas en cada conversación nueva. Se instala una vez y queda disponible.

Especialización. Un agente generalista puede “ponerse” temporalmente el conocimiento de un especialista — un diseñador, un experto en rendimiento de React, un practicante estricto de TDD — sin que tengas que cambiar de modelo ni de herramienta.

Procedimientos reproducibles. La diferencia clave frente a un prompt suelto: el agente no solo sabe qué hacer, tiene instrucciones sobre cómo hacerlo, paso a paso, de forma consistente entre ejecuciones.

Vamos a los cinco ejemplos.

Los 5 skills que vamos a ver

No hemos elegido cinco skills de programación parecidos entre sí, sino cinco que cubren tareas muy distintas. Antes de entrar en el detalle de cada uno, aquí tienes un resumen rápido de qué hace cada uno:

Para cada uno seguimos la misma estructura: qué problema resuelve, qué cambia en el comportamiento del agente, un ejemplo práctico y qué deberías observar en el resultado.

1. Frontend Design — enseñar a la IA a diseñar mejor

Qué problema resuelve. Cualquiera que haya pedido a un agente “hazme una landing” reconoce el resultado típico: tarjetas con sombra suave, degradado azul-violeta, tipografía genérica, mucho espacio en blanco sin una razón clara. Es una interfaz correcta, pero intercambiable con cualquier otra generada de la misma forma.

Frontend Design ataca ese problema de frente.

Quién lo publica. Es un skill oficial de Anthropic, dentro de su repositorio público anthropics/skills. Se instala con npx skills add anthropics/skills --skill frontend-design.

Qué cambia cuando el agente lo usa. El skill obliga al agente a tomar decisiones conscientes antes de escribir una sola línea de CSS: dirección estética, paleta, tipografía, jerarquía, composición. En lugar de aplicar el patrón visual por defecto, el propio skill insiste en producir interfaces distintivas y evitar deliberadamente el aspecto de plantilla genérica.

Ejemplo práctico. Para que la comparación sea evidente, conviene elegir algo donde el agente tenga mucha libertad estética — no una landing de SaaS, sino un contenido con el que pueda expresar una dirección artística propia. El texto que le pides es exactamente el mismo en los dos casos; lo único que cambia es si el agente tiene o no criterio para convertirlo en algo con personalidad.

Primero, sin ningún skill:

“Crea una página web sobre la exploración de Marte que muestre las principales misiones que han llegado al planeta.”

Después, con el skill activo:

“Utiliza Frontend Design para crear una página web sobre la exploración de Marte que muestre las principales misiones que han llegado al planeta. Diseña una experiencia visual con personalidad propia y evita el aspecto típico de una web generada por IA.”

Qué deberías observar. No basta con que “se vea distinto” — hay que fijarse en si hay una decisión de diseño coherente detrás: una paleta limitada y con propósito, una tipografía que no sea la opción por defecto del framework, un layout con jerarquía visual clara en lugar de bloques apilados sin motivo. Si el segundo resultado solo cambió el color pero conserva la misma estructura genérica, el skill no ha aportado gran cosa.

2. Agent Browser — darle un navegador operativo al agente

Qué problema resuelve. Un agente que solo escribe código nunca comprueba lo que construye. Puede generar un menú responsive perfecto sobre el papel y no darse cuenta de que se rompe en móvil hasta que un humano lo mira.

Agent Browser da al agente acceso operativo a Chrome/Chromium: mantener sesión, navegar, inspeccionar el DOM, interactuar con elementos, extraer información y ejecutar acciones sobre páginas reales.

Quién lo publica. Es un skill de terceros: lo mantiene Vercel Labs, no Anthropic ni OpenAI, en el repositorio vercel-labs/agent-browser. Se instala con npx skills add vercel-labs/agent-browser --skill agent-browser.

Qué cambia cuando el agente lo usa. Aquí el salto es distinto al del skill anterior — no es una cuestión de criterio, es una cuestión de capacidad de verificación. El agente deja de limitarse a generar código y puede comprobar lo que ha construido, de la misma forma que lo haría una persona probando la web.

Ejemplo práctico. Aquí conviene evitar por completo “tu aplicación local” — el objetivo no es simular una tarea de QA profesional, sino comprobar, con algo que cualquier lector pueda reproducir en el momento, que el agente navega e interactúa de verdad:

“Abre Wikipedia, busca la película Interstellar y comprueba quién la dirigió, en qué año se estrenó y qué actores aparecen como protagonistas. Después, indícame los pasos que has seguido para encontrar la información.”

O, para forzar una navegación todavía más completa:

“Abre Wikipedia, busca ‘Sistema solar’, entra en el artículo de Marte desde esa página y dime cuál es el diámetro que aparece en su ficha.”

Este segundo prompt es el más interesante de los dos: aunque el modelo probablemente ya sabría de memoria el diámetro de Marte, el prompt le pide explícitamente una secuencia de navegación — abrir la página, localizar el enlace a Marte, hacer clic, encontrar el dato en la ficha —, así que puedes comprobar con más facilidad si de verdad la siguió o si se limitó a soltar el dato sin abrir nada.

Qué deberías observar. Lo interesante no es tanto el dato final sobre Marte, sino la secuencia que lo produjo: qué página abrió primero, qué enlace localizó y siguió, qué hizo cuando llegó al artículo de destino. Pídele que te describa esos pasos. Si la respuesta es genérica (“todo parece correcto” o directamente el dato sin explicar cómo llegó a él) sin detalle de la navegación real, probablemente el agente esté generando texto plausible — o incluso recordando el dato de su entrenamiento — en lugar de haber navegado de verdad.

3. Vercel React Best Practices — convertir conocimiento experto en instrucciones reutilizables

Qué problema resuelve. Escribir React que “funciona” es fácil. Escribir React que rinde bien —sin waterfalls de peticiones, sin re-renders innecesarios, con buen tamaño de bundle e hidratación correcta— exige un tipo de conocimiento que normalmente vive en la cabeza de un ingeniero senior, no en un prompt de una línea.

Este skill encapsula del orden de 70 reglas de optimización, organizadas por impacto: waterfalls, tamaño de bundle, rendimiento en servidor, re-renders, hidratación y optimizaciones de JavaScript.

Quién lo publica. También es de Vercel Labs, esta vez desde el repositorio vercel-labs/agent-skills. Se instala con npx skills add vercel-labs/agent-skills --skill react-best-practices.

Qué cambia cuando el agente lo usa. Este es el ejemplo más claro de que un skill no siempre añade una herramienta nueva — a veces añade criterio especializado. El agente sigue teniendo las mismas capacidades técnicas de antes (leer código, editarlo), pero ahora las aplica con el conocimiento acumulado de un equipo de rendimiento.

Ejemplo práctico. Partimos de una pequeña aplicación React que muestra una lista de Pokémon obtenida desde una API y permite marcarlos como favoritos — algo que cualquier lector visualiza de inmediato, en lugar de “un componente empresarial que necesita optimización”. El componente incluye, a propósito, varios problemas típicos: una petición de datos mal planteada, un filtrado que se repite en cada render, imágenes que se cargan innecesariamente, componentes hijos que se vuelven a renderizar sin motivo, e imports más grandes de lo necesario.

“Esta pequeña aplicación React muestra una lista de Pokémon y permite marcarlos como favoritos. Analiza el código utilizando Vercel React Best Practices. Identifica primero los problemas de rendimiento, ordénalos por impacto y después aplica las mejoras.”

Qué deberías observar. La señal de que el skill está aportando algo real es que el agente prioriza: no se limita a soltar una lista de cambios, sino que explica cuáles importan más y por qué (por ejemplo, eliminar un waterfall de red suele pesar más que un micro-ajuste de memoización). Si todas las sugerencias se presentan como igual de importantes, el skill no está usando su propio criterio de impacto.

4. TDD — enseñar al agente una metodología de trabajo

Qué problema resuelve. Pedirle a un agente “escribe tests para esto” suele producir tests que confirman lo que el código ya hace, no tests que definan lo que el código debería hacer. Es tan fácil de mal-generar como de mal-escribir a mano.

El skill de TDD de Matt Pocock no se limita a explicar qué es un test — define cómo debe abordar el agente el desarrollo: ciclo red → green → refactor, tests basados en comportamiento (no en implementación), trabajar contra interfaces públicas, vertical slicing de las funcionalidades.

Quién lo publica. Es un skill de terceros publicado por Matt Pocock (desarrollador independiente conocido en la comunidad de TypeScript), en el repositorio mattpocock/skills. Se instala con npx skills@latest add mattpocock/skills, eligiendo el skill de TDD entre los que ofrece el instalador; también existe como plugin instalable directamente desde Claude Code (/plugin install mattpocock-skills).

Qué cambia cuando el agente lo usa. Este es un tercer tipo de skill, distinto a los dos anteriores: no da criterio de diseño ni una herramienta nueva — modifica el proceso de razonamiento y ejecución del agente. El orden en el que hace las cosas cambia, no solo el resultado final.

Ejemplo práctico. La validación de emails es el ejemplo más habitual para TDD, pero tiene un problema: “qué es realmente un email válido” tiene demasiadas sutilezas discutibles, y eso distrae del proceso. Un conversor de números enteros a números romanos es más intuitivo — cualquier lector reconoce si 4 → IV está bien o mal sin pensarlo dos veces — y además crece por casos de forma muy natural, que es justo donde TDD se luce.

“Crea una función que convierta números enteros a números romanos utilizando TDD. No escribas la implementación completa de antemano: define un primer comportamiento, escribe un test que falle, implementa únicamente lo necesario para hacerlo pasar y continúa iterando con nuevos casos.”

El resultado esperado es una progresión visible, donde cada caso nuevo obliga a generalizar un poco más la implementación:

  // 1. RED — test que falla porque la función no existe todavía
  test("convierte 1 en I", () => {
    expect(toRoman(1)).toBe("I");
  });
    

  // 2. GREEN — implementación mínima que hace pasar el test
  function toRoman(num) {
    return "I";
  }
    

  // 3. REFACTOR — un caso nuevo obliga a generalizar, no a parchear
  test("convierte 4 en IV", () => {
    expect(toRoman(4)).toBe("IV");
  });
    

Y así sucesivamente, con cada caso forzando una regla nueva en la implementación: 2 → II, 5 → V, 9 → IX, 14 → XIV, 49 → XLIX. El lector puede seguir la progresión completa sin necesitar contexto adicional, y se ve con claridad cómo el ciclo RED → GREEN → REFACTOR hace evolucionar la función caso a caso.

Qué deberías observar. La prueba de que el skill está funcionando no es que “haya tests” — es el orden: el test debe escribirse y ejecutarse en rojo antes de que exista implementación. Si el agente escribe primero la función completa y después tests que simplemente la confirman, está simulando TDD, no aplicándolo. Fíjate también en si cada caso nuevo (el 4, el 9, el 49…) obliga realmente a tocar la implementación, o si el agente se limita a añadir tests que ya pasaban con el código anterior — eso sería una señal de que no está dejando que los tests dirijan el diseño.

5. Oil Motion — pasar de generar código a producir experiencias

Qué problema resuelve. Hacer que un elemento “se anime al hacer scroll” es sencillo. Coordinar generación de vídeo por IA, diseño de estados clave, limpieza de artefactos frame a frame, optimización de peso por dispositivo y mapeo de esa animación a la interacción real (scroll, ratón, drag, touch, orientación) ya no lo es.

No incluimos Oil Motion porque esté entre los skills más instalados —no tenemos datos que permitan afirmarlo—, sino porque es, con diferencia, el ejemplo más llamativo de hasta dónde puede llegar un workflow completo empaquetado en un skill. Y editorialmente nos interesaba más tener cinco ejemplos distintos entre sí que cinco entradas consecutivas de un mismo leaderboard.

Quién lo publica. Es un proyecto open source independiente, mantenido en oil-oil/oil-motion, sin relación con Anthropic, OpenAI ni Vercel. Es también el ejemplo con la instalación más informal de los cinco: no ofrece un comando de CLI, sino que su propia documentación indica simplemente pedirle al agente que instale el skill a partir de la URL del repositorio en GitHub.

Qué cambia cuando el agente lo usa. Aquí el skill no da criterio ni metodología: coordina un pipeline completo de varias etapas que normalmente requeriría varias herramientas distintas y varias personas. El agente pasa de “escribir el código de la animación” a producir la animación de principio a fin: imágenes de referencia → estados clave → vídeo generado por IA → limpieza frame a frame → optimización de assets → conexión con el control de scroll.

Ejemplo práctico. En lugar de “dos imágenes de un producto” — que suena a demo de ecommerce —, conviene un ejemplo conceptualmente sencillo, donde cualquiera entienda de inmediato la relación entre el scroll y lo que ve en pantalla:

“Utiliza Oil Motion para crear una experiencia en la que una flor cerrada vaya abriendo progresivamente sus pétalos a medida que hacemos scroll, hasta quedar completamente abierta al llegar al final de la página.”

La relación es instantánea: scroll arriba → capullo cerrado; scroll intermedio → apertura progresiva; final de la página → flor completamente abierta.

Qué deberías observar. La animación final es lo visible, pero lo que demuestra que el skill está haciendo bien su trabajo es lo que pasa antes: que fije primero los estados clave — capullo cerrado, apertura parcial, flor abierta — antes de generar vídeo continuo entre ellos, y que respete la distinción entre lo que genera la IA (el movimiento orgánico de los pétalos, la textura, la luz) y lo que controla el propio código (en qué punto exacto del scroll ocurre cada estado, la velocidad, los límites). Si la flor se ve bien pero pierde su forma o proporción entre un estado y el siguiente, el problema no está en el vídeo — está en que no se fijaron bien los estados clave.

No instales cualquier skill que encuentres

Esta sección no es opcional. Un skill no debería tratarse como un prompt suelto que has encontrado por ahí.

A diferencia de un prompt, un skill puede incluir instrucciones que se cargan automáticamente, ejecutar scripts, acceder a archivos del sistema y usar cualquier herramienta que el agente tenga disponible. Los propios responsables de los directorios de skills suelen ser claros al respecto: no pueden garantizar la calidad ni la seguridad de todo lo que se publica ahí y recomiendan revisarlo antes de instalarlo.

Y hay un motivo muy actual para no tratar esto como una advertencia genérica de manual: esta misma semana se ha informado de campañas que utilizaron skills maliciosos, con nombres typosquatted que imitan a los populares, para intentar robar credenciales y otros datos de los equipos donde se ejecutaban.

Antes de instalar un skill:

• Comprueba quién mantiene el repositorio.
• Lee el SKILL.md completo, no solo la descripción del directorio.
• Revisa los scripts que incluye, si los incluye.
• Comprueba qué permisos o accesos necesita para funcionar.
• Desconfía de nombres casi idénticos a los de skills populares.
• No lo instales únicamente porque tenga muchas descargas — eso te dice que es popular, no que sea seguro.

Cierre

No vamos a cerrar diciendo que los skills son “el futuro de los agentes de IA”. El cambio interesante no consiste simplemente en darle más capacidades a un modelo — de eso ya llevamos tiempo hablando con las tools y con MCP. Lo interesante es poder empaquetar experiencia, procedimientos y criterio para que un agente los reutilice exactamente cuando los necesita, sin que tengas que repetírselos cada vez.

Si quieres experimentar, no empieces instalando veinte skills a la vez. Elige una sola tarea que te permita ver claramente la diferencia entre el antes y el después — no tiene por qué ser una tarea que repitas a diario en tu trabajo: puede ser tan simple como pedirle a tu agente la misma página web con y sin Frontend Design, o hacer que navegue Wikipedia de verdad con Agent Browser. Instala un único skill, prueba el mismo prompt con y sin él, y compara el resultado. Esa comparación, más que cualquier lista de instalaciones, es la que te va a decir si merece la pena.

Happy Building!!