Agent skills: com un equip de desenvolupament converteix el seu coneixement en skills d'IA

Ara mateix, les skills són la manera més barata que té un equip d’aconseguir que un agent d’IA treballi amb el seu coneixement en lloc de fer-ho amb el coneixement mitjà d’internet. No perquè siguin una tecnologia sofisticada, que no ho són, sinó perquè obliguen a escriure el que l’equip sap en un format que l’agent consulta només quan el necessita.

Aquesta és la tesi de la sèrie. La resta són matisos: quan una skill aporta alguna cosa i quan és documentació disfressada, com s’estructura perquè s’activi quan toca, com es prova, quins riscos comporta instal·lar les d’altres i què canvia quan el coneixement que empaquetes és el d’una empresa sencera.

Què és una skill i per què ja no depèn d’una sola eina

Una skill és una carpeta amb un fitxer SKILL.md. Aquest fitxer té una capçalera amb un nom i una descripció, i un cos en Markdown amb instruccions. Opcionalment, la carpeta inclou fitxers de referència, scripts i altres recursos.

El que la diferencia d’un prompt llarg és com es carrega. Al principi, l’agent només veu el nom i la descripció de cada skill disponible. Quan una petició encaixa amb una descripció, llegeix el SKILL.md; i només si la tasca ho requereix, obre les referències que aquest fitxer li indica. Pots tenir desenes de skills instal·lades sense omplir el context, perquè gairebé tot el seu contingut no es llegeix mai en una conversa concreta.

Anthropic va publicar el format com a estàndard obert a agentskills.io a finals del 2025, i des d’aleshores l’han adoptat eines d’altres fabricants: Codex d’OpenAI, GitHub Copilot, Gemini CLI, Cursor o VS Code, entre d’altres. Per a un equip, això canvia el càlcul. Escriure una skill ja no és apostar per un proveïdor; és escriure un fitxer Markdown que diversos agents saben llegir.

Ho he comprovat amb un cas propi. La skill d’Illuminate que hem desenvolupat a eLearning Media, que ajuda a generar i validar SQL per a Blackboard Data, s’empaqueta com a plugin de Codex. El SKILL.md és el mateix que llegiria Claude Code; l’únic específic de cada eina és l’empaquetatge que l’envolta. De moment no hi ha enllaç d’instal·lació perquè ChatGPT no accepta skills noves; quan ho faci, o quan sigui en un repositori públic, la informació estarà a Consultas SQL para Blackboard (web en castellà).

Si véns de MCP, la diferència està desenvolupada a MCP vs Skills. En una frase: MCP dona a l’agent eines per actuar sobre sistemes, i una skill li dona criteri sobre com fer una feina.

Quan surt a compte una skill

No tot el coneixement mereix una skill. Si el model ja fa bé una tasca genèrica, com resumir un document o escriure un test unitari corrent, una skill que l’hi expliqui només afegeix text per llegir.

Una skill surt a compte quan conté alguna cosa que el model no pot endevinar. En la d’Illuminate és evident: l’esquema de Blackboard Data no és a les dades d’entrenament amb el detall necessari, i un model sense ajuda s’inventa taules i columnes amb una seguretat absoluta. La skill porta l’esquema, l’índex de camps vàlids, les relacions candidates entre taules i una regla explícita de no inventar res que no hi sigui. El seu valor és acotar el terreny; SQL, el model ja en sap escriure.

En un equip de desenvolupament passa el mateix amb les convencions internes, les llibreries pròpies, els procediments de desplegament o la manera d’estructurar un projecte. És coneixement que existeix, que sol estar repartit entre el cap de la gent i documents que ningú no llegeix, i que cap model no porta de sèrie. Ja vaig escriure sobre aquest ús a skills com a documentació viva d’un equip, centrat en què posar i què no posar en una skill.

L’error contrari també existeix, i l’hem comès bastants vegades: crear skills per a processos d’empresa que el que necessitaven era estar definits o automatitzats. Una skill a sobre d’un procés confús no l’aclareix, i una skill per a una seqüència fixa fa amb un agent el que faria millor un script. Com distingir els tres casos ho explico a quan no crear una skill.

Com es construeix una skill que funciona

Escriure el SKILL.md porta deu minuts. Que l’agent l’utilitzi quan toca i no l’utilitzi quan no, bastant més.

El primer problema és l’activació, i depèn gairebé del tot de la descripció. Una descripció vaga fa que la skill no s’activi mai o que s’activi on no hi té res a fer. El segon és l’estructura: una skill que ho posa tot en un fitxer obliga l’agent a llegir centenars de línies per a qualsevol pregunta. El patró que millor ens funciona és un SKILL.md curt que actua com a router i diu a l’agent quina referència ha d’obrir per a cada necessitat. Tot això, amb la skill d’Illuminate com a exemple que evoluciona versió a versió, és a com crear una skill que funcioni.

Abans d’escriure cal decidir d’on surt el contingut. Poques skills s’escriuen des de zero; gairebé totes destil·len alguna cosa que ja existeix: un Custom GPT, un CLAUDE.md, la documentació d’un fabricant, l’operativa d’algú que fa anys que porta un procés. La d’Illuminate va néixer d’un Custom GPT, i un dels seus fitxers encara ho diu. Aquest procés de destil·lar, i el que es perd pel camí, és a com destil·lar el coneixement d’un equip en skills.

De skills soltes a un plugin d’equip

Quan un equip passa d’una skill a diverses, apareix la pregunta de com distribuir-les i mantenir-les. Al meu equip fem servir un plugin intern de Claude Code amb skills i comandes, distribuït a través d’un marketplace del departament. El contingut no el puc publicar, però sí com es reparteix la feina entre les peces que pot tenir un plugin.

Les skills donen criteri i l’agent decideix quan fer-les servir. Les comandes encadenen passos en un ordre fix quan una persona les invoca. Els hooks s’executen sempre, sense que ho decideixi l’agent: si una regla no es pot saltar, com passar el linter després d’editar un fitxer, no hauria de dependre que l’agent se’n recordi. Aquesta separació, amb exemples, és a skills, comandes i hooks en un plugin d’equip.

Provar una skill

Una skill sense proves és una suposició sobre com es comportarà el model. Hi ha dues coses per comprovar: si s’activa amb les peticions que li corresponen i no amb les altres, i si el resultat amb la skill és millor que sense.

La segona comprovació és la que acostuma a faltar. Una comprovació que passa igual amb skill i sense no demostra res, i una skill el resultat de la qual no millora la línia base sobra, per ben escrita que estigui. Com dissenyar aquestes evals, quines eines hi ha i què fer quan canvia el model ho explico a com provar una skill.

Què t’emportes quan instal·les la skill d’un altre

Una skill és text que l’agent obeeix, i de vegades ve amb scripts. Instal·lar-ne una d’un marketplace sense llegir-la equival a executar instruccions d’un desconegut amb els permisos de la teva sessió. Les anàlisis publicades aquest any sobre skills de registres públics troben problemes de seguretat en una part rellevant d’aquestes skills, i la injecció amagada en fitxers de referència és el patró més habitual.

Què cal revisar, com s’amaga una injecció i per què la revisió no substitueix limitar permisos és a seguretat de skills de tercers. El problema de fons és el mateix que amb MCP, que vaig tractar a MCP en una empresa: el problema són els permisos.

Més enllà del codi: processos i empresa

Les skills van començar com una cosa de desenvolupadors, però el patró serveix per a qualsevol coneixement procedimental. Dos articles de la sèrie surten de l’editor.

El primer aplica skills i comandes a un problema clàssic: modernitzar una aplicació legacy. Demanar a un agent que reescrigui un sistema antic produeix codi que compila i perd regles de negoci pel camí. El nostre mètode inverteix l’ordre: primer es documenta el sistema i algú de l’equip valida aquesta documentació, i només després s’escriu la versió nova. És a modernitzar codi legacy amb IA.

El segon és més ampli: què vol dir digitalitzar una empresa amb IA quan les dades d’adopció a Espanya diuen coses molt diferents segons qui pregunti, i per on començaria jo. A la feina fem servir cada vegada menys n8n perquè amb IA un script surt en minuts i, dockeritzat, es desplega com qualsevol servei. Aquest canvi de cost és, per a mi, més important que qualsevol agent autònom. És a digitalitzar una empresa amb IA.

Per on començar

Si el teu equip no té cap skill, no començaria per un plugin ni per un marketplace. Començaria per una sola skill sobre el coneixement que més vegades expliqueu a mà: la llibreria interna que tothom fa servir malament, el procediment de desplegament que només coneixen dues persones o l’esquema de dades sobre el qual el model s’inventa taules. Amb la descripció ben escrita, un router si el contingut ho demana i tres o quatre evals per saber si aporta alguna cosa.

Si aquesta primera skill funciona, la resta de la sèrie et serveix per escalar. Si no funciona, el més probable és que el problema sigui a la descripció o que el model ja sabés fer aquesta tasca sense ajuda, i totes dues coses es veuen a les evals abans que en producció.