Quan treballes amb assistents d'IA com Claude Code, arriba un moment en què les teves habilitats (skills) deixen de ser un truc personal i es converteixen en una eina que el teu equip necessita. Al principi ho resols com qualsevol desenvolupador: comprimeixes la carpeta, l'envies per Slack o la comparteixes en un repositori compartit. Però aviat t'adones que aquest ZIP és un problema disfressat de solució. No hi ha versions, no hi ha traçabilitat, i cada còpia manual es converteix en un fork silenciós que ningú sap actualitzar. A Q2BSTUDIO, on desenvolupem aplicacions a mida per a empreses que necessiten precisió i escalabilitat, sabem que la gestió del coneixement tècnic no es pot basar en fitxers solts. La resposta no és un repositori compartit més, sinó un marketplace de plugins amb identitat, versions i un catàleg central. En aquest article t'explico com crear el teu en quinze minuts utilitzant agkit, una eina que elimina la fricció de mantenir un ecosistema de skills professional.
El problema de fons no és tècnic, és conceptual. Quan tens un skill que converteix el teu staged diff en un commit convencional, i l'utilitzes dotze vegades al dia, el natural és compartir-lo. Però en fer-ho, introdueixes un vector de desactualització. Cada persona que el rep treballa sobre una còpia, sense vincle amb l'origen ni manera de saber si té l'última versió. Un repositori compartit amb catorze skills barrejades és com un calaix de sastre: pots clonar-lo, però després has de seleccionar a mà el que necessites, i en aquell mateix moment has creat un fork. Si un altre equip publica un skill excel·lent, et veus obligat a copiar-lo o a demanar al teu equip que cloni un segon repositori. La solució passa per dos elements que la indústria ja té clars: el plugin com a unitat i el marketplace com a catàleg.
El plugin no és simplement una carpeta amb fitxers; és una unitat amb identitat. Té un nom, una versió, un autor i una descripció. S'instal·la, actualitza i desinstal·la com un tot. Claude Code i GitHub Copilot ja modelen les extensions així. El que falta és la infraestructura per crear i mantenir aquest model sense esforç. I aquí entra agkit, una eina que no reinventa res, sinó que fa que l'obvi sigui barat d'implementar. Pensa-hi com el ng d'Angular per a marketplaces de plugins d'agents: un comandament crea un repositori llest per publicar, i uns quants més cobreixen el cicle de vida complet. A Q2BSTUDIO, quan abordem projectes d'intel·ligència artificial o automatització, apliquem exactament aquest principi: la simplicitat de l'eina no ha d'ocultar la complexitat del domini, sinó aplanar-la.
El procés comença amb un scaffold. Amb Node.js 22 o superior, executes npx agkit init dev-toolkit i respons unes preguntes bàsiques: nom, propietari, descripció i remote de git. En segons tens un directori amb un catàleg a .claude-plugin/marketplace.json, una carpeta plugins/ buida, un README amb secció d'instal·lació ja omplerta, un AGENTS.md per al context de l'agent, i fins i tot un flux de CI. El catàleg és un JSON pla amb schema, cosa que permet autocompletat a l'editor i validació des del primer commit. No hi ha build, no hi ha compilació: l'agent el llegeix tal qual. Això significa que pots servir a Claude Code, Copilot, Codex i Cursor des del mateix repositori, perquè tots ells entenen aquest format nadiu. A Q2BSTUDIO, quan integrem serveis cloud AWS o Azure, valorem especialment que una mateixa infraestructura pugui atendre múltiples entorns sense duplicar esforços. Aquí passa exactament això: un catàleg, quatre agents.
Un cop tens l'esquelet, afegeixes el teu primer skill amb agkit add skill commit-crafter. L'eina ofereix diverses plantilles: skill, command, agent, hook i MCP. La plantilla genera dos fitxers (un SKILL.md i un manifest) i registra el plugin al catàleg. El SKILL.md ve amb instruccions d'ompliment; l'important és que el description del front matter és el que Claude llegeix per decidir si carregar el skill, així que convé redactar-lo amb precisió. Substitueixes l'esquelet pel contingut real del teu skill: la lògica per detectar canvis staged, triar el tipus de commit i generar el missatge. El manifest plugin.json és la font de veritat; si després l'edites a mà, només necessites agkit sync perquè el catàleg, el README i l'AGENTS.md s'actualitzin automàticament. Això evita la deriva d'informació, un problema habitual en projectes de Business Intelligence i Power BI on diversos panells depenen de la mateixa font de dades.
Aquí ve el punt que realment diferencia un marketplace d'un calaix desastre: pots referenciar plugins que viuen en repositoris aliens sense copiar ni una línia. Amb agkit add octo-org/changelog-skill changelog --ref v1.2.0, el teu catàleg guanya una entrada que apunta a aquell repositori extern amb un tag fix. El teu equip no descarrega el codi d'aquest plugin; l'obté directament des de la font original en el moment de la instal·lació. No has de mantenir una còpia, no has de rastrejar actualitzacions. Si vols moure la referència a una versió posterior, utilitzes agkit add ... --ref v1.3.0. Si necessites apropiar-te del codi i modificar-lo, utilitzes la bandera --vendor perquè el cloni dins la teva carpeta plugins/. La regla és simple: referència per defecte, clona només quan vulguis posseir. A Q2BSTUDIO, apliquem aquesta mateixa filosofia quan treballem amb llibreries de tercers en projectes de ciberseguretat: integrem allò que està provat sense crear una bifurcació innecessària, però ens reservem el dret de forkear quan el control del codi és crític.
Abans de publicar, valides amb agkit validate. L'eina comprova la validesa JSON, noms en kebab-case, absència de noms reservats, resolució de fonts, existència de manifests i consistència de versions. Si tens el CLI de Claude Code instal·lat, també llança la validació nativa de l'agent. El flux de CI que es va generar a l'inici ja inclou aquest comandament, així que qualsevol pull request amb un catàleg trencat no passarà. Publicar és simplement fer git push. No necessites un registre central ni un token de publicació. El teu equip pot afegir el teu marketplace amb /plugin marketplace add jane/dev-toolkit i instal·lar qualsevol plugin amb /plugin install commit-crafter@dev-toolkit. Si a més copies el examples/team-settings.json generat al directori de configuració de Claude, el marketplace s'afegeix automàticament quan els membres de l'equip confien en el repositori. És a dir, zero passos manuals per als desenvolupadors. Això recorda com a Q2BSTUDIO facilitem l'adopció de automatització de processos: l'orquestració ha de ser invisible per a l'usuari final.
El veritable canvi de paradigma arriba amb el versionatge. Un skill no és una carpeta estàtica; és un producte que evoluciona. Millores el teu commit-crafter perquè detecti canvis breaking, fas commit amb un missatge convencional (feat(commit-crafter): detect breaking changes and add a BREAKING CHANGE footer), i després executes agkit bump commit-crafter --tag. L'eina analitza els commits que toquen aquest directori des de l'últim tag, aplica les regles de conventional commits (feat = minor, fix = patch, feat! = major), escriu el changelog, actualitza la versió al manifest i al catàleg, sincronitza el README i l'AGENTS.md, i fa un commit amb el tag corresponent. Tot en un sol comandament. No has de tocar manualment cap versió ni cap changelog. I com que cada plugin té el seu propi tag (commit-crafter@0.2.0), els releases d'un skill no contaminen els d'un altre. Quan el teu company executa /plugin update, obté exactament aquella versió. Això és el que significa tractar els skills com a programari que es distribueix, no com a fitxers que es comparteixen. A Q2BSTUDIO, quan desenvolupem aplicacions a mida, apliquem el mateix rigor semàntic: cada mòdul té el seu propi cicle de vida i el seu propi versionatge independent.
Hi ha un detall que no has de passar per alt: no pots fer bump sobre un plugin remot referenciat (com el changelog de l'exemple). La seva versió la controla l'autor original. Per moure'l, tornes a pinçar amb agkit add ... --ref nova-versió. Això és correcte, perquè evita que el teu catàleg es converteixi en un gestor de versions upstream. Tu ets el curador, no el mantenidor. I si algun dia decideixes que vols modificar aquest plugin, l'afegeixes amb --vendor i a partir d'aquell moment és teu, amb tot el que comporta. Aquesta distinció entre referència i còpia és la mateixa que apliquem en projectes de cloud híbrid: saps quins serveis consumeixes com a SaaS i quins gestiones tu. La claredat de límits evita maldecaps.
Per tancar el cercle, pensem en l'ecosistema complet. Un marketplace així pot servir a Claude Code, Copilot, Codex i Cursor des d'un sol repositori, sense duplicar contingut de plugins. La clau és que el catàleg és l'únic artefacte font; tot la resta (README, AGENTS.md, registres per a Codex i Cursor) es deriva d'ell mitjançant agkit build o agkit sync. Això garanteix que no hi hagi deriva: el que veus al catàleg és el que s'instal·la. I si el teu equip utilitza forges diferents (GitLab, Bitbucket, Gitea, self-hosted), agkit s'adapta perquè la distribució és simplement git. L'eina no imposa GitHub com a únic canal, cosa que a Q2BSTUDIO valorem en gestionar entorns multicloud on cada client té la seva pròpia política de repositoris.
Al final, el canvi de mentalitat és subtil però profund. Deixes de veure els teus skills com a fitxers que comprimeixes i envies, i comences a veure'ls com a plugins que publiques, verseges i actualitzes. No necessites una plataforma externa ni un compte especial; amb un repositori git i agkit tens tot el necessari. El ZIP era una solució ràpida que es convertia en deute tècnic. El marketplace és una inversió de quinze minuts que paga dividends cada vegada que algú instal·la, actualitza o descobreix un skill. I quan aquest algú et pregunta 'Em passes aquest skill?', ja no respons amb un adjunt, sinó amb una línia de terminal: /plugin install commit-crafter@dev-toolkit. El teu equip t'ho agrairà, i tu deixaràs de ser l'administrador informal d'un calaix desastre per convertir-te en l'editor d'un catàleg que evoluciona amb ordre. Com sempre diem a Q2BSTUDIO, la tecnologia ben estructurada no només resol problemes: elimina la fricció perquè l'equip pugui centrar-se en allò que realment importa.
