Las skills estáticas son skills muertas

Anoche publiqué una sección de Referencia de Configuración para la guía de Claude Code. Quince entradas. Cada cita verificada con grep contra un número de línea. La publiqué con convicción después de que el bucle de crítica volviera limpio. Para cuando estaba haciendo commit del archivo .md, ya sabía que necesitaría una v3, no porque hubiera hecho algo mal, sino porque la guía cambia, el producto subyacente cambia, las consultas de los usuarios se desplazan, y la sección que acababa de publicar empezaría a derivar en el momento en que me alejara de ella.

Una skill (ya sea una sección de referencia en Markdown o una definición de skill de agente en .claude/skills/) solo está viva mientras alguien observa su trayectoria. En el momento en que dejas de observarla, se vuelve estática. Las skills estáticas se degradan en el sitio. El post de abajo forma parte de la serie AI engineering que documenta cómo evoluciona la infraestructura de agentes en producción.

Las skills estáticas de agentes de IA fracasan porque dejan de aprender en el momento en que se publican. Sin un bucle de retroalimentación que ingiera trayectorias reales de invocación (las entradas, las llamadas a herramientas, las salidas y los estados de error del uso real), las skills no pueden adaptarse a productos cambiantes, consultas de usuario que se desplazan, o modos de fallo recurrentes. Múltiples usuarios redescubren de forma independiente las mismas soluciones alternativas mientras la definición de la skill permanece congelada. La solución: agregación continua de trayectorias que convierte los patrones de uso en actualizaciones automatizadas de skills.

Un nuevo paper de arxiv de Ma, Yang, Ji, Wang y Wang (“SkillClaw: Let Skills Evolve Collectively with Agentic Evolver”, abril de 2026) formaliza este problema a nivel de investigación.¹ Su planteamiento inicial, citado directamente: “Los agentes basados en modelos de lenguaje grandes (LLM) como OpenClaw dependen de skills reutilizables para realizar tareas complejas, pero estas skills permanecen en gran medida estáticas tras su despliegue. Como resultado, flujos de trabajo similares, patrones de uso de herramientas y modos de fallo se redescubren repetidamente entre usuarios, impidiendo que el sistema mejore con la experiencia.”¹

He estado viviendo ese modo de fallo durante meses. Tú también, si estás construyendo skills para cualquier framework de agentes.

TL;DR

Las skills de agentes se publican y luego dejan de mejorar. Los usuarios descubren los mismos modos de fallo de forma independiente y nunca retroalimentan esos descubrimientos a la propia skill. Ma et al. plantean esto como un problema de inteligencia colectiva: las interacciones entre usuarios y a lo largo del tiempo son señales sobre cuándo una skill funciona o falla, pero no existe ningún mecanismo a nivel de ecosistema que las agregue en actualizaciones de skills. Su framework SkillClaw propone tratar las trayectorias agregadas como la señal de evolución, ejecutando un evolucionador autónomo que identifica patrones de comportamiento recurrentes y los traduce en refinamientos o extensiones de capacidades.¹ El abstract cita a “OpenClaw” como ejemplo de un agente LLM que usa skills reutilizables. No he podido identificar a OpenClaw como un producto específico en producción basándome solo en el abstract, y no voy a especular sobre ello en este post. Lo que sí voy a afirmar es que el problema estructural que describe el paper se aplica a cualquiera que esté construyendo skills para Claude Code, Codex, Cursor, o su propio framework de agentes. La conclusión: si tu biblioteca de skills no está ingiriendo continuamente trayectorias del uso real, está muerta desde el día en que la publicaste.

Puntos clave

• Autores de skills: El trabajo no termina cuando la skill se publica. El trabajo termina cuando tienes un bucle que observa cómo se usa la skill, detecta los modos de fallo recurrentes, y los retroalimenta a la definición de la skill. Publicar es el comienzo de la vida de la skill, no el final.
• Constructores de frameworks: Registra cada invocación de skill con su trayectoria: las entradas, las llamadas a herramientas, las salidas, el estado de error. Ese registro es la señal de evolución. Si no lo estás registrando, no estás mejorando tus skills; las estás manteniendo.
• Practicantes con mentalidad Jiro: El paper de SkillClaw es lenguaje académico para el patrón Shokunin aplicado a las skills. La skill es el oficio. Las trayectorias son la práctica. La evolución es la búsqueda de la maestría. Estático = muerto.

Lo que el paper realmente dice

Voy a recorrer las afirmaciones del abstract con cuidado, y luego marcaré claramente dónde estoy extendiendo el planteamiento.

El planteamiento del problema (del abstract). Los agentes LLM dependen de skills reutilizables para realizar tareas complejas. Estas skills permanecen en gran medida estáticas tras su despliegue. Flujos de trabajo similares, patrones de uso de herramientas y modos de fallo se redescubren repetidamente entre usuarios. El sistema no mejora con la experiencia.¹

Los autores apuntan a un modo de fallo específico, no a una afirmación universal de que todas las skills se degradan. Una skill que nunca se invoca no se degrada. Una skill que un único usuario invoca sin reportar problemas no se degrada de forma visible. La degradación aparece cuando múltiples usuarios cada uno se encuentra con su propia versión del mismo fallo, y el sistema no tiene forma de agregar esos encuentros en una única actualización. (Esa última frase es mi planteamiento, no el del paper.)

La brecha existente (del abstract). El abstract afirma que, si bien las interacciones entre usuarios “proporcionan señales complementarias sobre cuándo una skill funciona o falla, los sistemas existentes carecen de un mecanismo para convertir esas experiencias heterogéneas en actualizaciones fiables de skills.”¹ La afirmación de carga está aquí. La brecha no es que nadie haya pensado en mejorar las skills. La brecha es que ningún mecanismo a nivel de ecosistema agrega trayectorias, identifica patrones recurrentes y los traduce en actualizaciones.

El pipeline de SkillClaw (del abstract). El abstract describe un pipeline continuo: SkillClaw “agrega trayectorias generadas durante el uso y las procesa con un evolucionador autónomo, que identifica patrones de comportamiento recurrentes y los traduce en actualizaciones al conjunto de skills mediante el refinamiento de skills existentes o su extensión con nuevas capacidades.”¹ El sistema mantiene skills actualizadas en un repositorio compartido y las sincroniza entre usuarios, de modo que las mejoras descubiertas en un contexto se propagan por todo el sistema sin requerir esfuerzo del usuario.¹

La evaluación (del abstract). El paper evalúa SkillClaw en un benchmark llamado WildClawBench usando Qwen3-Max como modelo subyacente. La propia redacción del abstract está gramaticalmente rota en la versión publicada: “los experimentos en WildClawBench muestran que limitada interacción y retroalimentación, mejora significativamente el rendimiento de Qwen3-Max en escenarios de agentes del mundo real.”¹ Yo lo leo así: con interacción y retroalimentación limitadas, SkillClaw aun así produce mejoras significativas de rendimiento sobre la línea base. El abstract no publica cifras específicas; es de suponer que el paper completo sí.

Ese es el paper tal como lo describe el abstract. Los autores proponen que los ecosistemas multiusuario de agentes con skills compartidas se benefician de la agregación automatizada de trayectorias que alimenta actualizaciones automatizadas de skills, y reportan que su implementación mejora significativamente el rendimiento de Qwen3-Max bajo condiciones de retroalimentación limitada.

Lo que el paper no dice (y lo que estoy añadiendo yo)

El abstract cita a “OpenClaw” como un ejemplo (“agentes LLM como OpenClaw”) de un agente que usa skills reutilizables. No sé qué es OpenClaw basándome solo en el abstract; no pude identificarlo rápidamente como un producto específico en producción. El framework del paper (SkillClaw) apunta a los ecosistemas multiusuario de agentes en general, no a OpenClaw específicamente, así que la pregunta “qué es OpenClaw” es mayormente tangencial al argumento. La señalo para que nadie lea este post y se vaya pensando que el paper trata sobre Claude Code. No es así. Nombra a OpenClaw como ejemplo y propone SkillClaw como mecanismo general.

Lo que sí afirmo, de forma separada al paper, es que el problema estructural que el paper describe se aplica a un problema real que he estado viviendo en el ecosistema de skills de Claude Code. Esa afirmación es mía, no del paper. Aquí está por qué creo que se aplica.

Las skills en el ecosistema de Claude Code se publican como artefactos estáticos. Una skill es un archivo SKILL.md (o un paquete de archivos de soporte) que describe cómo debe realizarse una tarea. La escribes una vez. Haces commit. La referencias con un comando slash o mediante autocompletado @skill-name; los mecanismos para construir skills personalizadas son directos. Una vez publicada, es un artefacto estático. Ningún mecanismo automático observa cómo se usa la skill en la práctica ni actualiza la definición de la skill en función de lo que funciona y lo que falla.

Distintos usuarios se encuentran con los mismos modos de fallo de forma independiente. Cada skill que he publicado tiene al menos un modo de fallo recurrente que solo aparece bajo condiciones específicas. Alguien invoca la skill con una entrada que no anticipé, se encuentra con el caso límite, lo rodea manualmente, y sigue adelante. Otra persona, en otro lugar, se topa con el mismo caso límite y hace su propia solución alternativa. La skill en sí nunca cambia.

La señal agregada es real pero no se usa. Si pudiera ver cada trayectoria de cada invocación de cada skill que he publicado, podría identificar los modos de fallo recurrentes en una tarde. Esa señal existe en el historial de sesión de cada usuario individual. Simplemente no está agregada en ningún lado, así que nadie actúa sobre ella.

La solución es o manual o inexistente. Ahora mismo, el único mecanismo para mejorar una skill es que yo note un problema en mi propio uso, o que alguien abra un issue, o que alguien abra una PR. Todas esas vías requieren esfuerzo del usuario. La idea central del paper de SkillClaw, que los datos de trayectoria ya existen y deberían alimentar actualizaciones de skills automáticamente, es exactamente el mecanismo que nos falta.

Esa es mi afirmación sobre cómo el planteamiento del paper se aplica a Claude Code. No es lo que dice el paper. Es cómo estoy leyendo el paper frente a mi propio trabajo.

El patrón Shokunin, aplicado a las skills

Un planteamiento sigue apareciendo cuando pienso en el oficio. Jiro Ono, el maestro del sushi, es el ejemplo canónico. Sesenta años del mismo trabajo. Cada día, observa lo que pasa en la barra, ajusta la técnica, refina la temperatura del arroz, el ángulo del cuchillo, el tiempo del shari. El trabajo en sí es la señal de entrenamiento. El practicante es el agregador.

Escribí sobre el planteamiento Shokunin / bucle de calidad hace un tiempo. La idea central: el oficio es el bucle de retroalimentación. Haces el trabajo, observas el trabajo, notas lo que se rompió, ajustas, vuelves a hacer el trabajo. Una y otra vez. La maestría vive en el delta entre lo que pretendías y lo que realmente pasó, y en tu disposición a llevar ese delta al siguiente intento.

Una skill estática rompe ese bucle. Publicas la skill. Dejas de observar. El delta entre lo que la skill pretendía y lo que realmente pasa se acumula en cien sesiones distintas que nunca ves. La skill no mejora porque el artesano no está en la barra.

El paper de SkillClaw propone un agregador automatizado: no un reemplazo del humano, sino un mecanismo que observa todas las trayectorias, nota lo que se rompió entre sesiones, y propone actualizaciones de vuelta a la definición de la skill. La ambición no es descabellada. En realidad es el mínimo aceptable si quieres que una skill sobreviva a su propio despliegue.

Cómo se ve esto en la práctica

Si quisiera construir el patrón SkillClaw contra las skills de Claude Code que mantengo hoy, esto es lo que necesitaría:

1. Un registro de trayectoria para cada invocación de skill. Cada vez que se ejecuta una skill, las entradas, las llamadas a herramientas que hace, las salidas, los estados de error, y la disposición final (¿aceptó el usuario el resultado? ¿lo revirtió? ¿lo reescribió?). El registro a nivel de sesión ya existe en Claude Code; la pregunta es si se agrega entre sesiones y se extrae para el propietario de la skill.

2. Un detector de patrones. Algo que lea el registro de trayectoria e identifique patrones recurrentes: la misma clase de entrada llevando al mismo fallo, la misma llamada a herramienta fallando de la misma manera, el mismo caso límite apareciendo bajo contextos de usuario distintos. El requisito es clustering sobre datos de trayectoria estructurados, no AGI.

3. Un generador de propuestas. Dado un patrón detectado, redacta una actualización candidata para la skill: una nueva rama de manejo, un ejemplo adicional, una restricción extra en el cuerpo del SKILL.md. La actualización es una propuesta, no un cambio publicado.

4. Una compuerta. Cada actualización propuesta pasa por revisión humana, verificación factual (la misma compuerta estricta que aplico a todo lo demás) y un bucle de crítica antes de publicarse. La automatización hace la agregación, no la publicación.

5. Distribución. Cuando una actualización propuesta es aceptada, se propaga a cada usuario de esa skill. En un ecosistema centralizado esto es trivial (actualiza la skill canónica, todos la descargan). En un ecosistema distribuido esto es más difícil.

La mayor parte ya existe en Claude Code: registro de sesión, definiciones de skills versionadas, un bucle de crítica operativo. La pieza que falta es la capa de agregación y detección de patrones que conecta las trayectorias de sesión con las actualizaciones de skills. La taxonomía organizativa de comandos, skills, subagentes y reglas ya proporciona la base estructural; lo que falta es el canal de retroalimentación que mantiene viva cada categoría después del despliegue.

La implicación incómoda

Cada skill que he publicado en los últimos seis meses está muerta exactamente en el sentido que describe el paper de SkillClaw. Escribo la skill. La uso yo. Noto problemas. Los arreglo en las skills que yo uso. Mis skills mejoran para mí. No mejoran para nadie más a menos que esa persona note independientemente el mismo problema y abra algo.

El trabajo que hice anoche en la Referencia de Configuración es exactamente este patrón. La guía de Claude Code es un artefacto compartido. Los usuarios la consultan buscando claves de configuración específicas. Puedo ver los datos de GSC que me dicen qué claves de configuración se buscan. Esos son datos de trayectoria agregados, que literalmente me dicen qué skills de la guía se están invocando y dónde están aterrizando los resultados. Y hasta que fui a mirar esos datos, la guía era estática. Había sido estática durante semanas. No porque nadie estuviera observando las trayectorias, sino porque yo era la única persona que podía observarlas, y tenía otras cosas que hacer.

El paper de SkillClaw es la formalización académica del problema. El mecanismo práctico es más simple: si no tienes un pipeline automático de los datos de trayectoria a las actualizaciones de skills, tus skills están envejeciendo en el sitio. Puede que sigan funcionando para algunos usuarios bajo algunas condiciones. No están mejorando.

La única pregunta es si aceptas que tus skills mueren en el momento en que las publicas, o si construyes al observador que las mantiene vivas. El principio del contexto compuesto se aplica aquí: cada observación de trayectoria se compone con la siguiente, y el valor de la skill crece de forma no lineal con la retroalimentación que ingiere. A la inversa, tratar el contexto como arquitectura significa reconocer que la estructura de una skill determina su capacidad para absorber nueva información en primer lugar.

El agregador mínimo viable

Antes de empezar este post, tenía cero agregación de trayectorias en mis skills. Nada. Tenía historial de sesión que podía leer manualmente, pero nada que sacara a la superficie patrones entre sesiones. Esa es exactamente la patología de skill estática que describe el paper, y yo la estaba ejecutando.

Aquí está la cosa real más pequeña que puedo publicar ahora mismo, hoy: un único archivo de texto que registre cada invocación de skill a través de mis propias sesiones, de solo-anexar, con timestamp + nombre de skill + forma de la entrada + disposición final (aceptada / revisada / revertida). Sin detector de patrones. Sin evolucionador autónomo. Solo el registro.

Ese archivo es el agregador mínimo viable. No es SkillClaw. Es la capa de entrada que SkillClaw necesitaría si existiera, y la capa de entrada que yo necesito antes de poder siquiera ver si mis skills tienen modos de fallo recurrentes. Sin él, estoy adivinando. Con él, al menos puedo escanear el registro a mano cuando reviso una skill y preguntar: ¿pasó el mismo fallo tres veces este mes?

Ese es el compromiso. Un archivo. Solo-anexar. Registrado por invocación. Revisado cuando reviso la skill.

Si eso funciona, la siguiente capa es el detector de patrones. Si el detector de patrones funciona, la siguiente capa es el generador de propuestas. La ambición del paper es un evolucionador autónomo completo ejecutándose a través de un ecosistema multiusuario. La ambición para mí es no estar corriendo a ciegas.

FAQ

¿Es “OpenClaw” en el paper lo mismo que Claude Code?

No, y tampoco puedo decirte qué es OpenClaw. El abstract menciona “agentes LLM como OpenClaw” como un ejemplo de un agente que usa skills reutilizables, sin definirlo. No pude identificarlo rápidamente como un producto específico en producción basándome solo en el abstract. Lo importante: el framework SkillClaw del paper apunta a ecosistemas multiusuario de agentes en general, no a OpenClaw ni a Claude Code específicamente. Sea lo que sea OpenClaw, el paper no es un paper sobre Claude Code, y mis afirmaciones sobre Claude Code en este post son mías, no del paper.¹

¿Cuál es la contribución novedosa real del paper?

Según el abstract: un framework para la evolución colectiva de skills en ecosistemas multiusuario de agentes que (1) agrega trayectorias entre usuarios y a lo largo del tiempo, (2) ejecuta un evolucionador autónomo para detectar patrones recurrentes, y (3) traduce patrones en actualizaciones a skills en un repositorio compartido que se sincronizan entre usuarios.¹ La novedad no es “las skills pueden mejorarse” (eso es obvio). La novedad es proponer que el bucle de mejora debería ser autónomo y guiado por trayectoria, no guiado por humanos.

¿Reporta el paper cifras específicas de mejora?

El abstract describe la mejora como “significativa” en un benchmark llamado WildClawBench usando Qwen3-Max, bajo condiciones de retroalimentación limitada, pero no publica cifras específicas.¹ Para cifras, la fuente es el paper completo.

¿En qué se diferencia esto de un pull request de git contra una definición de skill?

Una PR es un mecanismo iniciado por humanos. Alguien tiene que notar el problema, escribir el arreglo, abrir la PR, revisarla, mergearla. Cada paso requiere esfuerzo humano. El framework SkillClaw que propone el paper es agregación autónoma: el sistema nota el patrón a través de muchos usuarios, propone el arreglo por sí mismo, y sincroniza la actualización sin que ningún usuario individual tenga que abrir nada.¹ Si esa versión autónoma es deseable o segura para cualquier ecosistema específico es una pregunta aparte. La contribución del paper es mostrar que es técnicamente coherente.

¿Se aplica esto a mis skills personalizadas de Claude Code?

El paper no hace afirmaciones sobre ningún ecosistema específico de skills de Claude Code. Mi afirmación, separada del paper, es que el problema estructural (skills publicadas como artefactos estáticos, modos de fallo redescubiertos por cada usuario de forma independiente, sin mecanismo de agregación) sí se aplica a las skills de Claude Code, y que cualquiera que esté construyendo skills para Claude Code o cualquier framework de agentes similar debería estar pensando en cómo construir un bucle de mejora guiado por trayectoria. Esa es mi opinión, no un hallazgo del paper.

¿Cuál es la conexión Shokunin?

El planteamiento Shokunin / bucle de calidad argumenta que la maestría viene del delta entre lo que pretendías y lo que realmente pasó, llevado al siguiente intento. Las skills estáticas rompen ese bucle porque los deltas se acumulan en sesiones que el artesano nunca ve. SkillClaw es la versión académica de cerrar ese bucle: automatizar la recolección de deltas y retroalimentarlos a la skill. La disciplina es la misma; el mecanismo es distinto.

Referencias