Un file, qualche direttiva, e Claude fa il resto — come ho strutturato 500 email senza fatica

Nel precedente articolo, ho descritto un sistema di contesti strutturati per lavorare con un LLM su argomenti complessi. Cartelle, file di missione, manifesti di caricamento, note atomiche collegate tra loro. Il modello è potente. Ma non è semplice da capire, e ancora meno da mettere in piedi quando si parte da zero.

E soprattutto — non ci sono arrivato al primo tentativo. Questo sistema è il risultato di 40 giorni di prove, errori, versioni scartate e ricostruite. Nessuno compra una Ferrari come prima auto. Qui è lo stesso: bisogna prima guidare, capire come funziona, e solo dopo aumentare la complessità.

Questo articolo racconta come ho iniziato. Non con un framework. Con un file.

Il problema: 500 email e zero visione d'insieme

Come membro del consiglio del mio condominio, ricevo moltissime email. Dal'amministratore, dai proprietari, dagli inquilini. A volte un nuovo argomento, a volte l'ennesima risposta a un thread che va avanti da mesi.

Il volume non è il vero problema. Il vero problema è che ogni persona che risponde a un thread ha il contesto in testa — è lei che ha seguito l'argomento fin dall'inizio. Io, quando apro una nuova email, devo risalire tutta la catena, trovare chi ha detto cosa, capire a che punto siamo. Per un cantiere che dura sei mesi, è un lavoro considerevole. Moltiplicalo per quindici argomenti in parallelo, e capisci perché ho cercato un'altra soluzione.

Ho deciso di delegare a Claude la strutturazione di queste informazioni in entrata. Recupera le email automaticamente, le associa al loro thread e aggrega tutto. Il recupero automatico delle email è pura tecnica — non ne parlerò qui. Quello che mi interessa è ciò che viene dopo: come ho costruito, passo dopo passo, un sistema di memoria che regge.

Passo 1 — Un file, una frase

All'inizio era un semplice file context.md con una direttiva vaga:

«Aggrega le informazioni e suddividi per tematiche.»

E funzionava. Claude riceveva le email, le classificava per argomento, manteneva un riassunto per tematica. Per un primo tentativo, era già utile.

Passo 2 — Il problema della perdita di informazioni

Poi ho visto che perdevo informazioni. Quando un cantiere finiva, per esempio, Claude aggiornava l'aggregazione: «cantiere terminato, collaudo conforme». Bene. Ma la storia scompariva. Quando era iniziato il cantiere? Quando era stato ritardato? Quando era stato firmato un addendum? Tutto ciò veniva sovrascritto dall'ultimo aggiornamento.

Mi servivano entrambe le cose: l'informazione finale e la storia.

La soluzione è stata chiedere a Claude di mantenere, oltre all'aggregazione, un registro cronologico. Se un cantiere inizia, è una riga. Se viene ritardato, è un'altra riga. Se un addendum riguarda il cantiere, è ancora un'altra riga. Nell'aggregazione si vede lo stato attuale: «cantiere iniziato a gennaio, terminato a giugno, conforme». Nel registro si vede ogni tappa, ogni evento, nell'ordine.

Due viste dello stesso argomento. Una per capire in fretta, l'altra per risalire il filo.

Passo 3 — Le direttive specifiche

Poi ho voluto dare regole di trattamento più precise. Non regole generiche — direttive specifiche al mio contesto.

Per esempio: quando una persona viene citata con il suo cognome, trovare il nome corrispondente. Sembra banale, salvo quando due fornitori hanno lo stesso cognome. In quel caso, la direttiva precisa: usare il senso dell'email per disambiguare.

Altro caso: alcune persone vengono chiamate a volte con il cognome da nubile, a volte con quello da sposata. Senza direttiva, Claude crea due voci distinte per la stessa persona. Con la direttiva, sa che è la stessa.

Altro esempio ancora: separare i piccoli debitori (meno di 100 euro) dai grandi debitori. Non è la stessa gestione, non è lo stesso monitoraggio, non è lo stesso livello di attenzione.

Queste direttive non sono regole universali. Sono specifiche al mio contesto. Ed è proprio questo che le rende potenti: codificano una conoscenza che solo io possiedo, e che Claude applica poi sistematicamente, senza dimenticare, senza stancarsi.

Passo 4 — Il muro delle 1.000 righe

Funzionava bene. Il mio context.md organizzava correttamente la mia conoscenza. Ma stava gonfiandosi. 500 righe, poi 800, poi oltre 1.000.

Il problema non è solo la leggibilità per me. È la finestra di contesto del LLM. Più il file è grande, più Claude deve caricare tutto a ogni sessione. E come ho spiegato nell'articolo precedente, un LLM perde precisione sulle informazioni sepolte nel mezzo di un documento lungo. Il mio file unico stava cominciando a lavorare contro di me.

Passo 5 — Separare le direttive dal contesto

Prima soluzione: estrarre le direttive in un file separato.

Le direttive — come trattare i nomi, come separare i debitori, come gestire i duplicati — non sono informazioni sul condominio. Sono regole di trattamento. Mescolarle con il contesto è come mescolare la ricetta con gli ingredienti.

Un file directives.md da un lato. Il context.md dall'altro. Già meglio.

Ma context.md continuava a gonfiarsi.

Passo 6 — Suddividere il contesto per tematica

La vera soluzione è stata chiedere a Claude di suddividere il mio context.md in tanti file quante erano le tematiche. I lavori in un file. Le finanze in un altro. I fornitori in un terzo. E così via.

E per orientarsi: un readme.md che elenca tutti i file, con una breve descrizione di ciascuna tematica.

La prima suddivisione non mi ha convinto del tutto. È normale: gli avevo chiesto di suddividere senza dargli direttive precise su come farlo, quindi ha fatto come gli sembrava. E a volte la sua visione della suddivisione non corrispondeva alla mia. Avevo un file di diverse migliaia di righe — non lo vedevo necessariamente come lui.

Con un po' di discussione e qualche direttiva rafforzata sulla suddivisione, siamo arrivati a qualcosa che mi soddisfaceva. I file sono correttamente suddivisi. E soprattutto: Claude ora legge e scrive solo nei file di cui ha bisogno. Niente più file monolitico caricato per intero a ogni sessione. La finestra di contesto non va più fuori controllo.

Passo 7 — Esternalizzare il vocabolario

Ultimo affinamento: nel contesto del condominio abbiamo molto vocabolario tecnico. Nomi tecnici, acronimi (DPAE…), termini giuridici. Invece di lasciarli sparsi in ogni file tematico, gli ho chiesto di centralizzare tutto in un glossary.md.

Il modello finale — semplice e robusto

Ecco fatto. Senza andare verso un sistema di memoria complesso — niente manifesto di caricamento, niente note atomiche, niente memoria episodica — ho un modello che copre ampiamente il mio bisogno:

directives.md       — regole di trattamento
glossary.md         — vocabolario tecnico
readme.md           — indice delle tematiche
themes/
  residence.md
  travaux.md
  finances.md
  prestataires.md
  ...               — un file per tematica

Quattro concetti. Un file di regole, un glossario, un indice e file tematici. Tutto qui.

Per dare un'idea concreta, ecco il readme.md reale del mio contesto condominiale, così com'è oggi — 15 file tematici:

Questa cartella era in precedenza un unico file monolitico di oltre 1.000 righe. È stato decomposto in 14 file tematici in un'unica sessione, poi debiteurs.md è stato estratto da acteurs.md lo stesso giorno — perché la gestione dei debitori meritava il proprio spazio.

Cosa cambia nel quotidiano

Il guadagno è enorme.

Per chi segue un argomento da sei mesi — l'amministratore che gestisce un cantiere, il fornitore che risponde su un preventivo — il contesto è in testa. Sa dove siamo perché ha vissuto ogni tappa.

Io, quando arrivo a un'email, non ho questo lusso. Devo risalire la catena, rileggere gli scambi precedenti, ricostruire lo stato dell'argomento. Con 15 argomenti in parallelo e thread che si estendono su mesi, è un lavoro enorme.

Con il sistema in funzione, tutto è aggregato. So che c'è una nuova email. Ma soprattutto, so quali sono le evoluzioni, come è cambiato un dato, a che punto siamo. Ho la traccia storica. Ho la lista delle persone contattate. Ho la lista dei fornitori con i loro ambiti e i loro importi. Tutte queste informazioni sono organizzate e stabili. La lista dei fornitori non cambia a ogni email — si arricchisce progressivamente.

E quando mi faccio una domanda — «quale fornitore ha fatto l'ultimo preventivo per le grondaie?», «a che punto è il fascicolo con quel debitore?» — basta porla a Claude. Se hai 300, 400, 500 email e devi trovare la risposta a questo tipo di domanda frugando nella tua casella di posta, è un inferno.

Da dove iniziare?

Se vuoi provare, consiglierei di usare Claude CoWork quando non si viene dallo sviluppo. È più semplice, non serve tirare fuori un intero strumento di sviluppo. Solo due cose da fare:

1. Creare un file context.md
2. Dare 2-3 direttive nella conversazione: «ti darò delle informazioni, le aggrega, storicizza se ci sono più tappe per quella informazione, e metti tutto nel context.md»

E poi inizi a parlare con Claude. Gli dai informazioni, vedi come le organizza, aggiusti. L'obiettivo della prima volta è solo imparare. Non costruire il sistema perfetto. Imparare come funziona, come reagisce l'IA, cosa fa bene e cosa fa male.

Per parte mia, sono passato direttamente a Claude Code perché vengo dallo sviluppo. Era più semplice per me, è più potente. Ma la scelta dello strumento non è la cosa più importante — quello che conta è il metodo.

Il costo d'ingresso

Quanto tempo mi ha preso? Partendo da zero, senza aver mai conosciuto Claude, sono a circa 40 giorni per arrivare al sistema attuale (più una quantità di altre cose di cui bisognerà parlare: monitoraggio della concorrenza, questo blog è anch'esso interamente gestito da Claude, gestione della documentazione di supporto, agente analista dati…). Ma ho un vantaggio: prima di essere product manager, ero sviluppatore. Questo aiuta per la parte degli strumenti. Per la parte del metodo — come strutturare le informazioni, quali direttive dare — è accessibile a chiunque.

La questione della fiducia

Certo che Claude fa errori. Ma li fa anche un essere umano.

Quello che bisogna vedere è che ovviamente non affideremmo la gestione di documenti bancari a un'IA. Ci sono ambiti in cui non ci si può permettere l'errore. Ma per strutturare le email di un condominio, se di tanto in tanto Claude associa male un'informazione, non è grave. Il guadagno di tempo è così importante che qualche approssimazione è un prezzo accettabile.

E soprattutto, ho sempre una via d'uscita: la mia casella di posta. Tutte le email grezze sono conservate nel repository — una copia di tutte le email grezze nel progetto Claude. Posso in qualsiasi momento fare una ricerca direttamente sulle email originali tramite Claude Code, senza passare per l'informazione aggregata. Il sistema strutturato è un acceleratore, non un sostituto. La fonte di verità rimane accessibile.

Dal personale al professionale

Ho applicato esattamente lo stesso approccio per il mio lavoro di PM. All'inizio era davvero artigianale — un file di contesto, uno skill, conversazioni nella console senza sapere bene come funzionasse. E poi ho imparato. Mi sono lanciato, ho fatto molti errori.

Ho buttato via la prima versione di quello che avevo fatto. La seconda pensavo di butto via anche quella dicendomi «sarà molto migliore, ma almeno imparerò delle cose». E poi la seconda l'ho tenuta — funziona ancora. E ho iterato su di essa per arrivare a una terza versione, quella che descrivo nell'articolo precedente.

Fai evolvere, non saltare tappe

Sono alla terza versione del mio sistema. Ho appena convertito gli ultimi elementi dalla V2 alla V3. E forse un giorno avrò una V4, ancora più complessa, ma che porta ancora più valore.

Ma bisogna essere pragmatici. Si fa un'evoluzione di versione perché i bisogni crescono — non solo perché fa piacere. Altrimenti è overengineering.

Il percorso è: un file → delle direttive → una suddivisione → un glossario → un sistema. Ogni tappa risponde a un problema concreto. Si passa alla successiva solo quando la precedente non è più sufficiente. E a ogni tappa, si ha qualcosa che funziona.

Inizia con un file. Vedrai tu stesso quando sarà il momento di suddividerlo.

Per saperne di più

Il PM come architetto del Contesto Aggiungere una memoria di sessione come in OpenClaw