Agent skills: cómo un equipo de desarrollo convierte su conocimiento en skills de IA

Las skills son, ahora mismo, la forma más barata que tiene un equipo de que un agente de IA trabaje con su conocimiento en lugar de con el conocimiento medio de internet. No porque sean una tecnología sofisticada, que no lo son, sino porque obligan a escribir lo que el equipo sabe en un formato que el agente consulta solo cuando lo necesita.

Esa es la tesis de esta serie. El resto son matices: cuándo una skill aporta algo y cuándo es documentación disfrazada, cómo se estructura para que se active cuando toca, cómo se prueba, qué riesgos trae instalar las de otros y qué cambia cuando el conocimiento que empaquetas es el de una empresa entera.

Qué es una skill y por qué ya no es cosa de una sola herramienta

Una skill es una carpeta con un fichero SKILL.md. Ese fichero tiene una cabecera con un nombre y una descripción, y un cuerpo en Markdown con instrucciones. Opcionalmente, la carpeta incluye ficheros de referencia, scripts y otros recursos.

Lo que la diferencia de un prompt largo es cómo se carga. El agente solo ve al principio el nombre y la descripción de cada skill disponible. Cuando una petición encaja con una descripción, lee el SKILL.md; y solo si la tarea lo requiere, abre las referencias que ese fichero le indica. Puedes tener decenas de skills instaladas sin llenar el contexto, porque casi todo su contenido no se lee nunca en una conversación concreta.

Anthropic publicó el formato como estándar abierto en agentskills.io a finales de 2025, y desde entonces lo han adoptado herramientas de otros fabricantes: Codex de OpenAI, GitHub Copilot, Gemini CLI, Cursor o VS Code, entre otras. Para un equipo, esto cambia el cálculo. Escribir una skill ya no es apostar por un proveedor; es escribir un fichero Markdown que varios agentes saben leer.

Lo he comprobado con un caso propio. La skill de Illuminate que hemos desarrollado en eLearning Media, que ayuda a generar y validar SQL para Blackboard Data, se empaqueta como plugin de Codex. El SKILL.md es el mismo que leería Claude Code; lo único específico de cada herramienta es el empaquetado alrededor. De momento no hay enlace de instalación porque ChatGPT no acepta skills nuevas; cuando lo haga, o cuando esté en un repositorio público, la información estará en Consultas SQL para Blackboard.

Si vienes de MCP, la diferencia está desarrollada en MCP vs Skills. En una frase: MCP le da al agente herramientas para actuar sobre sistemas, y una skill le da criterio sobre cómo hacer un trabajo.

Cuándo una skill compensa

No todo conocimiento merece una skill. Si el modelo ya hace bien una tarea genérica, como resumir un documento o escribir un test unitario corriente, una skill que se lo explique solo añade texto que leer.

Una skill compensa cuando contiene algo que el modelo no puede adivinar. En la de Illuminate es evidente: el esquema de Blackboard Data no está en los datos de entrenamiento con el detalle necesario, y un modelo sin ayuda inventa tablas y columnas con total seguridad. La skill trae el esquema, el índice de campos válidos, las relaciones candidatas entre tablas y una regla explícita de no inventar nada que no esté ahí. Su valor está en acotar el terreno; SQL el modelo ya sabe escribirlo.

En un equipo de desarrollo pasa lo mismo con las convenciones internas, las librerías propias, los procedimientos de despliegue o la forma de estructurar un proyecto. Es conocimiento que existe, que suele estar repartido entre la cabeza de la gente y documentos que nadie lee, y que ningún modelo trae de serie. Ya escribí sobre ese uso en skills como documentación viva de un equipo, centrado en qué meter y qué no meter en una skill.

El error contrario también existe, y lo hemos cometido bastantes veces: crear skills para procesos de empresa que lo que necesitaban era estar definidos o automatizados. Una skill encima de un proceso confuso no lo aclara, y una skill para una secuencia fija hace con un agente lo que haría mejor un script. Cómo distinguir los tres casos está en cuándo no crear una skill.

Cómo se construye una skill que funciona

Escribir el SKILL.md lleva diez minutos. Que el agente lo use cuando debe y no lo use cuando no, bastante más.

El primer problema es la activación, y depende casi por completo de la descripción. Una descripción vaga hace que la skill no se active nunca o que se active donde no pinta nada. El segundo es la estructura: una skill que lo mete todo en un fichero obliga al agente a leer cientos de líneas para cualquier pregunta. El patrón que mejor nos funciona es un SKILL.md corto que actúa como router y le dice al agente qué referencia abrir para cada necesidad. Todo esto, con la skill de Illuminate como ejemplo que evoluciona versión a versión, está en cómo crear una skill que funcione.

Antes de escribir hay que decidir de dónde sale el contenido. Pocas skills se escriben desde cero; casi todas destilan algo que ya existe: un Custom GPT, un CLAUDE.md, la documentación de un fabricante, la operativa de alguien que lleva años haciendo un proceso. La de Illuminate nació de un Custom GPT, y uno de sus ficheros todavía lo dice. Ese proceso de destilar, y lo que se pierde por el camino, está en cómo destilar el conocimiento de un equipo en skills.

De skills sueltas a un plugin de equipo

Cuando un equipo pasa de una skill a varias, aparece la pregunta de cómo distribuirlas y mantenerlas. En mi equipo usamos un plugin interno de Claude Code con skills y comandos, distribuido a través de un marketplace del departamento. Su contenido no lo puedo publicar, pero sí cómo se reparte el trabajo entre las piezas que puede tener un plugin.

Las skills dan criterio y el agente decide cuándo usarlas. Los comandos encadenan pasos en un orden fijo cuando una persona los invoca. Los hooks se ejecutan siempre, sin que el agente lo decida: si una regla no se puede saltar, como pasar el linter después de editar un fichero, no debería depender de que el agente se acuerde. Esa separación, con ejemplos, está en skills, comandos y hooks en un plugin de equipo.

Probar una skill

Una skill sin pruebas es una suposición sobre cómo se va a comportar el modelo. Hay dos cosas que comprobar: si se activa con las peticiones que le corresponden y no con las demás, y si el resultado con la skill es mejor que sin ella.

La segunda comprobación es la que suele faltar. Una comprobación que pasa igual con skill y sin skill no demuestra nada, y una skill cuyo resultado no mejora la línea base sobra, por bien escrita que esté. Cómo diseñar esas evals, qué herramientas hay y qué hacer cuando cambia el modelo está en cómo probar una skill.

Lo que traes cuando instalas la skill de otro

Una skill es texto que el agente obedece, y a veces viene con scripts. Instalar una de un marketplace sin leerla equivale a ejecutar instrucciones de un desconocido con los permisos de tu sesión. Los análisis publicados este año sobre skills de registros públicos encuentran problemas de seguridad en una parte relevante de ellas, y la inyección escondida en ficheros de referencia es el patrón más habitual.

Qué revisar, cómo se esconde una inyección y por qué la revisión no sustituye a limitar permisos está en seguridad de skills de terceros. El problema de fondo es el mismo que con MCP, que traté en MCP en una empresa: el problema son los permisos.

Más allá del código: procesos y empresa

Las skills empezaron como algo de desarrolladores, pero el patrón sirve para cualquier conocimiento procedimental. Dos artículos de la serie salen del editor.

El primero aplica skills y comandos a un problema clásico: modernizar una aplicación legacy. Pedirle a un agente que reescriba un sistema antiguo produce código que compila y pierde reglas de negocio por el camino. Nuestro método invierte el orden: primero se documenta el sistema y alguien del equipo valida esa documentación, y solo después se escribe la versión nueva. Está en modernizar código legacy con IA.

El segundo es más amplio: qué significa digitalizar una empresa con IA cuando los datos de adopción en España dicen cosas muy distintas según quién pregunte, y por dónde empezaría yo. En el trabajo usamos cada vez menos n8n porque con IA un script sale en minutos y, dockerizado, se despliega como cualquier servicio. Ese cambio de coste es, para mí, más importante que cualquier agente autónomo. Está en digitalizar una empresa con IA.

Por dónde empezar

Si tu equipo no tiene ninguna skill, no empezaría por un plugin ni por un marketplace. Empezaría por una sola skill sobre el conocimiento que más veces explicáis a mano: la librería interna que todo el mundo usa mal, el procedimiento de despliegue que solo conocen dos personas o el esquema de datos sobre el que el modelo inventa tablas. Con la descripción bien escrita, un router si el contenido lo pide y tres o cuatro evals para saber si aporta algo.

Si esa primera skill funciona, el resto de la serie te sirve para escalar. Si no funciona, lo más probable es que el problema esté en la descripción o en que el modelo ya sabía hacer esa tarea sin ayuda, y ambas cosas se ven en las evals antes que en producción.