Cómo probar una skill: evals de activación y de resultado

Abre una sesión limpia de Claude Code y escribe una petición que debería activar una de tus skills sin nombrarla. Luego escribe otra que se le parece mucho pero que pertenece a otra skill, o a ninguna. Antes de pulsar Enter, apunta qué esperas que ocurra en cada caso. Si no estás seguro de acertar las dos, esa skill no está probada: funciona en las conversaciones en las que la has visto funcionar, que no es lo mismo.

Quien escribe tests ya conoce esta incomodidad. Lo que cambia con las skills es que hay dos preguntas distintas, y cada una necesita su propio tipo de eval:

• Activación: ante una petición concreta, ¿el agente decide cargar la skill? Esto depende casi por completo de la description del frontmatter.
• Resultado: una vez cargada, ¿el trabajo sale mejor que sin ella? Esto depende del cuerpo del SKILL.md, de las references y de los scripts.

Una skill puede fallar en una y aprobar la otra. Una descripción vaga hace que el mejor contenido del mundo no se lea nunca; una descripción perfecta puede cargar instrucciones que no mejoran nada. En el artículo sobre cómo crear una skill traté la descripción como un problema de activación. Aquí toca medir si ese problema está resuelto.

Para los ejemplos uso skill-creator, la skill de Anthropic para crear y evaluar skills, porque desde marzo de 2026 incluye evals, modo benchmark y comparaciones A/B. Lo que describo de su funcionamiento interno sale de leer su SKILL.md, sus scripts y sus agentes auxiliares, no solo del anuncio.

Evals de activación: los negativos son los que enseñan algo

El formato es mínimo: una lista de consultas, cada una con un should_trigger que dice si la skill debería dispararse. skill-creator propone unas 20, entre 8 y 10 positivas y otras tantas negativas. Para las positivas pide variedad de formulación (formales, informales, sin nombrar la herramienta) y casos en los que la skill compite con otra y debería ganar. Para las negativas insiste en algo que cualquiera que haya escrito tests de validación reconocerá: no sirven los casos obviamente irrelevantes. Según su ejemplo, «escribe una función de Fibonacci» no prueba nada como negativo de una skill de PDF. Los negativos útiles son los near-misses, consultas que comparten vocabulario con la skill pero necesitan otra cosa.

Para concretarlo uso una skill que hemos desarrollado en eLearning Media, illuminate-sql-support (dentro del plugin blackboard-illuminate-sql). Genera, valida y corrige SQL de Snowflake para Blackboard Data / Illuminate, el almacén analítico de ese LMS, a partir de un esquema empaquetado en sus references: la estructura de tablas, un índice plano de columnas válidas (valid-fields.txt), candidatos de relación y ejemplos. Su descripción la limita a siete esquemas (CDM_ALY, CDM_LMS, CDM_TLM y otros) y el cuerpo prohíbe generar consultas contra LEARN, CDM_CRM o CDM_SIS.

Un eval de activación para ella tiene que vivir en la frontera: SQL que no es de Illuminate, Snowflake que no es de Illuminate y Blackboard que no es SQL. Este conjunto es un diseño de ejemplo, no un eval que hayamos ejecutado:

[
  { "query": "Necesito los cursos con más de 50 matriculados este cuatrimestre sacados de Illuminate", "should_trigger": true },
  { "query": "Esta query contra CDM_LMS me da 'invalid identifier', ¿qué columna está mal?", "should_trigger": true },
  { "query": "Cuántos eventos de Ally hubo la semana pasada por tipo de evento", "should_trigger": true },
  { "query": "Optimiza esta consulta de Postgres que hace un CTE recursivo sobre la tabla de categorías", "should_trigger": false },
  { "query": "Escribe una query de Snowflake que agrupe las ventas por región con QUALIFY", "should_trigger": false },
  { "query": "¿Cómo listo los cursos de un usuario con la API REST de Blackboard?", "should_trigger": false }
]

El segundo negativo es el que más enseña. Comparte motor, sintaxis y probablemente la mitad del vocabulario de los positivos, y solo una descripción que ancle la skill a Illuminate y a sus esquemas lo rechaza. Un negativo como «hazme un endpoint de login» no aportaría nada.

Los esquemas excluidos plantean una duda de diseño interesante. Una petición sobre CDM_SIS parece un negativo, pero si la skill no se activa, el modelo improvisará la consulta con lo que sepa del producto, que es justo lo que la skill intenta impedir. Si se activa, sus reglas le dicen que eso queda fuera del modelo soportado. Yo no la pondría en el eval de activación: la probaría como eval de resultado, comprobando que la respuesta no inventa tablas de un esquema excluido.

Un detalle del mecanismo condiciona cómo se escriben. Según la propia skill-creator, el agente solo consulta una skill cuando la tarea no le resulta trivial: una petición de un paso como «lee este PDF» puede no activar nada aunque la descripción encaje perfectamente, porque el modelo la resuelve con sus herramientas básicas. Si las consultas son demasiado simples, el eval mide la tendencia del modelo a resolver solo, no la calidad de la descripción.

Cómo lo ejecuta skill-creator

El script run_eval.py lanza cada consulta con claude -p y comprueba si la skill se ha cargado. Por defecto repite cada consulta tres veces y da el caso por bueno si la tasa de activación supera el 0,5 (o no lo supera, en los negativos). La activación no es determinista, y una consulta que dispara la skill dos de cada tres veces es un dato distinto de una que la dispara siempre.

El bucle de optimización (run_loop.py) va un paso más allá. Divide el conjunto en un 60 % de entrenamiento y un 40 % reservado, pide a Claude que proponga una descripción nueva a partir de los fallos, la reevalúa en ambos conjuntos y repite hasta cinco veces. La mejor descripción se elige por la puntuación en el conjunto reservado, para no sobreajustarla a las veinte frases que has escrito. Es lo mismo que no dar por bueno un fix porque pasa exactamente el test que motivó el cambio.

Anthropic afirma que, al pasar este optimizador por sus skills de creación de documentos, la activación mejoró en 5 de las 6 skills públicas.

Evals de resultado: siempre contra una línea base

La segunda pregunta se responde con evals/evals.json, dentro de la propia skill. Según el esquema de skill-creator, cada caso tiene un prompt, una descripción en lenguaje natural del resultado esperado, ficheros de entrada opcionales y una lista de afirmaciones verificables:

{
  "skill_name": "illuminate-sql-support",
  "evals": [
    {
      "id": 1,
      "prompt": "Cuántos eventos de Ally por tipo hubo en los últimos 7 días",
      "expected_output": "Una consulta agregada sobre CDM_TLM.ALLY_EVENTS filtrada por EVENT_TIME, con el aviso de coste de TLM junto al SQL",
      "files": [],
      "expectations": [
        "Todas las tablas aparecen cualificadas como SCHEMA.TABLE",
        "Todas las columnas usadas existen en references/valid-fields.txt",
        "La consulta filtra por EVENT_TIME",
        "La respuesta incluye el aviso de coste en créditos de las consultas a CDM_TLM",
        "La respuesta no afirma haber ejecutado la consulta"
      ]
    }
  ]
}

El caso es ilustrativo, pero cada afirmación sale de una regla escrita en el SKILL.md: cualificar siempre las tablas, no inventar columnas, filtrar por fecha los datos de eventos de alto volumen, añadir un aviso fijo cuando la consulta toca CDM_TLM y no decir nunca que el SQL se ha validado contra un tenant real, porque la skill no se conecta a ninguno.

La segunda afirmación tiene además una ventaja práctica: no necesita a un modelo para evaluarse. Extraer los identificadores SCHEMA.TABLE.COLUMN del SQL y buscarlos en valid-fields.txt es un script corto, y skill-creator recomienda expresamente hacerlo así cuando se puede.

skill-creator lanza cada caso dos veces en paralelo, cada una en un subagente con contexto limpio: una con la skill y otra como línea base. Si estás creando una skill, la línea base es el mismo prompt sin skill; si estás mejorando una existente, es una copia de la versión anterior. Un subagente evaluador revisa cada salida contra las afirmaciones y un script agrega los resultados en un benchmark con tasa de acierto, tiempo y tokens por configuración, con media, desviación típica y la diferencia entre ambas.

Para comparar dos versiones existe además un comparador ciego, que recibe las dos salidas sin saber cuál es cuál.

Sin línea base, un eval de resultado solo dice que la salida cumple ciertas condiciones. Con ella dice si las cumple gracias a la skill, que es lo que justifica mantenerla.

La aserción que pasa siempre

Para quien ya escribe tests, esta es la parte más útil. El agente analista de skill-creator revisa el benchmark buscando afirmaciones que pasan siempre en las dos configuraciones, porque esas no distinguen nada. El evaluador tiene instrucciones aún más directas: un aprobado sobre una afirmación débil es peor que inútil, porque genera una confianza falsa.

La analogía que mejor me funciona es el mutation testing. Un test que sigue en verde cuando cambias la implementación no está protegiendo esa implementación. Aquí la mutación es quitar la skill entera. Si «la consulta es SQL válido de Snowflake» pasa con y sin skill, la afirmación es cierta y no sirve para nada: mide al modelo, no a tu skill. En el ejemplo anterior espero (es una hipótesis, no un resultado) que la de las columnas discrimine mucho, porque sin el esquema empaquetado el modelo tiene que adivinar nombres, y que la de cualificar tablas discrimine poco. El aviso de TLM es el caso más claro: es un texto que solo existe en la skill, así que la línea base no lo producirá nunca. Esa afirmación siempre discrimina, y por eso mismo dice poco: comprueba que la skill se ha leído, no que la consulta sea buena.

Una afirmación que falla siempre en ambas configuraciones suele indicar un eval mal escrito. Y una que pasa sin skill y falla con ella es la señal más valiosa del benchmark: la skill está empeorando algo.

Lo que no cabe en una aserción

El estilo de una explicación o la calidad de un diseño se evalúan mejor de forma cualitativa. Para eso skill-creator genera un visor en HTML donde una persona recorre las salidas, comenta cada caso y devuelve los comentarios como feedback.json para la siguiente iteración, y pide expresamente que ese visor llegue a un humano antes de que el agente se ponga a corregir la skill.

En qué se diferencia de una suite de tests

La tentación, viniendo de backend, es meter los evals en el pipeline y ejecutarlos en cada commit. No lo haría.

Cada caso de resultado son dos ejecuciones completas de un agente más una de evaluación, y cada consulta de activación se repite varias veces. Un conjunto modesto ya se mide en minutos y en tokens, no en milisegundos. Además está la varianza. Por eso el benchmark da desviación típica y no solo una media: el mismo prompt no produce la misma salida dos veces, y una diferencia de un caso entre dos iteraciones puede ser ruido. Un eval de skill se parece más a un test de carga que a un test unitario: se lee como una distribución.

Y el evaluador también es un modelo. Las afirmaciones que se pueden comprobar con un script deberían comprobarse con un script; skill-creator lo recomienda expresamente porque es más rápido, más fiable y reutilizable entre iteraciones.

Mi criterio es ejecutarlos en tres momentos: cuando cambia la descripción o el contenido de la skill, cuando cambia el modelo con el que trabaja el equipo y cuando cambia lo que la skill documenta (una librería interna que sube de versión, una plataforma que cambia su API). Anthropic sugiere que los resultados pueden conectarse a un sistema de CI; tiene sentido como job manual o programado, no como gate de cada PR.

Cuando cambia el modelo

El anuncio de skill-creator distingue dos tipos de skill, y es la idea más útil de todo el material. Las de aumento de capacidades ayudan al modelo a hacer algo que no sabe hacer, o no de forma consistente. Las de preferencias codificadas ordenan un trabajo que el modelo ya sabe hacer según el proceso de un equipo. Las primeras pueden volverse innecesarias a medida que mejoran los modelos; las segundas duran más, pero solo valen lo que valga su fidelidad al flujo real.

De ahí sale la señal más clara que puede dar un eval: si el modelo empieza a pasar tus evals sin la skill cargada, según Anthropic «la skill no está rota, solo que ya no es necesaria». Por eso la línea base sin skill se sigue ejecutando aunque la skill lleve meses en uso.

La distinción tiene un matiz que el anuncio no menciona. Las skills que empaquetan conocimiento privado o muy específico (un esquema de datos concreto, una librería interna) aportan una capacidad que el modelo no adquiere por mucho que mejore, porque esa información no está en sus datos de entrenamiento o cambia más rápido que ellos. La skill de Illuminate es de este tipo: su valor está en el esquema actual exportado, no en saber escribir SQL. No caduca cuando cambia el modelo; caduca cuando cambia el esquema. En ella, el eval que más rinde es el que detecta deriva entre las references y la base de datos real, y tiene sentido ejecutarlo cada vez que se regenera la exportación. Las skills de convenciones de código o de formato, en cambio, sí están expuestas a que el modelo base acabe haciendo lo mismo por defecto.

Cuando las skills empiezan a pisarse

En mi departamento usamos un marketplace propio para desarrollo con un ciclo de mejora constante: vamos añadiendo skills y comandos nuevos para complementar lo que ya hay. Con ese ritmo, lo que más pesa no es tanto mantener cada skill al día como que el conjunto tenga orden, alguien que lo lidere y una guía que diga qué entra y con qué límites. Sin eso, las skills acaban pisándose entre sí y generando problemas de rendimiento.

Las dos cosas tienen una explicación mecánica. Cada skill instalada añade su nombre y su descripción al contexto de todas las conversaciones, así que cuantas más hay, más texto lee el agente antes de empezar y más candidatas tiene para cada petición. Y cuando dos descripciones cubren el mismo tipo de petición, el agente elige una, a veces la que no toca, o carga las dos y mezcla instrucciones que no estaban pensadas para convivir.

En un marketplace que crece, los evals de activación sirven para algo más que probar una skill aislada. Si cada skill nueva llega con su conjunto de consultas y se ejecutan las de todas con el marketplace completo instalado, registrando qué skills se cargan, una consulta que activa dos skills distintas es un solapamiento que aparece antes de que lo note nadie en el uso diario. Los negativos de una skill nueva, además, deberían incluir los positivos de sus vecinas. Lo planteo como práctica recomendada y no como un resultado que haya medido. El eval no sustituye a la guía ni a quien decide qué entra, pero les da algo concreto que revisar.

Por dónde empezaría

Si tienes un puñado de skills y ningún eval, no empezaría por todas ni por el benchmark completo. Empezaría por las skills cuyo vocabulario se solapa con peticiones que no les corresponden, o con otra skill instalada, escribiendo un eval de activación donde los negativos sean precisamente esas peticiones vecinas. Es el fallo más barato de detectar y el más difícil de ver en el uso diario, porque cuando se carga la skill equivocada la respuesta suele parecer razonable.

Después añadiría tres o cuatro evals de resultado solo en las skills donde un error sale caro, como las de despliegue o las que generan código que toca credenciales, con afirmaciones elegidas por su capacidad de fallar sin la skill. Y guardaría la línea base sin skill como parte fija del conjunto, para que el día que el modelo cambie el benchmark diga qué skills siguen aportando y cuáles se pueden borrar.

En MCP vs skills decía que el mayor riesgo de una skill es producir resultados consistentemente malos; un eval con línea base es la forma más directa de enterarse. Los evals pueden vivir en la carpeta evals/ de cada skill y versionarse con ella; en el artículo sobre cómo organizar skills, comandos y hooks en un plugin está la estructura, y el artículo pilar de la serie sitúa los evals junto al resto de piezas.