Più di 178.000 utenti di GitHub hanno messo una stella a un singolo file markdown. Il file si limita a spiegare a un'AI come comportarsi.
Quattro regole: pensa prima di scrivere codice. Prima la semplicità. Modifiche chirurgiche. Esecuzione guidata dagli obiettivi. Tutto qui. Nessuna libreria. Nessun framework. Nessun installer. Forrest Chang ha racchiuso le osservazioni di Andrej Karpathy sui pattern di fallimento dei LLM nella scrittura di codice in un unico file CLAUDE.md, e la comunità di sviluppatori lo ha spinto oltre le 178.000 stelle su GitHub nei mesi successivi.
Se osservi bene cosa è successo lì, assomiglia molto a ciò che ogni organizzazione di ingegneria ha capito di avere bisogno, prima o poi, dopo abbastanza sofferenza: un insieme condiviso di vincoli su come viene scritto il codice. Un livello di regole. Il tipo di cosa che un tempo viveva in una checklist di revisione del codice, in una guida di stile o nella memoria istituzionale di un ingegnere senior. La comunità del vibe coding ha trovato una versione molto più leggera di quella stessa disciplina: scrivi le regole in markdown e lascia che l'agente le legga prima di scrivere codice.
Non è un caso isolato. È un pattern.
Riassunto rapido
- L'ecosistema delle istruzioni per gli agenti (CLAUDE.md, AGENTS.md, librerie di skill condivise e agenti per l'accessibilità) sta diventando un livello distribuito di enforcement della qualità per la programmazione assistita dall'AI.
- Il divario di qualità a cui risponde è reale: Snyk ha analizzato 3.984 skill da ClawHub e skills.sh e ha scoperto che 1.467, ovvero il 36,82%, avevano almeno un difetto di sicurezza; 534, ovvero il 13,4%, avevano almeno un problema di livello critico.
- La risposta della comunità è stata costruire più regole, non abbandonare l'approccio, e ora sono coinvolte istituzioni che vanno da Vercel a OWASP fino alla Linux Foundation.
Il divario di qualità è reale, e la comunità lo sa
Il 13,4% dei file di skill della comunità contiene difetti di sicurezza critici. È quanto emerge dal report ToxicSkills di Snyk, pubblicato a febbraio 2026 dopo l'analisi di 3.984 skill da ClawHub e skills.sh. Il 36,82% aveva almeno una vulnerabilità di sicurezza. 76 erano apertamente dannose, e il 91% di queste usava la prompt injection come meccanismo di distribuzione.
La storia più ampia sulla qualità del codice AI è simile. Secondo l'analisi dei dati di revisione del codice di CodeRabbit, il codice assistito dall'AI presenta in media 10,83 problemi per pull request contro i 6,45 del codice scritto da esseri umani, all'incirca 1,7 volte più problemi. Lo studio annuale sul codice di GitClear ha riportato quella che definisce una "crescita di 4 volte" nella clonazione del codice: un aumento dall'8,3% al 12,3% delle righe modificate tra il 2021 e il 2024.
Sono numeri forniti dai vendor, quindi prendi la precisione con la dovuta scetticismo. Eppure sono utili come indicazione di tendenza: la programmazione assistita dall'AI sta creando abbastanza pressione sulla qualità da spingere gli sviluppatori a costruire nuove protezioni attorno a essa.
Ciò che conta è cosa ha fatto la comunità con questa informazione. La risposta non è stata "i file di skill sono pericolosi, smettete di usarli". È stata: OWASP ha lanciato l'Agentic Skills Top 10 (AST10), l'equivalente per l'ecosistema delle skill della Web Application Security Top 10. Più regole. Più struttura. Un framework di sicurezza formale per un ecosistema informale.
È una classica risposta da ingegneria, persino da parte di una comunità che spesso cerca di evitare i processi pesanti.
L'ecosistema che è comparso
Nel corso della prima metà del 2026, tutto questo ha iniziato a sembrare meno un pugno di file markdown isolati e più un ecosistema stratificato.
Partiamo dal livello comportamentale. Il CLAUDE.md ispirato a Karpathy racchiude la versione di Forrest Chang delle osservazioni di Andrej Karpathy sui fallimenti dei LLM nella scrittura di codice in un unico file di istruzioni, e ora si attesta a più di 178.000 stelle su GitHub, uno dei repository più stellati nella storia di GitHub, per un file costruito attorno a quattro semplici regole. Quali siano quelle regole è meno interessante di ciò che rappresentano: un tentativo di codificare il giudizio che un ingegnere senior applicherebbe durante la revisione del codice.
Sopra a questo c'è un livello di aggregazione della comunità. Antigravity Awesome Skills ha superato le 1.595+ skill agentiche, raccogliendo playbook riutilizzabili per Claude Code, Cursor, Codex CLI, Gemini CLI, Antigravity e altri assistenti di programmazione AI. Funziona come una libreria condivisa in rapida evoluzione per il settore: il tipo di cosa che un comitato di standardizzazione potrebbe produrre se si muovesse attraverso GitHub invece che attraverso i PDF.
Poi sono comparsi i framework. Vercel ha reso vercel-labs/agent-skills un repository ufficiale dell'organizzazione, ora a 28.000 stelle. La sola skill React Best Practices contiene oltre 40 regole distribuite su otto categorie focalizzate sulle prestazioni, tra cui waterfall, dimensione del bundle, prestazioni lato server, recupero dati lato client, ottimizzazione dei re-render, prestazioni di rendering e micro-ottimizzazioni JavaScript. Quando l'azienda proprietaria della tua piattaforma di deployment rilascia regole di qualità ufficiali per gli agenti AI, l'ecosistema è passato da esperimento della comunità a infrastruttura di produzione.
E in cima, un livello di standard. OpenAI ha donato la specifica AGENTS.md all'Agentic AI Foundation (AAIF) della Linux Foundation insieme a MCP (Anthropic) e Goose (Block): cross-tool, cross-agent, orientata agli standard. La direzione punta alla portabilità: AGENTS.md offre ai team un luogo condiviso per indicazioni specifiche del progetto rivolte agli agenti, anche se i singoli strumenti possono ancora differire nel modo in cui caricano e applicano quelle istruzioni.
Questi pezzi non sono comparsi come un unico stack pianificato centralmente. Sono convergiti perché la domanda era reale.
La dimensione di cui nessuno parla
I dati su sicurezza e qualità del codice ottengono copertura. La dimensione dell'accessibilità quasi mai.
Community-Access/accessibility-agents è partito il 21 febbraio 2026 con sei agenti. A giugno 2026: 79 agenti specializzati distribuiti su otto team, 18 skill di accessibilità riutilizzabili, targeting WCAG 2.2 AA e supporto su cinque piattaforme: Claude Code, GitHub Copilot, Gemini CLI, Codex CLI e un server MCP in grado di servire client compatibili con MCP.
Cos'è questo progetto, in parole povere: una comunità di sviluppatori ha deciso che gli strumenti di programmazione AI generano per default codice non accessibile (saltano le regole ARIA, ignorano la navigazione da tastiera, producono modali che intrappolano gli screen reader) e ha costruito 79 agenti specializzati per applicare le regole che l'AI continua a dimenticare.
È una cosa notevole. Gli ingegneri frontend hanno storicamente fatto poco in materia di accessibilità. È la prima cosa che viene tagliata sotto la pressione delle scadenze. Il progetto accessibility-agents è fatto da vibe coder che scrivono le regole che altrimenti avrebbero bisogno di un ingegnere senior per applicarle, e lo fanno in pubblico, gratis, su cinque integrazioni supportate.
A mio avviso, il progetto è insolitamente accurato per uno sforzo volontario sull'accessibilità, soprattutto perché trasforma l'accessibilità da una preoccupazione tardiva in fase di QA in istruzioni riutilizzabili per gli agenti che vengono eseguite durante la generazione del codice.
Perché era inevitabile
L'argomentazione secondo cui "i file di skill sono solo dei README per l'AI" è corretta se guardi a un singolo file. Smette di reggere quando guardi a OWASP che lancia un framework di sicurezza per l'ecosistema, a Vercel che rilascia una libreria di qualità ufficiale o a un progetto volontario sull'accessibilità che cresce fino a 79 agenti specializzati.
Ecco cosa sta succedendo davvero: l'enforcement della qualità non scompare quando rimuovi il processo. Ricompare in una forma diversa, perché l'assenza di qualità produce sofferenza in fretta, e la persona più vicina a quella sofferenza la risolve alla fonte.
La disciplina ingegneristica tradizionale (revisione del codice, guide di stile, gate di QA, governance architetturale) esiste per intercettare ciò che i singoli sviluppatori saltano sotto la pressione del tempo. Funziona quando hai un team e un processo. I vibe coder, per natura, spesso non hanno né l'uno né l'altro. Così hanno precodificato la revisione nelle istruzioni dell'agente.
CLAUDE.md è revisione del codice precodificata. Awesome Skills è una guida di stile distribuita. AGENTS.md è uno standard di governance. Le parole sono cambiate. La funzione no.
Ciò che è interessante non è che i vincoli siano ricomparsi, quello era inevitabile. Ciò che è interessante è che sono ricomparsi più velocemente rispetto alla prima volta, e più pubblicamente, e a un livello di qualità che mette in imbarazzo alcune organizzazioni di ingegneria con processi maturi.
La comunità del vibe coding non ha reinventato la disciplina ingegneristica con riluttanza, sotto la pressione del management. L'ha costruita perché ha sbattuto contro un muro e gli strumenti per risolverlo erano a un file markdown di distanza.
Domande frequenti
Cosa va in un file CLAUDE.md?
Vincoli comportamentali per l'AI: cosa evitare, cosa dare priorità, regole architetturali, segnali d'allarme di sicurezza e convenzioni specifiche del progetto. L'uso orientato alla qualità va oltre le scorciatoie di workflow: regole come "non rimuovere mai la gestione degli errori per far passare i test" stanno accanto a "usa sempre TypeScript". Per esempi reali e testati, inizia con l'aggregazione della comunità Awesome Skills. agent-skills di Vercel è un altro ottimo riferimento.
Cos'è AGENTS.md e in cosa è diverso da CLAUDE.md?
AGENTS.md è uno standard universale per le indicazioni agli agenti specifiche del progetto, rilasciato da OpenAI e donato all'Agentic AI Foundation della Linux Foundation a dicembre 2025. CLAUDE.md è il file di indicazioni di progetto di Claude Code. Si sovrappongono nello scopo, ma non sono formati identici in ogni strumento. La conclusione pratica è che i team possono sempre più scrivere le istruzioni per gli agenti una volta sola e adattarle tra strumenti come Codex, Cursor, Copilot, Gemini CLI e Claude Code.
I file di skill sono sicuri da usare?
Le skill provenienti dalla comunità dovrebbero essere lette prima di importarle. report ToxicSkills di Snyk ha scoperto che il 36% delle skill della comunità analizzate aveva almeno un difetto di sicurezza, e il 13,4% aveva difetti di livello critico, con la prompt injection come principale meccanismo di attacco. L'OWASP Agentic Skills Top 10 è il framework di riferimento per comprendere la superficie di attacco. I file di skill provenienti da repository ufficiali o da progetti open-source consolidati comportano in genere un rischio di supply chain inferiore rispetto ai contributi anonimi della comunità, ma dovrebbero comunque essere revisionati prima dell'importazione.
Cos'è l'OWASP Agentic Skills Top 10 (AST10)?
È il framework di sicurezza di OWASP del 2026 per l'ecosistema delle skill, analogo alla OWASP Web Application Security Top 10 ma che affronta specificamente la superficie di attacco creata dai file di istruzioni per gli agenti AI. Copre i dieci rischi di sicurezza più critici su piattaforme tra cui Claude Code, Cursor/Codex e VS Code. Il framework è in fase di sviluppo attivo nel 2026, con una release v1.0 prevista per il Q4 2026.
Mi servono i file di skill se sto sviluppando un progetto personale?
Solo se vuoi un comportamento coerente dell'AI. Senza vincoli, gli strumenti di programmazione AI ottimizzano per il completamento del compito, non per la qualità del codice, il che funziona bene finché non produce logica duplicata, gestione degli errori mancante o componenti di UI non accessibili. L'onere è basso: un file per progetto, mantenuto man mano che scopri cosa l'AI continua a sbagliare. Le regole ispirate a Karpathy sono un punto di partenza ragionevole; le librerie di skill della comunità ti permettono di integrare regole specifiche di dominio (sicurezza, accessibilità, idiomi di linguaggio) senza scriverle da zero.
