Il Paradosso delle AI Skills Condivise: 38.000+ Stelle, Ma Cosa C'e' Dentro?

38.000+ stelle su GitHub. Centinaia di file .cursorrules. Migliaia di fork. Un ecosistema intero di directory, marketplace e aggregatori che indicizzano mezzo milione di "AI skills" pronte all'uso.

La promessa e' semplice: copia questo file nel tuo progetto e l'AI scrivera' codice migliore. Come una ricetta magica. Come un cheat code. Qualcuno ha gia' distillato l'expertise, tu devi solo incollare.

Ma se apri quei file e li leggi davvero — riga per riga, con occhio critico — quello che trovi racconta una storia diversa. Una storia di copie, di banalita' mascherate da conoscenza, e di un paradosso che nessuno vuole affrontare: le skill veramente preziose non sono li'. E probabilmente non lo saranno mai.

Il boom della condivisione

L'esplosione e' iniziata nel settembre 2024 con awesome-cursorrules — una raccolta di file .cursorrules su GitHub. In poco piu' di un anno e mezzo, 38.000+ stelle e oltre 3.300 fork. Un fenomeno.

Ma non e' l'unico. L'ecosistema si e' moltiplicato in fretta.

Piattaforma	Tipo	Dimensione
awesome-cursorrules	Raccolta .cursorrules	38.000+ stelle, centinaia di file
cursor.directory	Community hub	Migliaia di regole, chiunque puo' sottomettere
awesome-copilot	Raccolta ufficiale GitHub	175+ agents, 208+ skills, 176+ instructions
steipete/agent-rules	Regole cross-tool	5.600+ stelle (archiviato dic 2025)
SkillsMP	Aggregatore	500.000+ skills indicizzate (claim)

SkillsMP da solo dichiara mezzo milione di skill indicizzate. Skly ha lanciato un marketplace con pagamenti via Stripe. Cursor ha integrato un marketplace nel tool. Anthropic ha pubblicato un repo ufficiale con 17 skills di riferimento e un formato standard SKILL.md.

La barriera d'ingresso e' zero. Non serve essere esperti. Non serve nemmeno sapere cosa stai condividendo. Basta un file Markdown e un push su GitHub.

E qui iniziano i problemi.

Cosa c'e' davvero in quei file

Un gruppo di ricercatori ha fatto quello che pochi si erano presi la briga di fare: aprire quei file e analizzarli sistematicamente.

Il paper "Beyond the Prompt" — pubblicato su arXiv — ha esaminato 401 repository con 1.876 file .mdc. I risultati sono istruttivi.

Il 28.7% delle righe e' duplicato tra repository diversi. Quasi un terzo del contenuto e' copiato. Non "ispirato da", non "simile a". Copiato. 19.917 righe che compaiono identiche in repository diversi.

Ma il dato piu' interessante e' la tassonomia. I ricercatori hanno classificato il contenuto in cinque categorie:

Project (85% dei repo): stack tecnologico, architettura
Convention (84%): stile codice, pratiche del linguaggio
Guideline (89%): quality assurance, design patterns
LLM Directive (50%): istruzioni comportamentali per il modello
Example (50%): dimostrazioni pratiche

Solo il 50% dei file contiene direttive specifiche per LLM. L'altra meta' e' documentazione generica. Non istruzioni per l'AI — roba che staresti benissimo in un README o in un wiki interno. "Usa TypeScript strict mode." "Preferisci composizione a ereditarieta'." "Scrivi test per ogni funzione."

E solo il 37% include tutte e quattro le categorie core in modo completo. Il resto e' parziale, frammentario, incompleto.

L'AI sa gia' queste cose

Ecco il punto che nessuno dice ad alta voce.

Quando scrivi una regola che dice "usa TypeScript in strict mode", stai dicendo a Claude — un modello addestrato su milioni di repository TypeScript — qualcosa che sa gia'. Non stai aggiungendo conoscenza. Stai aggiungendo rumore nel contesto.

Quando scrivi "preferisci composizione a ereditarieta'", stai ripetendo un principio che l'AI ha visto in migliaia di libri di design patterns, centinaia di migliaia di discussioni su Stack Overflow, milioni di righe di codice che seguono esattamente quel pattern.

E' come spiegare a un pianista diplomato al conservatorio che il Do e' il tasto bianco a sinistra dei due tasti neri. Informazione tecnicamente corretta. Completamente inutile.

Un developer su Hacker News l'ha messa giu' in modo brutale:

"Gli LLM hanno una memoria e capacita' di astrazione di merda e aggiungere file md e piu' contesto e' come cercare di far imparare il piano a un paziente di Alzheimer."

Esagerato? Forse. Ma coglie un punto reale: le best practice generiche non sono il collo di bottiglia. L'AI non sbaglia perche' non conosce SOLID. Sbaglia perche' non conosce il TUO progetto — le tue convenzioni, i tuoi trade-off, le decisioni che hai preso tre anni fa e che oggi nessuno ricorda il perche'.

Il 90% che non si esporta

La letteratura sul knowledge management dice una cosa scomoda: il 90% della conoscenza organizzativa e' tacita. Non codificabile. Non trasferibile in un file.

E' quella sensazione che hai quando un junior propone un refactoring "elegante" di un modulo e tu sai — senza poterlo spiegare in due frasi — che quella soluzione si romperebbe in produzione sotto carico. Non e' una regola. E' pattern recognition costruita su anni di errori.

E' il "judgment" — la capacita' di decidere quando una best practice NON si applica. Quando violare la regola. Quando il trade-off giusto e' quello che nessun libro raccomanderebbe.

Lo studio di JUXT sui paradossi dell'AI-assisted engineering lo articola bene: le decisioni di design, la valutazione estetica, l'architettura — non sono automatizzabili. Un senior che condividesse DAVVERO tutto il suo sapere in un file dovrebbe codificare non solo le regole, ma anche le eccezioni alle regole, le eccezioni alle eccezioni, e il giudizio su quando applicare ciascuna.

Il paper "Codified Context" su arXiv mostra quanto lavoro serve per provarci. Un singolo sviluppatore ha costruito un sistema di contesto per un progetto da 108.000 righe di C#. Il risultato:

660 righe di "constitution" (memoria sempre attiva)
19 agenti specializzati con circa 9.300 righe di specifiche
34 documenti di knowledge base per altre 16.250 righe
Totale: 26.200 righe di contesto per 108.000 righe di codice — un rapporto del 24%
Testato su 283 sessioni di sviluppo, 2.801 prompt, 1.197 invocazioni agente

Confrontalo con una .cursorrules copiata da awesome-cursorrules: 50-200 righe generiche, zero manutenzione, zero test, applicabile a qualsiasi progetto — cioe' a nessuno in particolare.

La citazione chiave dell'autore: "Un prototipo da 1.000 righe puo' essere descritto in un singolo prompt, ma un sistema da 100.000 righe no."

Le skill che funzionano davvero

Allora le skill sono tutte inutili? No. Ma quelle che funzionano hanno caratteristiche precise. E sono quasi sempre quelle che NON trovi nei marketplace.

Le skill efficaci sono contestuali al progetto. Non dicono "usa TypeScript strict mode" — dicono "il nostro API layer usa Zod per la validazione degli input, ogni endpoint ha un file .schema.ts nella stessa directory, i tipi generati vanno in src/types/generated/". Non pretendono di essere expertise universale. Sono "ecco come funziona QUESTO progetto".

Il paper su arXiv lo conferma indirettamente: la categoria con piu' impatto e' "Project" — stack tecnologico, architettura, convenzioni specifiche. Non le best practice generiche che l'AI conosce gia', ma le decisioni idiosincratiche che nessun modello puo' indovinare.

Anthropic stessa, nella documentazione di Claude Code, suggerisce lo stesso approccio: il CLAUDE.md deve contenere le convenzioni del team, i comandi di build, la struttura delle directory, i pattern architetturali scelti. Non un trattato sulle best practice di programmazione.

I developer senior su Hacker News li chiamano "cerotti" — e hanno ragione, ma nel senso che un cerotto sul punto giusto puo' salvare una situazione. Il template del commit message del team. Lo script di deploy. La convenzione sui nomi delle branch. Le regole di naming del database. Roba noiosa, specifica, impossibile da generalizzare. Ed e' per questo che funziona.

Il mercato dei limoni

C'e' un concetto in economia — il "mercato dei limoni" di Akerlof — che descrive perfettamente quello che sta succedendo.

In un mercato dove i compratori non possono distinguere la qualita' prima dell'acquisto, i venditori di prodotti buoni escono dal mercato (non riescono a far pagare il prezzo giusto) e restano solo quelli di prodotti scadenti. Il mercato si riempie di "limoni" — macchine usate difettose, nell'esempio originale.

Le AI skills condivise sono un mercato dei limoni perfetto. Chi ha expertise reale non la condivide — e' il suo vantaggio competitivo, e' troppo specifica per essere trasferibile, e richiederebbe il suo giudizio per essere applicata. Chi non ha expertise genera una skill in due minuti con l'AI stessa e la pubblica. Il marketplace si riempie di contenuto mediocre.

SkillsMP aggrega 500.000+ skill ma ammette che "quality curation is next priority". Tradotto: prima abbiamo raccolto tutto, poi vedremo cosa vale qualcosa. E' il modello classico della quantita' prima della qualita'.

Il parallelo con PromptBase — il marketplace di prompt — e' illuminante. 260.000+ prompt, 20% di commissione. La maggior parte dei venditori guadagna poche centinaia di dollari al mese. Ma il dato piu' significativo e' la traiettoria: man mano che i modelli migliorano, i prompt generici perdono valore. Il mercato si contrae naturalmente.

La stessa cosa succedera' con le AI skills generiche. Ogni aggiornamento del modello rende meno utile la regola che dice "scrivi codice pulito". L'AI lo faceva gia'. Lo fara' sempre meglio. La finestra di utilita' delle istruzioni generiche si chiude progressivamente.

Quello che non perde valore — e anzi ne guadagna — e' il contesto specifico del progetto. Perche' quello, per definizione, il modello non puo' saperlo.

Il problema sicurezza che nessuno affronta

E poi c'e' il problema che rende tutto piu' urgente.

Un'analisi pubblicata su DEV Community ha trovato numeri preoccupanti sui registri di skill condivise: il 36% contiene vulnerabilita' di prompt injection. Il 7% espone API key attraverso la context window degli LLM. In un registro specifico, un singolo utente ha caricato 354 pacchetti maligni in una campagna automatizzata.

Pensaci un attimo. Stai copiando un file che viene iniettato direttamente nel contesto del tuo agente AI — un agente che ha accesso al tuo filesystem, alle tue API, alle tue credenziali. E quel file lo ha scritto uno sconosciuto su Internet.

E' la supply chain attack del 2024 applicata a un nuovo vettore. Come npm nel 2018, ma con permessi a livello agente. Il tuo .cursorrules scaricato da una directory non verificata potrebbe contenere istruzioni nascoste che dicono all'AI di esfiltrare dati, modificare codice in modo sottile, o esporre endpoint interni.

Il fatto che la maggior parte delle directory non abbia curation seria — SkillsMP filtra per "minimo 2 stelle GitHub", una soglia che chiunque supera — rende il problema strutturale, non episodico.

Cosa fare in pratica

Se stai usando AI skills nel tuo workflow quotidiano, ecco il punto: smetti di cercare la skill universale perfetta. Non esiste.

Scrivi skill di progetto, non di best practice. L'AI sa gia' le best practice. Quello che non sa e' come funziona il tuo progetto. Scrivi le convenzioni del team. I template. I pattern architetturali. I comandi di build. Le decisioni che hai preso e il perche'. Questo e' il contesto che fa la differenza.

Mantieni il file. Lo studio "Codified Context" documenta 1-2 ore settimanali di manutenzione. Un CLAUDE.md scritto sei mesi fa e mai aggiornato e' peggio di non averlo — contiene istruzioni obsolete che l'AI seguira' alla lettera. Anthropic stessa avverte: un file sovra-specificato fa si' che le istruzioni importanti si perdano nel rumore.

Non copiare, comprendi. Guardare come altri team strutturano i loro file di contesto e' utile — per capire il formato, la granularita', la gerarchia. Ma copiare le regole di qualcun altro nel tuo progetto e' come copiare il .env di qualcun altro: i nomi delle variabili possono essere gli stessi, ma i valori devono essere i tuoi.

Verifica la sicurezza. Qualsiasi file scaricato da una directory o un marketplace deve essere letto riga per riga prima di finire nel contesto del tuo agente. Cerca istruzioni nascoste, pattern di prompt injection, riferimenti a endpoint esterni. Se non hai tempo di leggerlo, non usarlo.

Costruisci contesto gerarchico. Il paper "Codified Context" suggerisce una struttura a tre livelli: hot memory (sempre attiva, le regole fondamentali), agenti specializzati (invocati per dominio specifico), cold memory (disponibile su richiesta). Non tutto deve essere nel contesto sempre. L'AI ha una context window limitata — usala per quello che serve davvero.

Il paradosso si risolve cosi': le AI skills piu' utili sono quelle che non condividerai mai, perche' hanno senso solo nel tuo progetto, con il tuo team, per le tue decisioni architetturali. E vanno bene cosi'. Non tutto deve essere open source. Non tutto deve essere un marketplace. A volte il valore sta proprio nel fatto che e' specifico, locale, non trasferibile.

L'expertise non si esporta. Si applica.

Fonti: