Per il primo mese, ho usato Claude Code nel suo stato grezzo. Scrivevo istruzioni, premevo Invio, leggevo il codice in output e lo correggevo. Pensavo che bastasse. Ma in realtà, era come guidare in autostrada con una patente solo automatica appena presa: non stavo tirando fuori nemmeno la metà delle sue prestazioni. C'è stato un momento in cui cambiare solo sette impostazioni ha fatto sembrare il comportamento per la stessa domanda qualcosa di completamente diverso.
Piacere di conoscerti, sono Hermes. Sono un professionista che usa l'AI, in particolare Claude Code, nel lavoro di tutti i giorni. Leggendo questo articolo, puoi portare a casa quelle sette impostazioni in una forma che puoi provare subito con valori di configurazione reali.
Questo contenuto è un'anteprima gratuita di una parte del mio Note a pagamento "Claude Code Complete Guide." Lascerò un link alla fine per gli interessati.
Perché l'uso "grezzo" dà solo metà delle prestazioni
Se non configuri nulla, Claude Code inizia ogni conversazione da uno stato in cui non sa nulla del progetto. Non conosce la struttura delle directory, le convenzioni di codifica, né cosa controllare prima del commit. Quindi, anche se fai la stessa domanda, un giorno potrebbe indovinare il comando giusto e un altro giorno potrebbe creare un file nel posto sbagliato.
Non è un difetto: è voluto. La documentazione ufficiale afferma chiaramente che "ogni sessione inizia da una lavagna pulita." In altre parole, la responsabilità di tirare fuori le prestazioni spetta all'utente. Le seguenti sette sono impostazioni specifiche per riempire quella "lavagna pulita."

Le 7 Impostazioni, Fornite con Dimostrazioni
1. CLAUDE.md — Memoria del Progetto
Posizionare un file chiamato CLAUDE.md nella root del progetto fa sì che Claude Code lo legga all'inizio di ogni sessione. Senza questo, Claude deve indovinare da zero ogni volta.
Il contenuto dovrebbe essere scritto con la mentalità: "Scrivo questo per non dover correggere lo stesso errore di nuovo." Scrivi dettagli concreti che possono essere verificati, non filosofie astratte.
Panoramica del Progetto: API di Gestione Inventario (Node.js + PostgreSQL) Esegui i test con npm test / Esegui sempre npm run lint prima del commit Gli handler API si trovano in src/api/handlers/
Invece di "mantieni il codice pulito," di' "indentazione a 2 spazi." Invece di "testa a dovere," di' "esegui npm test." Questa sola differenza cambia significativamente il tasso di esecuzione di Claude. Poiché si dice che l'efficacia diminuisca se il file supera le 200 righe, il trucco è spostare le procedure dettagliate all'Impostazione 7 (Skills) discussa più avanti.
2. hooks — Applicare le Decisioni tramite la Macchina
CLAUDE.md è una "richiesta," non un "requisito." Questo è un malinteso comune; è normale che Claude salti accidentalmente le istruzioni. Le regole che vuoi assolutamente che vengano rispettate dovrebbero essere bloccate meccanicamente usando un meccanismo chiamato hooks.
Scrivi un'impostazione come questa in .claude/settings.json:
Specifica hooks.PreToolUse con matcher: "Bash" Il comando da eseguire è ~/.claude/hooks/check-test.sh
Ecco una dimostrazione. Prima di aggiungere questa impostazione, mi capitava spesso questo: chiedevo a Claude di "correggere un bug," e lui faceva commit subito dopo la correzione senza eseguire i test, e solo dopo notavo test rotti.
Impostando un hook sull'evento PreToolUse, uno script intercetta proprio prima che Claude esegua un comando. Se quello script restituisce "exit code 2," l'operazione stessa viene bloccata.
Il contenuto dello script esegue semplicemente npm test se rileva git commit Se i test falliscono, restituisce "I test non sono passati" e ritorna exit code 2 L'exit code 2 è il segnale per l'hook di bloccare la chiamata allo strumento
Dal momento in cui ho aggiunto questo singolo pezzo, fare commit mentre i test sono rossi è diventato fisicamente impossibile. La forza degli hooks è che puoi confermare il passaggio da "richiesta" ad "applicazione" eseguendo effettivamente i comandi.

3. Sub-agents — Non Inquinare la Conversazione Principale con la Ricerca
Se gli fai leggere grandi file di log o esplorare l'intera codebase, quelle informazioni si accumulano nel contesto della conversazione. Quando il contesto si inquina, la precisione nel seguire le istruzioni nella seconda metà diminuisce.
Per evitare questo, usa i sub-agents per scaricare ricerca e verifica in una finestra di contesto separata, restituendo solo il riepilogo al flusso principale. Per esempio, se chiedi "Ricerca l'implementazione dell'autenticazione in questo repo e dimmi i punti chiave," il processo di esplorazione (leggere molti file e log) viene gestito in una finestra separata, e solo la conclusione torna alla conversazione principale.
✗ Continuare a fargli leggere grandi file di log direttamente nella conversazione principale
◯ Scaricare con "Fai cercare a un altro agente e riporta solo il riepilogo"
I compiti che implicano "leggere molto solo per ottenere informazioni," come risultati di test o recupero di documenti, sono particolarmente adatti da scaricare sui sub-agents.
4. Plan Mode — Fargli Scrivere un Piano Prima di Muovere le Mani
Quando si chiedono modifiche complesse, Claude potrebbe improvvisamente iniziare a scrivere codice nella direzione sbagliata, costringendoti a rifare tutto in seguito. Il Plan Mode è una modalità in cui fa solo ricerca e pianificazione senza apportare modifiche.
Puoi passare a questa modalità con Shift+Tab. In Plan Mode, Claude legge i file ed esegue comandi di ricerca ma non modifica il codice sorgente. Quando il piano è pronto, viene presentato a te, e solo allora scegli se approvarlo.
Se è noioso dire "proponi prima" ogni volta, puoi impostare questa modalità come predefinita nelle impostazioni del progetto.
Specifica permissions.defaultMode di settings.json come "plan"
Più complessa è la modifica, maggiore è il lavoro da rifare se il primo passo è fuori bersaglio. Il Plan Mode è un'assicurazione per prevenire quel lavoro da rifare.
5. Permission Modes — Progetta Dove Fermarsi
Claude Code ha diverse modalità che chiedono conferma ogni volta che modifica un file o esegue un comando, e modalità che procedono automaticamente in una certa misura. Di default, chiede conferma per tutto tranne la lettura.
Nel lavoro di implementazione quotidiano, un equilibrio in cui le modifiche ai file procedono automaticamente mentre le altre cose richiedono conferma è facile da gestire. Puoi rendere quell'equilibrio il predefinito scrivendo questo nel file delle impostazioni:
Specifica permissions.defaultMode di settings.json come "acceptEdits"
✗ Usare una modalità che disabilita tutti i controlli solo perché "la conferma è noiosa"
◯ Automatizzare solo le modifiche ai file mantenendo la conferma per le operazioni distruttive (come force push o deploy equivalenti alla produzione)
Nella mia esperienza, le persone che impostano con noncuranza tutto su "automatico" sono quelle che poi si ritrovano sorprese da modifiche inaspettate. Puoi allentare gradualmente le impostazioni una volta che hai capito dove vuoi che si fermi.

6. Gestione del Contesto — Pulisci la Stanza Spesso
Se mantieni una singola conversazione all'infinito, la cronologia irrilevante rimane nel contesto, sprecando token e riducendo la precisione delle risposte.
Digita /clear per azzerare la conversazione quando passi a un compito non correlato. Tutto qui. Per le conversazioni a cui vuoi tornare in seguito, usa /rename per dare loro un nome prima di cancellare, così puoi richiamarle senza perderti.
✗ Riusare la stessa conversazione dalla mattina alla sera, con argomenti non correlati di ieri ancora in giro
◯ Usare /clear ai confini dei compiti, e /rename prima se necessario
Se l'Impostazione 3 (Sub-agents) serve per "isolare la ricerca all'interno di un singolo compito," questa Impostazione 6 serve per "isolare tra i compiti." Fare entrambe è l'unico modo per mantenere il contesto davvero pulito.
7. Skills — Tieni le Procedure Fuori dalla Conversazione
Se continui ad aggiungere procedure a CLAUDE.md, il file stesso si gonfia, aumentando la quantità letta all'inizio di ogni sessione. Inoltre, le procedure che non usi di solito continueranno a essere lette anche durante compiti non correlati.
È qui che entrano in gioco le Skills. Se posizioni un file SKILL.md in .claude/skills/, verrà letto solo quando diventa necessario. Se CLAUDE.md è la "memoria che deve essere letta ogni volta," una Skill è un "manuale aperto solo quando serve."
Per esempio, se hai procedure lunghe che non usi frequentemente, come i passaggi di review delle PR o i passaggi di migrazione del database, spostale da CLAUDE.md al lato Skills. Le conversazioni quotidiane restano leggere, e paghi solo il peso quando è necessario.
Riepilogo — Cosa Succede Senza Queste 7?
Ecco i punti chiave.
Senza CLAUDE.md, Claude indovina da zero ogni volta. Senza hooks, le regole decise restano solo "richieste" e possono essere infrante. Senza sub-agents e /clear, il contesto si inquina e la precisione diminuisce. Senza Plan Mode, ti accolli il rischio di lavoro da rifare per le modifiche complesse. Se imposti i permission modes con noncuranza, perdi il punto in cui fermare le operazioni inaspettate. Senza Skills, CLAUDE.md diventa sempre più pesante.
Al contrario, questa è anche una storia di "perdi se non configuri queste 7." Se stai leggendo questo e non hai ancora impostato un CLAUDE.md o usato /clear una volta, quello è il tuo margine di crescita.
Non devi fare tutto in una volta. Inizia provando solo CLAUDE.md e Plan Mode nel lavoro di oggi. Anche solo questo ti farà sentire subito la differenza rispetto allo stato grezzo.

Ho compilato sistematicamente impostazioni più approfondite e insidie comuni della pratica nel mio Note a pagamento "Claude Code Complete Guide." Per chi è curioso di cosa viene dopo queste 7, vai qui.





