Cos'è e perché conta
Ogni sessione di Claude Code parte con il contesto vuoto. Quello che gli hai spiegato ieri in chat, oggi non c'è. Così ricominci da capo: «allora, la mia app è…». E le volte che te ne dimentichi, lui indovina: lo strumento, la cartella, quanto può cambiare.
Il CLAUDE.md serve a questo. È un file di testo semplice, nella cartella del progetto, con le regole che vuoi che valgano sempre. Claude Code lo legge all'inizio di ogni sessione, prima ancora del tuo primo messaggio. Per questo lo chiamo il file che Claude legge prima di tutto.
Conta perché scrivi una volta sola quello che ripeteresti ogni giorno. Lui parte già sapendolo, e tu vai dritto a quello che vuoi fare.
Una cosa da sapere subito: è un'indicazione, non un lucchetto. Claude lo legge e cerca di seguirlo, e più le regole sono chiare, più le segue. Ma per bloccare davvero una cosa non basta: ne parlo nelle domande in fondo.
1. Il mio file, da copiare
Ecco il mio file da copiare, su un'app d'esempio: un ricettario. Sono dieci righe. Cambia le parti tra < > con quelle del tuo progetto, e togli i simboli < >.
# <Ricettario>: <app di ricette> Stack: <Next.js e TypeScript> Codice in <src/>, test in <tests/> Non toccare <.env> e <la cartella dei pagamenti> Chiedi prima di cancellare file Leggi prima di cambiare Dopo ogni modifica: <npm test>, e dimmi il risultato Una modifica alla volta Parla con me in italiano Scrivi il codice in inglese
Le righe senza < > le tengo uguali in tutti i progetti. Anzi, quelle che valgono ovunque, come la lingua, le sposto nel file del mio utente: lo vediamo tra poco.
2. Le dieci righe spiegate
Ogni riga c'è perché mi ha tolto un problema che avevo spesso:
- Cos'è l'app. Niente più «allora, la mia app è…» a ogni sessione nuova.
- Con cosa è fatta. Non ti propone strumenti diversi da quelli che usi già.
- Dove sta il codice e dove i test. Non li cerca ogni volta.
- Cosa non deve toccare. Chiavi e soldi restano tuoi: le chiavi segrete di solito stanno nel file .env, e i pagamenti sono la parte dove un errore fa più danni. Ma è un'indicazione, non un blocco: per bloccarlo davvero serve una regola deny o un hook. Ne parlo nella guida GUARDIA (strikt.fit/guardia).
- Chiedi prima di cancellare. Niente cancellazioni a sorpresa.
- Leggi prima di cambiare. Capisce cosa c'è prima di riscriverlo.
- Il comando dei test. È quello che dimostra che l'app funziona ancora. E gli chiedo il risultato, non solo di lanciarlo.
- Una modifica alla volta. Cambi piccoli: se qualcosa si rompe, sai dove.
- La lingua. Ti risponde nella tua lingua.
- Il codice in inglese. Nomi, funzioni e commenti restano in inglese, come li legge chiunque.
Sono tutte cose che dal codice non si capiscono, o si capiscono solo cercando: è proprio quello che serve scrivere.
3. Dove va
Il nome è sempre CLAUDE.md. Cambia la cartella, e la cartella decide dove vale:
- Nella cartella principale del progetto: ./CLAUDE.md, oppure ./.claude/CLAUDE.md. Sono equivalenti, scegline uno. Contiene le regole di quel progetto, e se il progetto è su git le vede anche chi ci lavora con te.
- Nel file del tuo utente: ~/.claude/CLAUDE.md. Le regole che valgono per tutti i tuoi progetti, come la lingua, vanno qui. Le vedi solo tu.
Claude Code li legge all'inizio di ogni sessione, tutti e due: si sommano, non si sostituiscono. Quindi nel progetto non ripetere quello che c'è già nel file del tuo utente, e fai in modo che non si contraddicano: se due righe dicono cose opposte, Claude può seguire l'una o l'altra.
Quando cambi un file, apri una sessione nuova: così sei sicuro che lavori con la versione aggiornata.
4. Come lo crei e lo modifichi
- Apri Claude Code nella cartella del progetto e scrivi /init. Guarda il tuo codice e ti scrive un primo CLAUDE.md, con i comandi per avviare e testare il progetto e le convenzioni che trova. Se un CLAUDE.md c'è già, non lo sovrascrive: ti propone dei miglioramenti.
- Poi aggiungi tu le regole che da solo non può indovinare: cosa non deve toccare, come vuoi che lavori, in che lingua parlarti. Sono quelle del mio file qui sopra.
- Per modificarlo scrivi /memory. Ti mostra i file di memoria del progetto e del tuo utente. Scegli il file e si apre nel tuo editor; se non esiste, lo crea.
- Per controllare che l'abbia caricato, in una sessione nuova scrivi /context e guarda l'elenco sotto Memory files. Ci devono essere i tuoi CLAUDE.md: se uno manca, Claude non lo vede.
Le regole nuove puoi anche fargliele scrivere a lui. Quando ti accorgi che ne manca una:
Aggiungi al CLAUDE.md del progetto questa regola: [la regola]. Scrivila in una riga, corta e precisa.
Conta come lo dici. Con «aggiungilo al CLAUDE.md» finisce nel file. Se gli dici solo «ricordati che…», di solito lo salva nella sua memoria automatica, che è un'altra cosa: la spiego nelle domande in fondo.
5. Tienilo corto
Tienilo corto e preciso: più le regole sono chiare e poche, più le segue. La documentazione di Claude Code consiglia di stare sotto le 200 righe per file: oltre, le regole vengono seguite peggio.
Preciso vuol dire che si può controllare. «Dopo ogni modifica lancia npm test» funziona meglio di «testa bene il codice». «Il codice sta in src/» funziona meglio di «tieni i file in ordine».
E poi va tenuto vivo. Io seguo tre regole:
- Se gli ripeti la stessa cosa due volte, è una riga che manca: aggiungila.
- Se una riga non è più vera, toglila.
- Se è una cosa che Claude vede da solo aprendo il codice, non serve scriverla.
Gli errori più comuni
- Lasciare il file di /init così com'è. È una base: aggiungi le regole che dal codice non si vedono, come cosa non toccare e in che lingua parlarti.
- Ripetere in ogni progetto le regole che valgono ovunque. Mettile una volta sola in ~/.claude/CLAUDE.md.
- Scrivere regole vaghe, tipo «stai attento». Scrivi cose che si possono controllare: un comando, una cartella, un file.
- Trattarlo come un lucchetto. È un'indicazione: per bloccare davvero un file servono una regola deny nei permessi di Claude Code o un hook.
- Cambiarlo e continuare nella stessa sessione dando per scontato che lo veda. Apri una sessione nuova e controlla con /context.
Checklist
- Il CLAUDE.md è nella cartella principale del progetto
- Le parti tra < > ora parlano del mio progetto
- C'è il comando che lancia i test
- La lingua sta in ~/.claude/CLAUDE.md, non in ogni progetto
- In una sessione nuova, /context lo mostra sotto Memory files
- È corto, senza righe ripetute o non più vere
Domande frequenti
Claude Code non ha già una memoria sua?
Sì, la memoria automatica, attiva di default: Claude si prende appunti da solo, per esempio sulle correzioni che gli fai, e li rilegge nelle sessioni dopo. La differenza è chi scrive: il CLAUDE.md lo scrivi tu, ed è il posto delle regole; la memoria automatica la scrive lui. Con /memory puoi aprirne la cartella o spegnerla.
Se scrivo «non toccare .env», sono sicuro che non lo apre?
No. Il CLAUDE.md è contesto: Claude lo legge e cerca di seguirlo, ma non lo ferma. Per un blocco vero ci sono le regole dei permessi nelle impostazioni di Claude Code: con una regola di divieto come Read(./.env), Claude Code impedisce ai suoi strumenti di lettura di aprire quel file, qualunque cosa decida Claude. La riga nel CLAUDE.md tienila comunque: gli dice cosa evitare anche dove non hai messo un blocco.
Il mio CLAUDE.md è diventato lunghissimo. Che faccio?
Prima togli le righe non più vere e quelle che Claude capisce dal codice. Se restano regole che valgono solo per una parte del progetto, puoi spostarle in file separati nella cartella .claude/rules/: se in cima al file indichi a quali file si applicano, vengono caricate solo quando Claude lavora su quei file. Spezzarlo in più file con gli import @percorso aiuta a tenerlo in ordine, ma non lo alleggerisce: anche i file importati vengono caricati all'inizio.