56.804 skills y menos de cien plazas: la poda que le falta a los agentes

Un paper de agosto propone dejar de instalar skills en los agentes de IA y empezar a llamarlas por su nombre. La idea es buena y el diagnóstico es mejor. La implementación lleva tres semanas en GitHub, tiene dos forks y un paquete que todavía no existe.

Un paper de agosto propone dejar de instalar skills en los agentes de IA y empezar a llamarlas por su nombre. La idea es buena y el diagnóstico es mejor. La implementación lleva tres semanas en GitHub, tiene dos forks y un paquete que todavía no existe.

Un prompt que engorda

Si has montado un agente de codificación con más de cuatro o cinco skills, ya conoces la sensación. Cada skill que instalas mete su descripción en el system prompt, ahí se queda, y ahí sigue estando en cada mensaje que envías, la uses o no. Es un alquiler que pagas por adelantado y para siempre, a cambio de la posibilidad de que algún día el modelo se acuerde de que la tiene.

El 12 de agosto de 2026, un equipo de SylphAI —Li Yin, Zhi Li, Zhan Shi, Haoran Zhang y Haebin Seong— junto con Zhangyang «Atlas» Wang, de la Universidad de Texas en Austin, publicó «@skills: Attention is all you have» (arXiv:2608.12610). El título es un chiste, pero el argumento no.

Su punto de partida: instalar es hoy el único canal persistente por el que una skill puede llegar a un agente. Y ese canal tiene un aforo ridículo comparado con lo que hay ahí fuera.

El diagnóstico: un aforo de menos de cien

El formato del que va todo esto es SKILL.md: un directorio con un fichero markdown y un frontmatter con nombre y descripción. Lo lanzó Anthropic el 16 de octubre de 2025 y en diciembre lo publicó como estándar abierto. Hoy lo lee prácticamente cualquier agente de codificación serio.

El paper dice que su rastreo de julio de 2026 encontró 56.804 skills públicas repartidas en 1.133 repositorios de GitHub, y que todas ellas compiten por «menos de cien plazas fiables de auto-disparo por agente».

Un apunte de higiene antes de seguir, porque el número es llamativo y va a circular solo: las dos cifras son autorreportadas. El rastreo es de los propios autores y no hay forma de reproducirlo desde fuera. El límite de las cien plazas lo respaldan con evidencia propia que ellos mismos califican de «conservadora», apoyada en la literatura sobre sesgo posicional y degradación por instrucciones concurrentes. No es un benchmark independiente. Es una estimación razonada de parte interesada, y así hay que leerla.

Dicho lo cual, el mecanismo que describen lo hemos sufrido todos: cuando el prompt se llena de descripciones, el modelo no dispara mejor. Dispara peor. Cada instrucción residente diluye a las demás.

Lo que hace una célula con este mismo problema

Aquí es donde la biología ya tiene la respuesta desde hace unos tres mil millones de años.

Una célula humana lleva encima unos veinte mil genes. No fabrica veinte mil proteínas a la vez —eso la mataría en minutos por puro coste energético—. Lo que hace es guardar el catálogo completo en un sitio barato y frío (el ADN), transcribir bajo demanda lo que necesita en cada momento, y mantener expresado de forma permanente solo un puñado de genes housekeeping: los que hacen falta siempre, pase lo que pase.

Tres regímenes distintos para tres necesidades distintas: estar disponible, estar a mano y estar encendido. Nadie confunde el catálogo con el inventario.

Los agentes de IA, en cambio, llevan desde el principio con un único régimen: o instalas la skill —y la enciendes para siempre— o no existe. El paper propone justamente separar lo que la célula separó hace eones.

Los tres niveles

La propuesta se llama @skills y se resume en tres formas de invocar una ruta.

Nivel 1 · Referencia. Escribes @skills:<ruta> y el cuerpo completo de la skill entra en el punto de uso. No se instala nada. Coste residente en el prompt: cero. Cuando termina la sesión, se evapora. Este nivel es el que sirve a la cola larga: las 56.804 skills, sin tener que ganar una plaza antes de poder usarse ni una sola vez.

Nivel 2 · Guardado. Añades :save y el protocolo vendoriza una copia dentro de .atskills/, en el árbol versionado de tu proyecto. Editable, revisable en un pull request, compartible con un git clone. Sigue costando cero tokens residentes: el descubrimiento ocurre en el autocompletado de tu herramienta, no en el prompt del modelo.

Nivel 3 · Instalación. Añades :install y se escribe una línea en .atskills/.autotrigger, un fichero con sintaxis tipo .gitignore —globs, negaciones con !, comentarios con #—. Solo el frontmatter (nombre y descripción, unos 50-100 tokens) queda residente; el cuerpo carga cuando dispara. Es el único nivel que paga alquiler, y los autores recomiendan reservarlo para menos de diez skills esenciales.

Tres niveles, un solo alquiler QUÉ CUESTA CADA FORMA DE USAR UNA SKILL EN EL PROMPT DEL AGENTE NIVEL GESTO QUÉ PERSISTE COSTE RESIDENTE EN EL PROMPT 1 · Referencia @skills:<ruta> Nada. Se evapora con la sesión. 0 tokens 2 · Guardado @skills:<ruta>:save Una copia en .atskills/, versionada en git. 0 tokens 3 · Instalación @skills:<ruta>:install Una línea en .atskills/.autotrigger ~50-100 tokens por skill Solo el nivel 3 ocupa espacio permanente. Los autores recomiendan reservarlo para menos de diez skills esenciales. Fuente: Yin et al., «@skills: Attention is all you have», arXiv:2608.12610, 12 de agosto de 2026.
Los tres niveles del protocolo @skills y lo que cuesta cada uno en el prompt

Lo que el protocolo se niega a tener

Esta es la parte que más me gusta, y es una lista de ausencias.

No hay manifiesto. No hay lockfile. No hay base de datos ni registro obligatorio. Todo el estado vive en el árbol de ficheros del proyecto y se versiona con git, como cualquier otra cosa del repositorio.

Tampoco hay versionado ni pinning. Una copia guardada se desengancha de su proveedor en el momento exacto de guardarla, y lo único que queda es .source: un sello de procedencia de dos líneas —origen en la primera, fecha y revisión en la segunda— que se escribe una vez y nunca se consulta para resolver nada. La descripción del propio protocolo es preciosa: pure provenance. Partida de nacimiento, no correa. Si lo borras, te desenganchas del todo.

La resolución es local primero: si existe una carpeta en .atskills/<ruta>, esa carpeta responde siempre a su propia dirección —el mismo gesto que el vendor/ de Go—. Si no existe nada local, la ruta apunta a la nube y pasa por una caché validante compartida (~/.cache/atskills/, común a todos los clientes conformes) que se comporta como un navegador: cada uso pregunta «¿esto ha cambiado?» con una sola sonda de revisión, no con una redescarga.

Cero mecanismos nuevos. Todo son convenciones prestadas de sitios donde ya funcionan.

La función que convertiría esto en gobernanza

Hay una pieza que en el informe pasa como detalle de producto y que a mí me parece la más importante a medio plazo.

El cliente de referencia trae un comando, atskills prompt (y su equivalente visual, la vista View prompt dentro de /skills), que hace algo aparentemente tonto: te enseña el texto exacto, literal, que va a recibir el modelo, con su recuento de tokens.

Piénsalo un segundo. Eso es una capacidad de auditoría de IA. En un mundo donde el Reglamento europeo de IA pide trazabilidad sobre lo que un sistema hace y por qué, poder decir «estas son las instrucciones que el modelo vio en esta sesión, y aquí está el diff de una línea que cambió» es infinitamente mejor que la alternativa habitual: un AGENTS.md monolítico de setecientas líneas que nadie revisa y una lista de plugins que nadie sabe qué inyecta.

Un fichero tipo .gitignore que gobierna qué se dispara solo es, sobre todo, un fichero revisable en un pull request. Eso no es una feature. Es una postura.

Dónde encaja esto en el mapa

  • MCP resuelve otro problema, ortogonal a este: conectar agentes con herramientas y servicios a través de un servidor. @skills distribuye instrucciones procedimentales en forma de texto. Se llevan bien. El paper se apoya, eso sí, en una cifra de Anthropic que conviene citar con cuidado: el −98,7% de tokens (de 150.000 a 2.000) que Anthropic publicó el 4 de noviembre de 2025 mide cargar definiciones de herramientas MCP bajo demanda desde el sistema de ficheros en vez de precargarlas todas. No mide una migración de MCP a skills. Ese puente lo construyen los autores del paper, no Anthropic.
  • skills.sh, de Vercel, es hoy el registro comunitario dominante e indexa buena parte de ese corpus. Ojo con una confusión que circula: su flujo es npx skills add, es decir, instala. El eslogan «usar sin instalar» es de atskills.one, no de skills.sh.
  • Agent Skills de Anthropic es el estándar de formato del que depende todo lo demás. @skills no lo reemplaza: se declara explícitamente aditivo y de cero campos nuevos.
  • AGENTS.md / CLAUDE.md es la competencia real, y el paper lo admite. Es la convención cruda pero dominante. El nivel 2 se presenta, con bastante honestidad, como «un AGENTS.md factorizado en piezas» que cargan bajo demanda en vez de gravar cada mensaje.

La letra pequeña

Y ahora la parte incómoda, que es la razón por la que este artículo no termina en «instálalo».

El repositorio se creó el 27 de julio de 2026. A día de hoy, 20 de agosto, lleva 66 estrellas y 2 forks. Licencia MIT, sin restricciones comerciales, eso está bien. Pero no hay ningún otro framework de agentes que lo haya integrado.

El paquete npm atskills no está publicado. El registro devuelve un 404 limpio. El package.json del repo declara el nombre y la versión 0.1.0, y el propio README lo lista como tarea pendiente: publicar el paquete para que la gente pueda fijar una versión en vez de apuntar a la ruta de un clon. Hoy, adoptar esto significa clonar un repositorio.

El hub tiene una contradicción curiosa entre dos fuentes primarias: atskills.one está desplegado y vivo, presume de más de 60.000 skills y usa el eslogan «tu agente nunca empieza de cero»; el README del repositorio, en cambio, dice literalmente «the hub ships later». No elijo bando: lo cuento.

Y el detalle que más me chirría. El primer autor del paper es cofundador y CEO de SylphAI, la empresa que opera la infraestructura que el paper defiende —y que vende AdaL Engineer, su agente comercial, donde vive el cliente de referencia—. El conflicto de interés existe y el paper no lo declara. No hay sección de competing interests, ni de financiación. Solo las afiliaciones. Que conste que la empresa tiene obra: AdalFlow, su biblioteca insignia, va por las 4.200 estrellas. Pero especificación, cliente de referencia y único caso de producción citado pertenecen todos a la misma casa.

Mi veredicto: quédate con el patrón

El diagnóstico está bien argumentado y describe un problema real que cualquiera con un agente medianamente cargado ha sufrido. La separación en tres regímenes —disponible, a mano, encendido— es la forma correcta de pensar el presupuesto de contexto, y me sorprendería que en doce meses no esté absorbida de alguna forma en la especificación oficial o en el registro de Vercel.

La implementación es otra cosa: tres semanas escasas en GitHub, un solo proveedor detrás, sin paquete publicado y sin adopción externa medible.

Así que lo mismo de siempre. El patrón sí, la dependencia todavía no. Direccionamiento por ruta, vendoring versionado con procedencia mínima, un fichero de auto-disparo revisable en PR y una caché que pregunta antes de descargar: eso te lo puedes llevar hoy a tu propio sistema sin depender de nadie. Clonar un repositorio de tres semanas para que sea el eje de tu arquitectura de agentes, no.

La célula no guarda el catálogo en el mismo sitio donde fabrica. Nosotros llevamos dos años haciéndolo, y el prompt se nos ha puesto del tamaño de un armario.

Ideas por encima de código; evidencia por encima de humo.

Pablo Formoso
autor

Pablo Formoso

Notas de campo desde la intersección de datos, IA, y filosofía aplicada.

entradas
56
desde
2024

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *