APandrea.
Torna al Blog
Claude CodeAI AgentsAutomazioneWorkflow AILangGraphMarkdown

5 Trucchi per Claude Code che Avrei Voluto Conoscere dal Primo Giorno

Scopri 5 strategie essenziali per ottimizzare Claude Code: riduci token, struttura workstation efficaci e automatizza il tuo workflow da freelance.

8 min di lettura
5 Trucchi per Claude Code che Avrei Voluto Conoscere dal Primo Giorno

Se hai iniziato a sperimentare con Claude Code (chiamato anche Cowork), probabilmente hai già capito una cosa: è uno strumento potentissimo. Ma c'è un problema. Non esiste ancora uno standard su come strutturare al meglio il tuo workspace. E se sbagli le fondamenta, ti ritroverai a risolvere problemi evitabili per settimane.

Dopo mesi di utilizzo quotidiano di Claude Code per automatizzare buona parte del mio lavoro di freelance, ho imparato alcune cose che avrei voluto sapere dal primo giorno. In questo articolo ti mostro cinque strategie essenziali per partire con il piede giusto.

Come Rendere i File Markdown Leggibili (Senza Impazzire)

Le istruzioni e la memoria di Claude Code vivono in file markdown (.md). Il problema? Aprire e modificare questi file direttamente nell'editor costa token. Ok, è una battuta, ma ogni volta che devo editare un file .md grezzo mi sento come se stessi sprecando risorse.

La soluzione che ho trovato è semplice: usa Obsidian, un'app gratuita che trasforma i file markdown in documenti leggibili con titoli, grassetti, elenchi puntati. Basta aprire la cartella del tuo workspace in Obsidian e ogni file .md diventa immediatamente più gestibile.

Ecco cosa faccio: apro il file claw.md in Obsidian, modifico le sezioni che mi interessano (ad esempio, aggiungo una preferenza nella sezione "Preferenze"), salvo, e quando riapro Claude Code le modifiche sono già sincronizzate. Non serve imparare tutte le funzioni di Obsidian: è solo una lente per leggere e scrivere markdown senza mal di testa.

Consiglio pratico: Usa Command/Control + per ingrandire il testo, attiva la modalità lettura per bloccare modifiche accidentali, e abilita "Show all file types" nelle impostazioni per visualizzare anche PDF, immagini e spreadsheet nella sidebar.

La Regola delle 300 Righe per Ridurre il Consumo di Token

Il file claw.md si carica a ogni sessione. Se è troppo lungo, sprechi token inutilmente. Quando ho ridotto il mio da oltre 600 righe a circa 250, l'uso di token è sceso del 25%. Un risparmio concreto, soprattutto se usi Claude Code ogni giorno.

La prima tattica: includi solo l'essenziale. Il mio template claw.md ha sei sezioni chiave:

  • Memory System: dice a Claude di caricare sempre memory.md all'avvio
  • Preferences: tono, lunghezza, formato della comunicazione
  • Rules: regole comportamentali ("Chiedi sempre chiarimenti prima di task complessi", "Non modificare file senza spiegare cosa e perché")
  • Routing Map: tabella che indirizza Claude verso la workstation giusta in base al task
  • References: puntatori a file da caricare solo su richiesta
  • Creating New Workstations: istruzioni per creare nuove workstation

La regola aurea: mantieni il file claw.md tra 200 e 250 righe, massimo 300. Ma come fai se continui ad aggiungere istruzioni?

Seconda tattica: sposta le regole non essenziali. Chiediti: Claude ha bisogno di questa regola a ogni sessione, o solo quando lavoro su un task specifico? Per esempio, ho una sezione "governance" che deve restare in claw.md perché governa tutto il workspace. Al contrario, le regole sulla creazione di nuovi file le uso raramente: invece di tenerle tutte in claw.md, le ho spostate in un file separato con un semplice puntatore: "Leggi questo prima di creare nuovi file".

Puoi farlo subito: dì a Claude "Sposta la sezione X da claw.md in un file di riferimento separato e sostituiscila con un puntatore". In pochi secondi, il file principale diventa più snello senza perdere nulla.

Terza tattica: distingui cosa va in claw.md e cosa in memory.md. Test uno: se contiene "sempre" o "mai" (è prescrittivo), va in claw.md. Test due: se è un fatto che potrebbe cambiare, va in memory.md. Esempio: "Prima di scrivere una nuova email, controlla se esiste già un thread con quel destinatario" è una regola comportamentale → claw.md. "La mia azienda usa Microsoft Copilot" è un fatto temporaneo → memory.md.

Prova questo: chiedi a Claude di revisionare i tuoi file e segnalarti voci fuori posto. Ti darà raccomandazioni precise su cosa spostare e dove.

La Dieta della Memoria: Come Tenere memory.md Sotto Controllo

Anche memory.md si carica a ogni sessione. Se è disordinato, sprechi token e peggiori gli output di Claude. Ho imparato a strutturarlo in tre sezioni:

  • Active Projects: lista dei progetti in corso con stato aggiornato
  • Scheduled Tasks: task automatizzati ricorrenti, così Claude non crea duplicati
  • Core Memory: fatti persistenti su di me (background professionale, indirizzo email, URL LinkedIn)

Ma la vera svolta è stata impostare un limite rigido. Nelle regole del memory system ho scritto: "memory.md ha un tetto di 150 righe. Quando lo supero, la soluzione è sempre compressione e archiviazione, mai alzare il tetto".

Quando memory.md raggiunge 150 righe, Claude archivia automaticamente le informazioni obsolete (progetti chiusi 2-3 mesi fa) in un file separato: archive.md. Questo file non si carica a ogni sessione: Claude lo consulta solo quando gli chiedo esplicitamente qualcosa come "Cosa è successo con il progetto X tre mesi fa?".

Il risultato? Il mio memory.md non ha mai superato le 100 righe, anche dopo mesi di uso intensivo. E archive.md non ha limiti di dimensione: conservo tutto senza pagare costi di token.

Consiglio avanzato: crea un memory.md separato per ogni workstation e progetto. Quando chiedo a Claude aggiornamenti su una campagna email specifica, prima controlla il memory.md principale (esiste il progetto?), poi salta al memory.md del progetto per dettagli come pagine Notion, subject line, decisioni passate. Questa struttura a cascata tiene il file principale sempre snello.

Come Migrare i Progetti Claude Standard in Claude Code

Se usavi già Claude Projects, ti consiglio di migrare tutto in Claude Code. Perché? I progetti standard hanno limiti che Code supera facilmente.

Nei progetti standard, per modificare le istruzioni devi cliccare manualmente nell'editor e digitare. La memoria del progetto è un paragrafo generato dall'AI che non puoi strutturare o editare direttamente. E se alleghi un file Google Docs come knowledge base, Claude non può scriverci: devi copiare e incollare manualmente.

In Claude Code, invece, le istruzioni del progetto diventano il file claw.md della workstation, la memoria diventa memory.md, e i knowledge file finiscono nella cartella risorse. Puoi dire a Claude "Aggiungi questa regola al file claw.md della mia workstation newsletter" e lui la scrive direttamente nel file giusto.

Per migrare un progetto esistente, segui questi passaggi:

  • Apri un documento di testo vuoto
  • Copia le istruzioni del progetto e incollale
  • Copia la memoria del progetto e incollala sotto un titolo "Project Memory"
  • Salva come project-info.md
  • Scarica eventuali knowledge file come markdown
  • Condividi tutto con Claude Code usando un prompt di migrazione

Claude creerà automaticamente una nuova workstation con file claw.md, memory.md, cartella risorse e aggiungerà una voce nella routing map. Da quel momento, ogni miglioramento che fai al sistema resta salvato e compone risultati sempre migliori. Non è solo automazione: è un sistema che impara e cresce con te.

Workstation o Skill? Quando Usare Cosa

Molti mi chiedono: qual è la differenza tra una workstation e uno skill? La risposta è più semplice di quanto sembri.

Una workstation è un'area di lavoro continua che richiede il tuo input e le tue decisioni. Per esempio, quando lavoro alla mia newsletter settimanale, Claude carica la workstation newsletter e mi guida attraverso il workflow: "Hai già scelto l'argomento? Quale app Google tratti questa settimana?". Io devo fare scelte lungo il percorso. Non può girare in autopilota.

Uno skill , al contrario, è un processo ripetibile che funziona sempre allo stesso modo. Una volta finalizzata la bozza della newsletter, attivo lo skill "subject line": prende il draft, applica una checklist, restituisce cinque opzioni con punteggio. L'output è prevedibile, l'unica cosa che cambia è il contenuto in input.

Un altro esempio: ho creato uno skill "workstation audit" che controlla errori, regole fuori posto e lacune in una cartella workstation. Il risultato è sempre un report con sintesi esecutiva, findings specifici e raccomandazioni.

Il test è semplice: è un posto dove lavoro o una cosa che faccio? Se è un'area di lavoro continua con voce propria e contesto accumulato nel tempo, è una workstation. Se è un processo ripetibile che vuoi eseguito allo stesso modo ogni volta, è uno skill.

Questa distinzione mi ha aiutato a strutturare il workspace in modo molto più razionale. Le workstation sono gli spazi dove ragiono, prendo decisioni, creo contenuti. Gli skill sono gli strumenti che uso per automatizzare le parti ripetitive e prevedibili.

Claude Code: Uno Strumento che Cresce con Te (Se Sai Come Usarlo)

Claude Code è diverso da un chatbot tradizionale. Non è solo una conversazione: è un sistema persistente che accumula contesto, ricorda scelte passate, migliora ogni giorno. Ma solo se lo strutturi bene fin dall'inizio.

Se parti con file disordinati, senza regole chiare su cosa va dove, ti ritroverai a sprecare token e a ottenere output mediocri. Se invece investi tempo per costruire fondamenta solide — file markdown leggibili, limiti rigidi sulla lunghezza, memoria strutturata, distinzione chiara tra workstation e skill — allora hai tra le mani uno strumento che può davvero cambiare il modo in cui lavori.

Io l'ho usato per automatizzare buona parte del mio workflow quotidiano: dalla gestione delle email alla scrittura di contenuti, dalla ricerca alla creazione di report. E ogni miglioramento che faccio oggi rende il sistema più potente domani.

Se stai iniziando con Claude Code, il mio consiglio è questo: non cercare la perfezione dal primo giorno. Parti con un template snello, testa il sistema su un progetto reale, e lascia che cresca in modo organico. Ma imposta subito i limiti e le regole che ho condiviso qui. Ti risparmierai mesi di refactoring e token sprecati.