Las habilidades estáticas son habilidades 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é por convicción después de que el bucle de crítica regresara 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 cambian, y la sección que acababa de publicar empezaría a desviarse en cuanto me alejara de ella.

Una habilidad, ya sea una sección de referencia en Markdown o una definición de habilidad de agente en .claude/skills/, solo está viva mientras alguien vigila su trayectoria. En el momento en que dejas de vigilarla, se vuelve estática. Las habilidades estáticas decaen en el sitio.

Un nuevo artículo 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: “Large language model (LLM) agents such as OpenClaw rely on reusable skills to perform complex tasks, yet these skills remain largely static after deployment. As a result, similar workflows, tool usage patterns, and failure modes are repeatedly rediscovered across users, preventing the system from improving with experience.”¹

He estado viviendo ese modo de falla durante meses. Tú también, si estás construyendo habilidades para cualquier arnés de agentes.

TL;DR

Las habilidades de agentes se publican y luego dejan de mejorar. Los usuarios descubren los mismos modos de falla de forma independiente y nunca retroalimentan esos hallazgos a la habilidad misma. Ma et al. enmarcan esto como un problema de inteligencia colectiva: las interacciones entre usuarios y a lo largo del tiempo son señales sobre cuándo una habilidad funciona o falla, pero no existe ningún mecanismo a nivel de ecosistema para agregarlas y convertirlas en actualizaciones de la habilidad. 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 resumen cita a “OpenClaw” como ejemplo de agente LLM que usa habilidades reutilizables; no he podido identificar a OpenClaw como un producto específico en producción solo a partir del resumen, y no voy a especular sobre ello en esta publicación. Lo que sí voy a afirmar es que el problema estructural que describe el artículo se traslada a cualquiera que esté construyendo habilidades para Claude Code, Codex, Cursor o su propio arnés. La conclusión: si tu biblioteca de habilidades no está ingiriendo continuamente trayectorias de uso real, está muerta desde el día en que la publicas.

Puntos clave

• Autores de habilidades: El trabajo no termina cuando se publica la habilidad. El trabajo termina cuando tienes un bucle que observa cómo se usa la habilidad, detecta modos de falla recurrentes y los retroalimenta a la definición de la habilidad. Publicar es el comienzo de la vida de la habilidad, no el final.
• Constructores de arneses: Registra cada invocación de habilidad 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 habilidades; las estás manteniendo.
• Practicantes con mentalidad Jiro: El artículo de SkillClaw es lenguaje académico para el patrón Shokunin aplicado a habilidades. La habilidad 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 dice realmente el artículo

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

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

Esa es una afirmación sobre un modo de falla específico, no una afirmación de que todas las habilidades decaen. Una habilidad que nunca se invoca no decae. Una habilidad invocada por un usuario que nunca reporta problemas no decae de forma visible. El deterioro aparece cuando tienes múltiples usuarios, cada uno encontrándose con su propia versión de la misma falla, y el sistema no tiene forma de agregar esos encuentros en una única actualización. (Esa última oración es mi planteamiento, no del artículo.)

La brecha existente (del resumen). El resumen afirma que, si bien las interacciones entre usuarios “proporcionan señales complementarias sobre cuándo una habilidad funciona o falla, los sistemas existentes carecen de un mecanismo para convertir tales experiencias heterogéneas en actualizaciones de habilidades confiables.”¹ Esta es la afirmación que sostiene toda la estructura. No es que nadie haya pensado en la mejora de habilidades. Es que ningún mecanismo a nivel de ecosistema agrega trayectorias, identifica patrones recurrentes y los traduce en actualizaciones.

El pipeline de SkillClaw (del resumen). El resumen 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 habilidades, refinando las habilidades existentes o extendiéndolas con nuevas capacidades.”¹ Las habilidades actualizadas se mantienen en un repositorio compartido y se sincronizan 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 resumen). El artículo evalúa SkillClaw en un benchmark llamado WildClawBench usando Qwen3-Max como modelo subyacente. La propia redacción del resumen está gramaticalmente rota en la versión publicada: “experiments on WildClawBench show that limited interaction and feedback, it significantly improves the performance of Qwen3-Max in real-world agent scenarios.”¹ Lo leo como: con interacción y retroalimentación limitadas, SkillClaw aún produce mejoras significativas de rendimiento sobre la línea base. El resumen no publica cifras específicas; presumiblemente el artículo completo sí.

Así es como el resumen describe el artículo. Los autores proponen que los ecosistemas de agentes multiusuario con habilidades compartidas se benefician de la agregación automatizada de trayectorias que alimenta actualizaciones automatizadas de habilidades, y reportan que su implementación mejora significativamente el rendimiento de Qwen3-Max bajo condiciones de retroalimentación limitada.

Lo que el artículo no dice (y lo que yo estoy añadiendo)

El resumen cita a “OpenClaw” como un ejemplo (“agentes LLM como OpenClaw”) de un agente que usa habilidades reutilizables. No sé qué es OpenClaw solo a partir del resumen; no pude identificarlo rápidamente como un producto específico en producción. El framework del artículo (SkillClaw) se presenta como una solución para ecosistemas de agentes multiusuario en general, no para OpenClaw específicamente, así que la pregunta “¿qué es OpenClaw?” es en gran medida tangencial al argumento. Lo señalo para que nadie lea esta publicación y se vaya pensando que el artículo trata sobre Claude Code. No lo es. Nombra a OpenClaw como ejemplo y propone SkillClaw como mecanismo general.

Lo que afirmo, por separado del artículo, es que el problema estructural que describe el artículo se traslada a un problema real que he estado viviendo en el ecosistema de habilidades de Claude Code. Esa afirmación es mía, no del artículo. Aquí está por qué creo que se traslada.

Las habilidades en el ecosistema de Claude Code se publican como artefactos estáticos. Una habilidad es un archivo SKILL.md (o un paquete de archivos de apoyo) que describe cómo debe realizarse una tarea. La escribes una vez. Haces commit. La referencias con un comando slash o mediante autocompletado con @skill-name. Una vez publicada, es un artefacto estático. No existe ningún mecanismo automático que observe cómo se usa la habilidad en la práctica y actualice la definición de la habilidad con base en lo que funciona y lo que falla.

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

La señal agregada es real pero no se utiliza. Si pudiera ver cada trayectoria de cada invocación de cada habilidad que he publicado, podría identificar los modos de falla recurrentes en una tarde. Esa señal existe: está en el historial de sesiones de cada usuario. Solo que no está agregada en ninguna parte, así que nadie actúa sobre ella.

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

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

El patrón Shokunin, aplicado a las habilidades

Hay un planteamiento al que vuelvo una y otra vez 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, observando lo que ocurre en la barra, ajustando la técnica, refinando la temperatura del arroz, el ángulo del cuchillo, el tiempo del shari. El trabajo mismo 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 ocurrió, y en tu disposición a llevar ese delta al siguiente intento.

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

El artículo de SkillClaw propone un agregador automatizado: no un reemplazo del humano, sino un mecanismo que observa todas las trayectorias, nota lo que se rompió a través de las sesiones y propone actualizaciones de vuelta a la definición de la habilidad. Esa no es una ambición descabellada. En realidad, es el umbral mínimo si quieres que una habilidad sobreviva a su propio despliegue.

Cómo se ve esto en la práctica

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

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

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

3. Un generador de propuestas. Dado un patrón detectado, redactar una actualización candidata a la habilidad: 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 puerta de control. Cada actualización propuesta pasa por revisión humana, verificación factual (la misma puerta 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 se acepta una actualización propuesta, se propaga a cada usuario de esa habilidad. En un ecosistema centralizado esto es trivial (se actualiza la habilidad canónica, todos la obtienen). En un ecosistema distribuido es más difícil.

La mayor parte ya está presente en Claude Code: el registro de sesiones existe, las definiciones de habilidades están versionadas, el bucle de crítica está 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 habilidades.

La implicación incómoda

Cada habilidad que he publicado en los últimos seis meses está muerta exactamente en el sentido que describe el artículo de SkillClaw. Escribo la habilidad. La uso yo mismo. Noto problemas. Los arreglo en las habilidades que yo uso. Las habilidades mejoran para mí. No mejoran para nadie más, a menos que esa persona note independientemente el mismo problema y reporte 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 en busca de claves de configuración específicas. Puedo ver los datos de GSC que me dicen qué claves de configuración se buscan. Eso son datos de trayectoria agregados: literalmente me dicen qué habilidades de la guía se están invocando y dónde están aterrizando los resultados. Y hasta que no fui a mirar esos datos, la guía estaba estática. Había estado estática durante semanas. No porque nadie vigilara las trayectorias, sino porque yo era la única persona que podía vigilarlas, y tenía otras cosas que hacer.

El artículo 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 que vaya desde los datos de trayectoria a las actualizaciones de habilidades, tus habilidades están envejeciendo en el sitio. Puede que aún funcionen para algunos usuarios bajo algunas condiciones. No están mejorando.

La única pregunta es si aceptas que tus habilidades están muertas en el momento en que las publicas, o si construyes el vigilante que las mantiene con vida.

El agregador mínimo viable

Antes de empezar esta publicación, tenía cero agregación de trayectorias sobre mis habilidades. Ninguna. Tenía historial de sesiones que podía leer manualmente, pero nada que sacara a la superficie patrones a través de sesiones. Esa es exactamente la patología de las habilidades estáticas que describe el artículo, y yo la estaba ejecutando.

Esto es lo más pequeño que realmente puedo publicar contra eso ahora mismo, hoy: un único archivo de texto que registre cada invocación de habilidad a través de mis propias sesiones, append-only, con marca de tiempo + nombre de habilidad + 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 es la capa de entrada que necesito antes de siquiera poder ver si mis habilidades tienen modos de falla recurrentes. Sin ella, estoy adivinando. Con ella, al menos puedo escanear el registro a mano cuando reviso una habilidad y preguntarme: ¿esto se rompió de la misma forma tres veces este mes?

Ese es el compromiso. Un archivo. Append-only. Registrado por invocación. Revisado cuando reviso la habilidad.

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 artículo es un evolucionador autónomo completo operando a través de un ecosistema multiusuario. La mía es no estar operando a ciegas.

Preguntas frecuentes

¿Es “OpenClaw” del artículo lo mismo que Claude Code?

No, y tampoco te puedo decir qué es OpenClaw. El resumen menciona “agentes LLM como OpenClaw” como un ejemplo de agente que usa habilidades reutilizables, sin definirlo. No pude identificarlo rápidamente como un producto específico en producción solo a partir del resumen. Lo importante es que el framework SkillClaw del artículo se presenta como una solución general para ecosistemas de agentes multiusuario, no como una solución específica para OpenClaw o Claude Code. Sea lo que sea OpenClaw, el artículo no es un artículo sobre Claude Code, y mis afirmaciones sobre Claude Code en esta publicación son mías, no del artículo.¹

¿Cuál es la contribución realmente novedosa del artículo?

Según el resumen: un framework para la evolución colectiva de habilidades en ecosistemas de agentes multiusuario 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 los patrones en actualizaciones de habilidades en un repositorio compartido que se sincroniza entre usuarios.¹ La novedad no es “las habilidades se pueden mejorar”; eso es obvio. La novedad es proponer que el bucle de mejora debería ser autónomo y guiado por trayectorias, no guiado por humanos.

¿El artículo reporta cifras específicas de mejora?

El resumen 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 las cifras, la fuente es el artículo completo.

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

Un PR es un mecanismo iniciado por humanos. Alguien tiene que notar el problema, escribir el arreglo, abrir el PR, revisarlo, fusionarlo. Cada paso requiere esfuerzo humano. El framework SkillClaw que propone el artículo 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 reportar nada.¹ Si esa versión autónoma es deseable o segura para cualquier ecosistema específico es una pregunta aparte. La contribución del artículo es mostrar que es técnicamente coherente.

¿Esto se aplica a mis habilidades personalizadas de Claude Code?

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

¿Cuál es la conexión con Shokunin?

El planteamiento Shokunin / bucle de calidad sostiene que la maestría surge del delta entre lo que pretendías y lo que realmente ocurrió, llevado al siguiente intento. Las habilidades 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 habilidad. La disciplina es la misma; el mecanismo es distinto.

Referencias