Com provar una skill: evals d'activació i de resultat

Obre una sessió neta de Claude Code i escriu una petició que hauria d’activar una de les teves skills sense anomenar-la. Després n’escriu una altra que s’hi assembla molt però que pertany a una altra skill, o a cap. Abans de prémer Enter, apunta què esperes que passi en cada cas. Si no estàs segur d’encertar-les totes dues, aquesta skill no està provada: funciona en les converses en què l’has vista funcionar, que no és el mateix.

Qui escriu tests ja coneix aquesta incomoditat. El que canvia amb les skills és que hi ha dues preguntes diferents, i cadascuna necessita el seu propi tipus d’eval:

• Activació: davant d’una petició concreta, l’agent decideix carregar la skill? Això depèn gairebé del tot de la description del frontmatter.
• Resultat: un cop carregada, la feina surt millor que sense? Això depèn del cos del SKILL.md, de les references i dels scripts.

Una skill pot fallar en una i aprovar l’altra. Una descripció vaga fa que el millor contingut del món no es llegeixi mai; una descripció perfecta pot carregar instruccions que no milloren res. A l’article sobre com crear una skill vaig tractar la descripció com un problema d’activació. Aquí toca mesurar si aquest problema està resolt.

Per als exemples faig servir skill-creator, la skill d’Anthropic per crear i avaluar skills, perquè des del març del 2026 inclou evals, mode benchmark i comparacions A/B. El que descric del seu funcionament intern surt de llegir-ne el SKILL.md, els scripts i els agents auxiliars, no només de l’anunci.

Evals d’activació: els negatius són els que ensenyen alguna cosa

El format és mínim: una llista de consultes, cadascuna amb un should_trigger que diu si la skill s’hauria de disparar. skill-creator en proposa unes 20, entre 8 i 10 de positives i altres tantes de negatives. Per a les positives demana varietat de formulació (formals, informals, sense anomenar l’eina) i casos en què la skill competeix amb una altra i hauria de guanyar. Per a les negatives insisteix en una cosa que qualsevol que hagi escrit tests de validació reconeixerà: no serveixen els casos òbviament irrellevants. Segons el seu exemple, «escriu una funció de Fibonacci» no prova res com a negatiu d’una skill de PDF. Els negatius útils són els near-misses, consultes que comparteixen vocabulari amb la skill però necessiten una altra cosa.

Per concretar-ho faig servir una skill que hem desenvolupat a eLearning Media, illuminate-sql-support (dins del plugin blackboard-illuminate-sql). Genera, valida i corregeix SQL de Snowflake per a Blackboard Data / Illuminate, el magatzem analític d’aquest LMS, a partir d’un esquema empaquetat a les seves references: l’estructura de taules, un índex pla de columnes vàlides (valid-fields.txt), candidats de relació i exemples. La seva descripció la limita a set esquemes (CDM_ALY, CDM_LMS, CDM_TLM i d’altres) i el cos prohibeix generar consultes contra LEARN, CDM_CRM o CDM_SIS.

Un eval d’activació per a aquesta skill ha de viure a la frontera: SQL que no és d’Illuminate, Snowflake que no és d’Illuminate i Blackboard que no és SQL. Aquest conjunt és un disseny d’exemple, no un eval que hàgim executat:

[
  { "query": "Necessito els cursos amb més de 50 matriculats aquest quadrimestre, tret d'Illuminate", "should_trigger": true },
  { "query": "Aquesta query contra CDM_LMS em dona 'invalid identifier', quina columna està malament?", "should_trigger": true },
  { "query": "Quants esdeveniments d'Ally hi va haver la setmana passada per tipus d'esdeveniment", "should_trigger": true },
  { "query": "Optimitza aquesta consulta de Postgres que fa un CTE recursiu sobre la taula de categories", "should_trigger": false },
  { "query": "Escriu una query de Snowflake que agrupi les vendes per regió amb QUALIFY", "should_trigger": false },
  { "query": "Com llisto els cursos d'un usuari amb l'API REST de Blackboard?", "should_trigger": false }
]

El segon negatiu és el que més ensenya. Comparteix motor, sintaxi i probablement la meitat del vocabulari dels positius, i només una descripció que ancori la skill a Illuminate i als seus esquemes el rebutja. Un negatiu com «fes-me un endpoint de login» no aportaria res.

Els esquemes exclosos plantegen un dubte de disseny interessant. Una petició sobre CDM_SIS sembla un negatiu, però si la skill no s’activa, el model improvisarà la consulta amb el que sàpiga del producte, que és just el que la skill intenta impedir. Si s’activa, les seves regles li diuen que això queda fora del model suportat. Jo no la posaria a l’eval d’activació: la provaria com a eval de resultat, comprovant que la resposta no s’inventa taules d’un esquema exclòs.

Un detall del mecanisme condiciona com s’escriuen. Segons la mateixa skill-creator, l’agent només consulta una skill quan la tasca no li resulta trivial: una petició d’un sol pas com «llegeix aquest PDF» pot no activar res encara que la descripció encaixi perfectament, perquè el model la resol amb les seves eines bàsiques. Si les consultes són massa simples, l’eval mesura la tendència del model a resoldre-ho tot sol, no la qualitat de la descripció.

Com ho executa skill-creator

L’script run_eval.py llança cada consulta amb claude -p i comprova si s’ha carregat la skill. Per defecte repeteix cada consulta tres vegades i dona el cas per bo si la taxa d’activació supera el 0,5 (o no el supera, en els negatius). L’activació no és determinista, i una consulta que dispara la skill dues de cada tres vegades és una dada diferent d’una que la dispara sempre.

El bucle d’optimització (run_loop.py) va un pas més enllà. Divideix el conjunt en un 60 % d’entrenament i un 40 % reservat, demana a Claude que proposi una descripció nova a partir dels errors, la torna a avaluar en tots dos conjunts i ho repeteix fins a cinc vegades. La millor descripció es tria per la puntuació al conjunt reservat, per no sobreajustar-la a les vint frases que has escrit. És el mateix que no donar per bo un fix perquè passa exactament el test que va motivar el canvi.

Anthropic afirma que, en passar aquest optimitzador per les seves skills de creació de documents, l’activació va millorar en 5 de les 6 skills públiques.

Evals de resultat: sempre contra una línia base

La segona pregunta es respon amb evals/evals.json, dins de la mateixa skill. Segons l’esquema de skill-creator, cada cas té un prompt, una descripció en llenguatge natural del resultat esperat, fitxers d’entrada opcionals i una llista d’afirmacions verificables:

{
  "skill_name": "illuminate-sql-support",
  "evals": [
    {
      "id": 1,
      "prompt": "Quants esdeveniments d'Ally per tipus hi ha hagut els últims 7 dies",
      "expected_output": "Una consulta agregada sobre CDM_TLM.ALLY_EVENTS filtrada per EVENT_TIME, amb l'avís de cost de TLM al costat del SQL",
      "files": [],
      "expectations": [
        "Totes les taules apareixen qualificades com a SCHEMA.TABLE",
        "Totes les columnes utilitzades existeixen a references/valid-fields.txt",
        "La consulta filtra per EVENT_TIME",
        "La resposta inclou l'avís de cost en crèdits de les consultes a CDM_TLM",
        "La resposta no afirma haver executat la consulta"
      ]
    }
  ]
}

El cas és il·lustratiu, però cada afirmació surt d’una regla escrita al SKILL.md: qualificar sempre les taules, no inventar columnes, filtrar per data les dades d’esdeveniments d’alt volum, afegir un avís fix quan la consulta toca CDM_TLM i no dir mai que el SQL s’ha validat contra un tenant real, perquè la skill no es connecta a cap.

La segona afirmació té a més un avantatge pràctic: no necessita cap model per avaluar-se. Extreure els identificadors SCHEMA.TABLE.COLUMN del SQL i buscar-los a valid-fields.txt és un script curt, i skill-creator recomana expressament fer-ho així quan es pot.

skill-creator llança cada cas dues vegades en paral·lel, cadascuna en un subagent amb context net: una amb la skill i l’altra com a línia base. Si estàs creant una skill, la línia base és el mateix prompt sense skill; si en millores una d’existent, és una còpia de la versió anterior. Un subagent avaluador revisa cada sortida contra les afirmacions i un script agrega els resultats en un benchmark amb taxa d’encert, temps i tokens per configuració, amb mitjana, desviació típica i la diferència entre totes dues.

Per comparar dues versions hi ha a més un comparador cec, que rep les dues sortides sense saber quina és quina.

Sense línia base, un eval de resultat només diu que la sortida compleix certes condicions. Amb línia base diu si les compleix gràcies a la skill, que és el que justifica mantenir-la.

L’asserció que passa sempre

Per a qui ja escriu tests, aquesta és la part més útil. L’agent analista de skill-creator revisa el benchmark buscant afirmacions que passen sempre en les dues configuracions, perquè aquestes no distingeixen res. L’avaluador té instruccions encara més directes: un aprovat sobre una afirmació feble és pitjor que inútil, perquè genera una confiança falsa.

L’analogia que millor em funciona és el mutation testing. Un test que continua en verd quan canvies la implementació no protegeix aquesta implementació. Aquí la mutació és treure la skill sencera. Si «la consulta és SQL vàlid de Snowflake» passa amb skill i sense, l’afirmació és certa i no serveix per a res: mesura el model, no la teva skill. A l’exemple anterior espero (és una hipòtesi, no un resultat) que la de les columnes discrimini molt, perquè sense l’esquema empaquetat el model ha d’endevinar noms, i que la de qualificar taules discrimini poc. L’avís de TLM és el cas més clar: és un text que només existeix a la skill, així que la línia base no el produirà mai. Aquesta afirmació sempre discrimina, i precisament per això diu poc: comprova que s’ha llegit la skill, no que la consulta sigui bona.

Una afirmació que falla sempre en totes dues configuracions sol indicar un eval mal escrit. I una que passa sense skill i falla amb la skill és el senyal més valuós del benchmark: la skill està empitjorant alguna cosa.

El que no cap en una asserció

L’estil d’una explicació o la qualitat d’un disseny s’avaluen millor de manera qualitativa. Per a això skill-creator genera un visor en HTML on una persona recorre les sortides, comenta cada cas i retorna els comentaris com a feedback.json per a la iteració següent, i demana expressament que aquest visor arribi a un humà abans que l’agent es posi a corregir la skill.

En què es diferencia d’una suite de tests

La temptació, venint del backend, és posar els evals a la pipeline i executar-los a cada commit. No ho faria.

Cada cas de resultat són dues execucions completes d’un agent més una d’avaluació, i cada consulta d’activació es repeteix diverses vegades. Un conjunt modest ja es mesura en minuts i en tokens, no en mil·lisegons. A més, hi ha la variància. Per això el benchmark dona desviació típica i no només una mitjana: el mateix prompt no produeix la mateixa sortida dues vegades, i una diferència d’un cas entre dues iteracions pot ser soroll. Un eval de skill s’assembla més a un test de càrrega que a un test unitari: es llegeix com una distribució.

I l’avaluador també és un model. Les afirmacions que es poden comprovar amb un script s’haurien de comprovar amb un script; skill-creator ho recomana expressament perquè és més ràpid, més fiable i reutilitzable entre iteracions.

El meu criteri és executar-los en tres moments: quan canvia la descripció o el contingut de la skill, quan canvia el model amb què treballa l’equip i quan canvia el que la skill documenta (una llibreria interna que puja de versió, una plataforma que canvia la seva API). Anthropic suggereix que els resultats es poden connectar a un sistema de CI; té sentit com a job manual o programat, no com a gate de cada PR.

Quan canvia el model

L’anunci de skill-creator distingeix dos tipus de skill, i és la idea més útil de tot el material. Les d’augment de capacitats ajuden el model a fer una cosa que no sap fer, o no de manera consistent. Les de preferències codificades ordenen una feina que el model ja sap fer segons el procés d’un equip. Les primeres poden esdevenir innecessàries a mesura que milloren els models; les segones duren més, però només valen el que valgui la seva fidelitat al flux real.

D’aquí surt el senyal més clar que pot donar un eval: si el model comença a passar els teus evals sense la skill carregada, segons Anthropic «la skill no està trencada, només és que ja no és necessària». Per això la línia base sense skill es continua executant encara que la skill faci mesos que s’utilitza.

La distinció té un matís que l’anunci no esmenta. Les skills que empaqueten coneixement privat o molt específic (un esquema de dades concret, una llibreria interna) aporten una capacitat que el model no adquireix per molt que millori, perquè aquesta informació no és a les seves dades d’entrenament o canvia més de pressa que elles. La skill d’Illuminate és d’aquest tipus: el seu valor és en l’esquema actual exportat, no en saber escriure SQL. No caduca quan canvia el model; caduca quan canvia l’esquema. En aquesta skill, l’eval que més rendeix és el que detecta deriva entre les references i la base de dades real, i té sentit executar-lo cada vegada que es regenera l’exportació. Les skills de convencions de codi o de format, en canvi, sí que estan exposades al fet que el model base acabi fent el mateix per defecte.

Quan les skills comencen a trepitjar-se

Al meu departament fem servir un marketplace propi per a desenvolupament amb un cicle de millora constant: anem afegint skills i comandes noves per complementar el que ja hi ha. Amb aquest ritme, el que més pesa no és tant mantenir cada skill al dia com que el conjunt tingui ordre, algú que el lideri i una guia que digui què hi entra i amb quins límits. Sense això, les skills acaben trepitjant-se entre si i generant problemes de rendiment.

Totes dues coses tenen una explicació mecànica. Cada skill instal·lada afegeix el seu nom i la seva descripció al context de totes les converses, així que com més n’hi ha, més text llegeix l’agent abans de començar i més candidates té per a cada petició. I quan dues descripcions cobreixen el mateix tipus de petició, l’agent en tria una, de vegades la que no toca, o carrega totes dues i barreja instruccions que no estaven pensades per conviure.

En un marketplace que creix, els evals d’activació serveixen per a alguna cosa més que provar una skill aïllada. Si cada skill nova arriba amb el seu conjunt de consultes i s’executen les de totes amb el marketplace complet instal·lat, registrant quines skills es carreguen, una consulta que activa dues skills diferents és un solapament que apareix abans que ningú se n’adoni en l’ús diari. Els negatius d’una skill nova, a més, haurien d’incloure els positius de les seves veïnes. Ho plantejo com a pràctica recomanada i no com un resultat que hagi mesurat. L’eval no substitueix la guia ni qui decideix què hi entra, però els dona alguna cosa concreta per revisar.

Per on començaria

Si tens un grapat de skills i cap eval, no començaria per totes ni pel benchmark complet. Començaria per les skills el vocabulari de les quals se solapa amb peticions que no els corresponen, o amb una altra skill instal·lada, i escriuria un eval d’activació on els negatius fossin precisament aquestes peticions veïnes. És l’error més barat de detectar i el més difícil de veure en l’ús diari, perquè quan es carrega la skill equivocada la resposta sol semblar raonable.

Després afegiria tres o quatre evals de resultat només a les skills on un error surt car, com les de desplegament o les que generen codi que toca credencials, amb afirmacions triades per la seva capacitat de fallar sense la skill. I guardaria la línia base sense skill com a part fixa del conjunt, perquè el dia que canviï el model el benchmark digui quines skills continuen aportant i quines es poden esborrar.

A MCP vs skills deia que el risc més gran d’una skill és produir resultats consistentment dolents; un eval amb línia base és la manera més directa d’assabentar-se’n. Els evals poden viure a la carpeta evals/ de cada skill i versionar-se amb ella; a l’article sobre com organitzar skills, comandes i hooks en un plugin hi ha l’estructura, i l’article pilar de la sèrie situa els evals al costat de la resta de peces.