El 22 de octubre de 2026, Anthropic cedió Agent Skills, el formato con el que se dan instrucciones y procedimientos a un agente de IA, a la Agentic AI Foundation, que depende de la Linux Foundation. Para un equipo de desarrollo, la noticia tiene dos lados, y conviene leer los dos.
La idea que defiende este insight: si el formato es abierto, el método de tu equipo (cómo especifica, cómo revisa, qué comprueba) se puede escribir una vez y llevar a cualquier agente. Pero por la misma puerta entra lo que escriben otros: una skill de un registro público es una dependencia, y se instala con los mismos criterios que un paquete de npm o de PyPI.
Qué ha cambiado
Hasta ahora, Agent Skills era un formato creado por Anthropic que otras herramientas habían adoptado. Desde el 22 de octubre, lo mantienen ingenieros de Anthropic, Google, OpenAI y otras empresas a título individual, dentro de la Agentic AI Foundation, con el compromiso de mantenerlo «abierto, impulsado por la comunidad y neutral respecto a los fabricantes». Tres cifras del anuncio, que da la propia Anthropic:
Riesgo Las cifras de adopción son de Anthropic, que es parte interesada. Que una herramienta haya integrado el formato no garantiza que admita todas sus partes: compruébalo en la documentación de la tuya.
Qué es una skill
Una skill es una carpeta con un archivo SKILL.md. Ese archivo lleva unos metadatos (como mínimo, nombre y descripción) y las instrucciones para hacer una tarea concreta. La carpeta puede incluir también scripts, documentación de referencia y plantillas. El agente lee al arrancar solo el nombre y la descripción de cada skill, y carga las instrucciones completas cuando una tarea encaja con ella.
La especificación lo explica así: las skills empaquetan conocimiento de procedimiento y contexto del equipo y de la empresa en «carpetas portables y bajo control de versiones». Y lo resume en una frase: construir una skill una vez y usarla en cualquier agente compatible.
Lo que gana tu equipo
Lo que de verdad distingue a un equipo que trabaja bien con agentes no es la herramienta, sino lo que tiene escrito: cómo se redacta una especificación, qué criterios de aceptación lleva, qué se comprueba antes de un merge, qué decisiones de arquitectura no puede adivinar el agente. Es lo que contábamos sobre Spec-Driven Development (SDD), el desarrollo guiado por especificaciones, en las plantillas de SDD ya son gratis: la plantilla la da cualquiera; el método es del equipo.
Con un formato abierto, ese método deja de estar atado a un fabricante. Una skill que explica cómo especifica tu equipo en SDD sirve igual si mañana parte del equipo usa otro agente. Lo mismo vale para las decisiones de arquitectura y para las instrucciones compartidas del equipo: si viven en skills dentro del repositorio, se versionan, se revisan y se quedan cuando cambia la herramienta. En onext no te atamos a un único fabricante, y este es uno de los motivos por los que el método debe vivir en el repositorio del equipo.
Lo que tu equipo tiene que controlar
El otro lado es el mismo hecho visto desde fuera. Un formato que funciona en más de 70 plataformas y tiene registros públicos con miles de skills es también una cadena de suministro. Una skill de terceros puede llevar instrucciones que el agente va a seguir y scripts que va a ejecutar con tus permisos. Los primeros análisis de esos registros dan motivos para mirarla antes:
Riesgo Snyk vende herramientas de seguridad para este problema: es investigación de un fabricante. El estudio académico es un preprint sin revisión por pares. Los dos analizan registros públicos y comunitarios, que no se parecen a un repositorio interno con revisión.
La conclusión no es que las skills sean peligrosas, sino que son código. Snyk lo dice así: las skills son una cadena de suministro de software y piden el mismo rigor que npm, PyPI o los registros de contenedores. La Cloud Security Alliance, en una nota para responsables de seguridad de mayo de 2026, va más lejos: los archivos de contexto de los agentes hay que tratarlos como código de terceros no fiable, y recomienda comprobar el hash del contenido antes de cargar una skill en producción. La propia hoja de ruta del estándar incluye una guía de seguridad para quien escribe e instala skills.
Es la misma disciplina que pedíamos para las dependencias que propone un asistente y para los servidores MCP que nadie gobierna: saber quién publica lo que se ejecuta y no dejar que la versión cambie sola.
Dos tipos de skill, dos reglas
La tabla es nuestra propuesta para separar lo que se escribe en casa de lo que se trae de fuera:
| Skill del equipo | Skill de terceros | |
|---|---|---|
| Qué es | El método escrito: cómo se especifica, se revisa y se comprueba | Una dependencia: instrucciones y, a veces, código que el agente ejecuta |
| Dónde vive | En el repositorio, junto al código | En el repositorio, con la versión fijada, nunca descargada al vuelo |
| Quién la aprueba | El equipo, por pull request | El equipo, por pull request, después de leerla entera |
| Qué se comprueba | Que el agente se comporta como dice (evals del agente) | Origen, contenido, scripts, permisos que pide y hash |
| Si cambias de agente | Viaja con el equipo | Se vuelve a revisar si cambia la versión |
Elaboración de onext a partir de Snyk (2026), la Cloud Security Alliance (2026) y la especificación de Agent Skills
Antes de instalar una skill de fuera
Cinco pasos que proponemos para cualquier skill que no haya escrito el equipo:
- Leerla entera, incluidos los scripts y los archivos de referencia, no solo la descripción.
- Comprobar quién la publica y desconfiar de las que imitan el nombre de una marca conocida.
- Fijar la versión o el hash del contenido, para que no cambie sola en la siguiente instalación.
- Que entre por pull request, como cualquier dependencia, con alguien que firma.
- Dar al agente solo los permisos que la skill necesita: si no tiene por qué salir a internet ni escribir fuera del proyecto, que no pueda.
Ninguno de los cinco pasos es nuevo. Lo nuevo es aplicarlos a algo que parece texto. En muchos equipos, cambiar el código del agente pasa por revisión, pero cambiar una skill no, porque «solo son instrucciones». Una skill cambia lo que hace el agente tanto como el código, y por eso sus cambios deberían disparar también los evals en cada pull request. Y un agente que sigue bien sus instrucciones no garantiza que el resultado sea seguro, como contamos en el código del agente pasa los tests y no es seguro.
Las skills que escribe tu equipo son su método y viajan con él. Las que trae de fuera son dependencias y se revisan antes de entrar. Las dos viven en el repositorio y pasan por la misma puerta que el código.
Por dónde empezar
Si tu equipo ya usa skills o reglas compartidas con su agente, haz inventario: cuáles ha escrito el equipo, cuáles vienen de fuera y cuáles viven fuera del repositorio. Las primeras son el método y merecen revisión como el código; las segundas, la de una dependencia; las terceras, mudarse al repositorio. Para que una skill del equipo diga algo comprobable, sirve lo mismo que para una especificación: criterios que se puedan verificar, como contamos en tu spec ya es un eval.
Si quieres revisarlo con alguien de fuera, el diagnóstico es gratuito, y si en el diagnóstico no vemos diferencia, no hay Quick-start. Antes, puedes ver en qué punto estás con el autodiagnóstico de SDD. Cómo trabajamos el método de un equipo de desarrollo está en AI-Accelerated Development.
Preguntas frecuentes
¿Qué es Agent Skills?
Es un formato abierto para dar a un agente de IA conocimiento y procedimientos concretos. Una skill es una carpeta con un archivo SKILL.md, que lleva metadatos (como mínimo, nombre y descripción) e instrucciones, y que puede incluir scripts, referencias y plantillas. Lo creó Anthropic y el 22 de octubre de 2026 lo cedió a la Agentic AI Foundation, que depende de la Linux Foundation.
¿Qué herramientas admiten skills?
Según Anthropic, más de 70 plataformas de agentes las han integrado, entre ellas ChatGPT, Cursor, GitHub Copilot y VS Code. La especificación lo resume así: construir una skill una vez y usarla en cualquier agente compatible. Antes de contar con ello, comprueba en la documentación de tu herramienta qué partes del formato admite.
¿Qué gana un equipo de desarrollo al escribir su método en skills?
Que cómo especifica, cómo revisa y qué comprueba queda escrito una vez, versionado en el repositorio y revisado como el resto del código. Y que ese método no se pierde si el equipo cambia de agente o convive con varios, porque el formato es el mismo.
¿Son peligrosas las skills de terceros?
Son instrucciones que el agente sigue y, a veces, código que ejecuta, así que tienen los riesgos de cualquier dependencia. Snyk analizó 3.984 skills de dos registros públicos y encontró que el 13,4 % tenía al menos un problema crítico de seguridad y 76 eran maliciosas. Un estudio académico sobre 98.380 skills confirmó 157 maliciosas. No significa que no haya que usarlas: significa que se revisan antes de instalarlas.
¿Cómo se instala una skill de terceros con garantías?
Nuestra propuesta: leerla entera antes de instalarla, incluidos sus scripts; comprobar quién la publica; fijar la versión o el hash del contenido para que no cambie sola; que entre en el repositorio por pull request, y darle al agente los permisos mínimos para lo que la skill necesita.
¿Dónde deben guardarse las skills del equipo?
En el repositorio, junto al código, con revisión por pull request como cualquier cambio. Una skill cambia el comportamiento del agente igual que cambia el código, así que conviene que sus cambios disparen también los evals del agente. Las que viven en un documento compartido fuera del repositorio no las revisa nadie.
Fuentes
- Anthropic, «Donating Agent Skills to the Agentic AI Foundation», 22 de octubre de 2026.
- Agent Skills, «Agent Skills Overview» y especificación (sin fecha; consultada el 28 de octubre de 2026).
- Luca Beurer-Kellner, Aleksei Kudrinskii, Marco Milanta, Kristian Bonde Nielsen, Hemang Sarkar y Liran Tal (Snyk), estudio ToxicSkills sobre la cadena de suministro de las skills de agente, 5 de febrero de 2026 (investigación de un fabricante).
- Yi Liu, Zhihao Chen, Yanjun Zhang, Gelei Deng, Yuekang Li, Jianting Ning y Leo Yu Zhang, «"Do Not Mention This to the User": Detecting and Understanding Malicious Agent Skills in the Wild», arXiv:2602.06547, versión 4 del 10 de junio de 2026 (preprint).
- Cloud Security Alliance (AI Safety Initiative), «CISO Briefing: Agent Context Poisoning: SKILL.md and the New AI Supply Chain Attack Surface», 6 de mayo de 2026.
- Las cifras y citas de fuentes en inglés están traducidas por onext. La tabla de los dos tipos de skill y los cinco pasos son elaboración propia de onext.
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →