In ogni ufficio c’è una persona a cui si mandano le cose «prima di chiudere». Non è scritto da nessuna parte, ma tutti sanno che guarda prima l’autenticazione e poi il resto, che un certo tipo di incidente lo vuole sapere subito e un altro il lunedì, che certi messaggi li scrive in tre righe e basta. Quando cambia lavoro, lascia un documento di passaggio di consegne di due pagine. Il resto, cioè quasi tutto quello che serviva davvero, era sparso in commenti alle revisioni, in thread di chat e in note scritte alle due di notte, e se ne va con lei.
Da questa scena prende il nome il sistema descritto in COLLEAGUE.SKILL: Automated AI Skill Generation via Expert Knowledge Distillation, un paper depositato su arXiv il 29 maggio 2026 (2605.31264) da Tianyi Zhou, Dongrui Liu, Leitao Yuan, Jing Shao e Xia Hu dello Shanghai Artificial Intelligence Laboratory. Il paper arriva dopo il software, non prima: descrive un repository aperto che, alla stesura, contava circa 18.500 stelle su GitHub. Più che un risultato di ricerca, è la documentazione ragionata di un software già pubblico e molto seguito.
Che cosa propone
Le skill stanno diventando, scrivono gli autori, l’unità portabile con cui si insegna un mestiere a un agente: una cartella con un file SKILL.md, metadati in testa e istruzioni sotto, più eventuali script e riferimenti, che l’agente carica solo quando serve. Il formato dice come si impacchetta una competenza. Non dice come si ricava quando la competenza non è mai stata scritta, e sta dispersa nelle tracce di lavoro di qualcuno.
Colleague.skill prova a riempire quel vuoto. Si danno al sistema un nome, qualche campo di profilo e il materiale: messaggi da Slack, Feishu e DingTalk, esportazioni SQLite di WeChat, archivi di posta, PDF, screenshot, Markdown o testo incollato. In uscita c’è un pacchetto che gli autori formalizzano così:
$$S = (A,\, M,\, L)$$
dove $A$ sono i file generati, $M$ i metadati leggibili dalla macchina e le informazioni di installazione, $L$ lo stato del ciclo di vita: versione, data dell’ultimo aggiornamento, numero di correzioni, storia dei ripristini. La formula non ha nulla di profondo, ed è proprio il punto: il paper sposta la domanda dal modello alla cosa che si consegna, un insieme di file che si possono aprire e leggere.
Perché le istruzioni di un agente si impacchettano una volta sola e si tengono in archivio con la loro storia delle modifiche, come il codice (nel gergo del 2026, appunto, skill), e dove stanno nel ciclo di lavoro di un agente: se ne parla nel capitolo sul loop engineering.
Due binari invece di una persona
La scelta di progetto che regge tutto il resto è la divisione in due. Il binario della competenza, work.md, raccoglie procedure, standard tecnici, criteri di revisione, euristiche di decisione, lezioni dal lavoro passato. Il secondo si chiama persona.md, ma gli autori precisano che il suo ruolo è più ristretto di quanto il nome suggerisca: contiene vincoli di comportamento, preferenze di espressione, regole di interazione e il registro delle correzioni. Non un’identità, un insieme di limiti.
La ragione è una diagnosi sui sistemi di «persona»: molti dei loro fallimenti, secondo gli autori, vengono dal mescolare tre cose diverse, cioè conoscenza fattuale, giudizio procedurale e tono superficiale. Separarle in file distinti permette di ispezionarle e invocarle una per volta. Il sistema genera infatti un SKILL.md completo, con la competenza come parte A e il comportamento come parte B, più due sotto-skill che espongono l’una o l’altra da sole, e due file JSON: un manifesto per gli installatori e i metadati del ciclo di vita, secondo uno schema giunto alla terza versione. Nell’esempio del paper, la skill di un revisore serve perché controlla autenticazione, validazione degli input, limiti di frequenza, schema delle risposte ed esposizione di dati sensibili prima delle questioni minori; lo stile è accessorio, e dove trasferirlo non è opportuno si invoca la sola competenza.
Correggere a parole, tornare indietro
Gli autori partono dal presupposto che il pacchetto generato sarà imperfetto, e prevedono fin dall’inizio come ripararlo. L’utente scrive in linguaggio naturale, «questo non lo direbbe», «qui avrebbe obiettato», e il gestore delle correzioni decide dove va a finire. Se riguarda la competenza, produce una patch in Markdown: le sezioni con lo stesso titolo di secondo livello vengono sostituite, quelle nuove aggiunte in coda. Se riguarda il comportamento, produce un record normalizzato a tre campi,
$$(\textit{scene},\ \textit{wrong},\ \textit{correct}),$$
cioè la situazione, la risposta sbagliata e quella giusta. A ogni correzione il sistema archivia la versione corrente, applica la modifica, incrementa il numero di versione e rigenera tutti i file derivati. Le versioni archiviate si possono elencare e ripristinare, e quelle vecchie ripulire. È un’idea da controllo di versione più che da machine learning, e per un artefatto che dovrebbe rappresentare, almeno in parte, il giudizio di qualcuno è l’idea giusta: una correzione può anche peggiorare le cose, e deve restare un modo di tornare indietro.
Il pacchetto finito si installa in più ambienti: gli autori citano Claude Code, OpenClaw, Codex e Hermes. È la conseguenza pratica dell’aver scelto il formato standard delle skill invece di una memoria interna al prodotto: la stessa cartella, dichiarano, si carica con i meccanismi ordinari in qualunque agente che legga quel formato.
Oltre l’ufficio
Il collega è il caso principale, quello che per gli autori ha l’utilità più chiara ed è il più controllabile. Ma il repository definisce tre preimpostazioni, ognuna con il proprio comando: /create-colleague, /create-icon per i personaggi pubblici e /create-ex per le relazioni private. Cambiano le fonti ammesse, i prompt, le regole di consenso; il formato del pacchetto resta lo stesso.
La variante per i personaggi pubblici aggiunge una fase di ricerca su sei dimensioni (scritti in prima persona, interviste, decisioni, stile di espressione, ricezione esterna, cronologia), strumenti per scaricare sottotitoli e trascrivere l’audio, e un controllo di qualità che cerca, fra le altre cose, i modelli mentali, i limiti dichiarati, le tensioni interne e gli URL delle fonti. Gli autori precisano che il controllo non certifica da solo la verità dei fatti: registra i limiti delle prove e permette di abbassare la fiducia dove sono scarse, invece di riempire i vuoti con un personaggio generico.
La variante per le relazioni è quella su cui il paper si fa più cauto. Riconosce tre rischi espliciti, l’attaccamento emotivo eccessivo, la simulazione di qualcuno senza il suo consenso e l’uso improprio di chat private, e la presenta come estensione, «non come un avallo di un uso senza vincoli». Che il comando si chiami /create-ex dice senza giri di parole a quale uso si pensava.
I numeri, e che cosa misurano
Il 28 maggio 2026 gli autori hanno registrato circa 18.500 stelle e 1.800 fork sul repository, 104 commit, e nella galleria pubblica 215 skill, 55 meta-skill e 165 contributori, con oltre 100.000 stelle cumulative sulle schede delle skill elencate. Quest’ultima cifra la riportano solo come ordine di grandezza, perché i contatori della galleria si sincronizzano in modo asincrono e possono essere indietro rispetto a GitHub.
E qui va detta la cosa più importante del paper, che gli autori scrivono loro stessi: questi numeri misurano la diffusione, non la qualità, né l’efficacia sui compiti, né la fedeltà alla persona. Nel testo non c’è un solo esperimento. Nessuna misura di quanti problemi di revisione una skill del collega intercetta rispetto al collega vero, nessun confronto fra la versione completa e quella con la sola competenza, nessuna prova che le correzioni migliorino il comportamento senza introdurre regressioni. Il paper elenca queste domande come «frontiera della fedeltà comportamentale» e le lascia a studi futuri.
I limiti
Il primo è quello appena detto: le affermazioni del lavoro riguardano l’artefatto, cioè che esista un formato, un flusso di generazione e aggiornamento, un’installazione su più ambienti. Se il pacchetto sia utile, non è dimostrato. Il confronto con i vicini è istruttivo: SkillOpt, di cui abbiamo scritto, ottimizza una skill contro un punteggio misurato; SkillsBench misura quanto le skill aiutino davvero; Colleague.skill non ha un verificatore, perché il giudizio di una persona non ne ha uno automatico. È un problema più difficile, e il paper lo dichiara e lo rimanda invece di affrontarlo.
Il secondo è che la correzione umana non è neutrale. Gli autori lo ammettono: le correzioni possono incorporare i pregiudizi di chi le fa, e far sembrare assestate tracce che erano controverse. Chi corregge la skill di un collega che se n’è andato decide, di fatto, che cosa quel collega pensava.
Il terzo riguarda le fonti. Il sistema importa chat, email ed esportazioni di messaggistica, cioè una parte del materiale più personale che circoli in un’azienda. Il paper chiede partecipazione esplicita, raccolta limitata, controlli di accesso, scadenze di conservazione e uso non obbligatorio, e rimanda a una verifica separata la liceità delle fonti, il consenso e l’oscuramento completo dei dati sensibili. Per chi lavora in Europa quella verifica ha un nome preciso, il GDPR, e l’impostazione locale e ispezionabile del pacchetto aiuta, ma non basta da sola: resta da stabilire su quale base si tratta la chat di un collega dopo che ha lasciato l’azienda.
Perché conta adesso
Le skill stanno diventando il pacchetto con cui si distribuisce il comportamento degli agenti, e finora nascevano soprattutto scritte a mano o ricavate dalle traiettorie degli agenti stessi, come in SkillX e SkillGen, che il paper cita; AutoSkill le astrae da dialoghi e interazioni, per agenti personalizzati che imparano nel tempo. Colleague.skill le ricava dalle tracce di una persona precisa, e l’attenzione attorno al repository dice che la domanda esiste, ben prima che qualcuno abbia misurato se funziona. Il merito del paper è aver messo quella domanda in un formato onesto: file leggibili, competenza e stile tenuti separati, correzioni versionate, la possibilità di cancellare tutto. Sulla carta è più ispezionabile di un prompt opaco che «suona come» qualcuno, ed è la tesi stessa degli autori. Ma finché mancano le misure, quello che il pacchetto contiene è un’ipotesi sul giudizio di una persona, scritta da un modello e corretta da un’altra persona. Ed è questo che conviene ricordare prima di affidargli le revisioni del lunedì.
Il codice è su github.com/titanwings/colleague-skill.
I commenti sono riservati agli iscritti.
Accedi per commentare