Come le skill derivano

Un team lavorava su diversi repository di prodotto. Aveva passato le sessioni di refinement del trimestre precedente a perfezionare la propria skill di review, aggiungendo controlli sulle strategie di rollback delle migrazioni e altre convenzioni concordate in riunione. La skill aggiornata viveva in un solo repository. Copie più vecchie giacevano negli altri, mai aggiornate da quando erano state copia-incollate mesi prima. Un ingegnere entrato nel team dopo quelle sessioni stava revisionando merge request in uno dei repository che conteneva ancora la skill vecchia. La skill sembrava lo standard attuale del team. Era quello del trimestre prima.

Nessuno aveva torto. Il nuovo arrivato eseguiva la versione della skill presente nel repository assegnato. Gli standard erano stati concordati in una stanza e committati in un solo repository. Gli altri conservavano la versione precedente. La pratica corrente viveva nei membri del team presenti in quella stanza. I repository conservavano quella del trimestre prima. Il nuovo arrivato lavorava su quella di ieri.

Non è un problema nuovo. Le config degli editor derivano, le regole di lint derivano, i formatter derivano. Il motivo per cui conta di più con Claude Code è che l'artefatto non è più cosmetico. Una skill cambia il codice che Claude scrive. Un subagent cambia quali strumenti può chiamare. Un hook cambia cosa viene eseguito attorno a ogni chiamata di strumento. Quando i setup del team divergono tra repository, gli output del modello divergono con loro, e lo scopri la prossima volta che il team attraversa i repository.

Perché condividere dotfile qui fallisce

Quattro pattern ricorrono nei team che usano Claude Code su più repository. Presi singolarmente non sorprendono. Quel che sorprende è che hanno tutti la stessa soluzione.

Deriva tra colleghi. La stessa skill, due versioni, nessun diff da confrontare. Le raccomandazioni si contraddicono. Il team lead diventa la fonte di verità umana: la conoscenza è a una sola dimissione di distanza dal dover essere ricostruita.

Costo di onboarding. Un nuovo ingegnere entra a progetto in corso e ricostruisce il setup del team scorrendo la cronologia della chat e chiedendo: "che skill state usando?" Non c'è un bundle canonico da installare. Il primo giorno è artigianale.

Skill legate a un repository di progetto. Una skill utile scritta per il progetto A diventa attrito per il progetto B. Riusarla significa copiare file, sistemare percorsi relativi e ricordarsi quale versione è quella buona. L'infrastruttura IA del team finisce plasmata dal progetto in cui ogni pezzo è stato scritto, non dalla pratica collettiva del team.

Nessuna governance. Qualcuno aggiunge un hook che esegue uno scanner di segreti prima delle scritture su file. Utile. Ma mai revisionato. Due settimane dopo scopri che la regex ha un falso negativo, e un altro collega sta facendo passare valori sensibili senza accorgersene.

Un marketplace di plugin chiude tutti e quattro i problemi. Il marketplace è un repository git. Ogni artefatto vive nel codice, ogni modifica passa dalla review, ogni collega esegue /plugin marketplace update e ottiene le stesse versioni. Il pattern non è nuovo: i team che incontrano questi problemi spesso ne costruiscono una versione fatta in casa (un repo di dotfile condiviso, uno script di setup, un wiki di convenzioni). Il marketplace è il meccanismo formale.

Marketplace vs repository

Ne deriva una separazione netta delle responsabilità. Skill, subagent e hook codificano "come lavora il team" e restano costanti tra i progetti che il team tocca. Il loro posto è nel marketplace: agnostici rispetto al progetto, installati una volta, disponibili ovunque. Le rule codificano "cos'è questo sistema" (lo stack, la struttura dei file, le convenzioni di questo codebase) e il loro posto è nel repository del progetto, nella sua directory .claude/.

L'errore comodo è mettere una skill utile nel repository del progetto in cui ti è capitato di scriverla. La skill smette di essere riutilizzabile, accumula assunzioni specifiche del progetto e impone un copia-incolla quando inizi il progetto successivo. Quando hai due progetti, hai due copie. Derivano l'una dall'altra per lo stesso motivo per cui ogni artefatto condiviso deriva: non c'è una fonte canonica.

Il marketplace previene l'errore dando agli "artefatti di team" una casa diversa dagli "artefatti di progetto". Una skill che vive nel marketplace si usa su ogni codebase su cui il team lavora, senza modifiche. Una rule che vive in un repository di progetto resta dove serve, limitata al sistema che descrive.

Cosa resta umano

Il marketplace dà al team un setup IA versionato e revisionabile. Cosa metterci resta una scelta del team.

Un bundle revisionato batte copie che derivano. Il team può vedere cosa contiene. È questo che gli permette di ragionarci.

Questo argomento non è specifico di Claude. La stessa separazione vale per qualsiasi CLI agentica: convenzioni di team in un bundle versionato e agnostico rispetto al progetto; regole di progetto nel repository. Claude Code è un'implementazione, ergonomica e facile da distribuire. Strumenti come opencode permettono di spingersi oltre instradando parti diverse del workflow verso LLM diversi: un modello più economico per i commit di routine, un reasoner più potente per la review di architettura, un modello locale per il codice sensibile. L'architettura resta la stessa. L'implementazione diventa più granulare e più iper-ottimizzata.

Se il tuo team ha tre o più persone che usano assistenti di coding IA, hai un problema di deriva, che tu l'abbia già chiamato così o no. Pubblica un marketplace. Il guadagno va oltre la coerenza: è un'unica fonte di verità su come lavora il team, accessibile a chiunque sappia eseguire un comando. Quelli che erano quattro assistenti diversi su quattro macchine diverse diventano un unico bundle condiviso. Versionato. Revisionabile. Installato una volta.