5 meccanismi Claude Code che cambiano il tipo di lavoro che fai

In sintesi — Claude Code rallenta i founder non per mancanza di potenza, ma per mancanza del modello mentale giusto. Questi sono i 5 meccanismi che lo trasformano da esecutore imprevedibile a collaboratore affidabile:

• CLAUDE.md + /init — contesto persistente tra sessioni, non riparti mai da zero
• Plan mode — fai esplorare e pianificare prima di toccare i file, eviti implementazioni sbagliate
• /clear e /compact — gestisci il context window prima che degradi le risposte
• Subagents — deleghi analisi e review in contesto isolato, la sessione principale resta pulita
• Skills — i tuoi comandi personalizzati per le operazioni che ripeti ogni settimana

La prima settimana con Claude Code va quasi sempre così: apri il terminale, digiti una richiesta come faresti con ChatGPT, ottieni qualcosa, lo correggi, chiedi di nuovo. Funziona, ma è lento. Frustrante. Ti aspettavi di spedire un MVP in un weekend e invece hai passato tre ore a riscrivere lo stesso componente da capo ogni volta che aprivi una nuova sessione.

Il problema non è il modello. Il problema è il modello mentale.

Claude Code non è un chatbot più potente. È un agente: legge file reali sul tuo filesystem, esegue comandi nel terminale, fa commit su git. Ma ha un vincolo critico che i chatbot non hanno: un context window che si riempie e degrada. Quando quella finestra si intasa di conversazioni irrilevanti, Claude inizia a commettere errori che sembrano stupidi — ma sono solo una conseguenza del fatto che le istruzioni che avevi dato due ore prima sono letteralmente scomparse dalla sua memoria attiva.

I 5 meccanismi che seguono non sono trucchi avanzati per chi ha già padroneggiato tutto il resto. Sono le fondamenta: quello che devi capire nella prima settimana se vuoi che Claude Code si comporti come un collaboratore affidabile e non come un esecutore imprevedibile. Se stai ancora decidendo quale stack usare per il tuo progetto, leggi prima cosa cambia nell'MVP nel 2026 — questa guida presuppone che tu abbia già scelto Claude Code come strumento principale.

1. CLAUDE.md e /init: la memoria persistente tra sessioni

Ogni volta che apri Claude Code, parte da zero. Non ricorda lo stack che usi, non sa come si avvia il dev server, non conosce le convenzioni del tuo codebase. Se non gli dai un punto di partenza, la prima richiesta di ogni sessione la passi a riorientarlo.

CLAUDE.md risolve questo problema alla radice. È un file markdown che scrivi una volta e che Claude legge automaticamente all'inizio di ogni conversazione, prima ancora che tu abbia digitato la tua prima richiesta[1]. Non è una preferenza nascosta nel menu: è letteralmente testo che Claude riceve come contesto fisso prima di iniziare.

Per generarne uno di base in automatico, lancia /init nella cartella del progetto. Claude analizza il tuo codebase, identifica stack, comandi di build e convenzioni, e crea un file di partenza. Poi lo editi tu.

Un CLAUDE.md efficace per un MVP SaaS con Next.js potrebbe avere una sezione stack (Next.js 15, Supabase, Tailwind), una sezione regole (no any in TypeScript, lancia npm run build dopo ogni modifica sostanziale), e una sezione vincoli (non toccare lo schema Supabase senza chiedere conferma esplicita). In tre sezioni, hai eliminato il 90% delle riorientazioni manuali a inizio sessione.

Attenzione al limite che i docs ufficiali raccomandano esplicitamente: circa 200 righe per file CLAUDE.md[1]. Oltre quella soglia, Claude tende a ignorarne parti perché il file stesso consuma troppo contesto. La regola pratica per ogni riga che scrivi: "se la togliessi, Claude farebbe un errore?" Se la risposta è no, taglia.

Claude Code dalla versione v2.1.59 ha anche un secondo sistema chiamato auto memory: Claude salva da solo note tra una sessione e l'altra — comandi di build trovati, pattern ricorrenti, preferenze espresse — in un file dedicato (MEMORY.md). Le prime 200 righe di quel file vengono caricate automaticamente ad ogni sessione[1]. Verifica la tua versione con claude --version.

2. Plan mode: esplora prima di toccare

Il pattern più costoso in Claude Code è questo: dai un'istruzione vaga, Claude parte subito a modificare file, e dopo dieci minuti ti ritrovi con un'implementazione che tecnicamente funziona ma risolve il problema sbagliato. Disfarlo richiede più tempo di quanto ne avresti impiegato a fermarti e ragionare.

Plan mode spezza questo loop. Quando è attivo, Claude può leggere file, esplorare il codebase ed eseguire comandi di shell per capire la situazione, ma non scrive una riga di codice. Propone un piano dettagliato e poi si ferma in attesa di istruzioni[2].

Si attiva con Shift+Tab da terminale, che cicla tra le modalità default → acceptEdits → plan. In alternativa puoi anteporre /plan a qualsiasi prompt per limitare il comportamento a quella singola richiesta. Un esempio concreto:

/plan voglio aggiungere pagamenti con Stripe. Leggi src/app e dimmi:
(1) quali file devi toccare,
(2) qual è il flow di checkout che proponi,
(3) dove potrebbe andare storto con il mio schema Supabase attuale

Claude risponde con un'analisi completa. Prima che abbia modificato nulla. A quel punto puoi dirgli di cambiare approccio — "usa un webhook async invece del call sincrono" — senza dover correggere codice già scritto.

I docs Anthropic articolano il workflow ottimale in quattro fasi[3]: Explore (Claude legge senza toccare nulla), Plan (chiedi un piano dettagliato), Implement (Claude esegue e verifica i test), Commit (Claude committa con messaggio descrittivo). Per task che toccano più di due o tre file contemporaneamente, questo workflow è sistematicamente più veloce del ciclo modifica-correzione.

L'errore tipico è l'opposto: usare plan mode anche per task banali. Rinominare una variabile, aggiungere un log, correggere un typo non richiedono un piano. Plan mode ha senso quando l'approccio non è ovvio, quando il cambiamento tocca più file, o quando non sei sicuro delle conseguenze a valle.

3. /clear e /compact: gestire il contesto prima che si degradi

Il context window è la risorsa più critica da gestire in Claude Code. Quando si avvicina al limite, Claude inizia a "dimenticare" istruzioni date all'inizio della sessione e a commettere errori che sembrano incoerenti — ma sono solo il risultato di istruzioni che non sono più nella sua finestra di memoria attiva[3].

Hai due strumenti per gestirlo. /clear resetta completamente il context window: è come aprire Claude Code da capo, ma senza perdere CLAUDE.md e auto memory, che vengono ricaricati automaticamente dal disco. /compact comprime la storia della conversazione in un sommario strutturato, liberando spazio ma preservando le informazioni chiave.

La differenza conta. Se hai finito di sistemare un bug sull'autenticazione e ora vuoi lavorare su una funzionalità completamente diversa — diciamo la dashboard analytics — /clear è la scelta giusta. Le due aree di codice non hanno relazione: trascinare il contesto del debug non ti aiuta, ti distrae.

Se invece stai ancora lavorando sulla stessa feature ma la sessione si è allungata, /compact è più utile. Puoi anche specificare cosa preservare:

/compact Focus on the current auth implementation state. Ignore earlier debugging attempts.

Per capire quando è il momento giusto di intervenire, usa /context: mostra l'utilizzo attuale del context window diviso per categoria, con indicazioni su dove si è accumulato il rumore[4].

Il pattern più frequente tra chi inizia con Claude Code è la "kitchen sink session": apri una sessione, lavori su una cosa, chiedi qualcosa di non correlato, torni alla prima. Dopo un paio d'ore, il contesto è pieno di informazioni irrilevanti. La regola dei docs Anthropic: dopo due tentativi falliti sullo stesso problema, /clear e riscrivi il prompt iniziale incorporando quello che hai imparato nel frattempo[3]. Spesso funziona al primo tentativo.

4. Subagents: isola il lavoro sporco

Costruire un MVP da soli significa dover essere security reviewer, QA engineer e developer allo stesso tempo. Il problema è che ogni ruolo richiede di leggere decine di file e accumulare contesto — e se lo fai tutto nella stessa sessione, quel contesto si mischia e si degrada.

I subagents risolvono questo. Un subagent è un file markdown in .claude/agents/ con un frontmatter YAML che definisce nome, descrizione, tool autorizzati e, opzionalmente, il modello da usare. Quando Claude incontra un task che corrisponde al dominio del subagent, può delegargli il lavoro — e quel lavoro gira in un context window completamente separato[5].

Il risultato pratico: il subagent fa tutto il lavoro "sporco" (leggere file, analizzare, verificare), e riporta solo il sommario alla sessione principale. Il contesto principale rimane pulito.

Un subagent utile per un MVP SaaS potrebbe essere un mvp-reviewer:

---
name: mvp-reviewer
description: Reviews new features for MVP quality: RLS correctness, security basics, error handling
tools: Read, Grep, Glob, Bash
---
Review code changes for an MVP SaaS. Focus on:
1. RLS protects all Supabase tables correctly?
2. Obvious security holes (unvalidated input, missing auth checks)?
3. Happy path only, or also error states?
Report findings as a numbered checklist, one item per issue.

Dopo ogni feature: "Use mvp-reviewer to check the changes in src/app/api/". Claude chiama il subagent, il subagent lavora nel suo contesto isolato, restituisce il report. Puoi anche specificare il modello per ogni subagent: se il tuo piano principale usa Sonnet, puoi lanciare Opus solo per le analisi di sicurezza dove la qualità conta di più. (Se lavori anche sulla parte visuale del prodotto con tool no-code, il confronto tra v0, Lovable e Bolt per landing page MVP è il complemento naturale a questa guida.)

L'errore tipico è confondere subagents e skills. Un subagent gira in contesto isolato con i propri tool — ideale per task che consumano molto contesto come analisi, ricerca, review. Una skill è un set di istruzioni che Claude esegue nel contesto principale — ideale per workflow ripetibili che vuoi invocare con un comando.

5. Skills: i tuoi comandi personalizzati

Costruendo un MVP, hai operazioni che esegui più volte alla settimana: aggiungere un endpoint API, fare un check prima del deploy, configurare un nuovo ambiente. Senza uno strumento per standardizzarle, ogni volta rispieghi la sequenza di step. O peggio, la dimentichi e salti qualcosa.

Le skills sono la risposta. Un file SKILL.md in .claude/skills/ definisce un workflow che Claude esegue quando lo invochi con /nome-skill[6]. Non è un'automazione bash — è Claude che segue la sequenza con la sua capacità di capire il contesto e adattarsi.

Una skill per aggiungere endpoint in modo consistente:

.claude/skills/new-endpoint/SKILL.md

---
name: new-endpoint
description: Creates a new API endpoint following project conventions
disable-model-invocation: true
---
Create a new API endpoint: $ARGUMENTS

1. Create the route file in src/app/api/$ARGUMENTS/route.ts
2. Add input validation with zod schema
3. Check Supabase RLS for authenticated users
4. Write a basic test in src/app/api/$ARGUMENTS/route.test.ts
5. Update docs/api.md
6. Run npm run build to verify no TypeScript errors

Invocazione: /new-endpoint user/profile. Claude esegue i 6 step in ordine, con il tuo stack, rispettando le convenzioni del progetto. La prossima volta, uguale.

Le skills hanno una caratteristica importante rispetto a CLAUDE.md: vengono caricate on-demand, non in ogni sessione[1]. Se hai procedure che usi spesso ma non sempre — "come fare release", "come configurare un nuovo ambiente", "checklist pre-demo" — appartengono a una skill, non al CLAUDE.md. Mettendole nel CLAUDE.md, appesantisci ogni sessione anche quando quelle procedure non servono.

Il flag disable-model-invocation: true nel frontmatter serve per workflow con effetti irreversibili — deploy, push su git, operazioni di configurazione. Con quel flag, Claude attiva la skill solo quando la invochi esplicitamente, non in automatico quando pensa che sia rilevante.

Le skills sono file nel repository. Se hai un co-founder o un developer che si unisce al progetto, li trova già in .claude/skills/ con git clone.

Una skill pratica per chi fa release in solitaria su Vercel è una checklist pre-deploy — la sequenza che dimentichi almeno una volta al mese se non la codifichi:

# .claude/skills/deploy-check/SKILL.md

---
name: deploy-check
description: Checklist pre-deploy su Vercel. Usa questa skill prima di fare push su main o di triggerare un deploy manuale.
disable-model-invocation: true
---

Esegui i controlli pre-deploy nell'ordine indicato. Fermati e segnala se uno step fallisce — non procedere al successivo.

## Step 1 — Build locale
Lancia `npm run build` e verifica che termini senza errori TypeScript o errori di build Next.js.
Se ci sono warning di deprecazione, annotali ma non bloccare.

## Step 2 — Variabili d'ambiente
Controlla che tutte le variabili in `.env.local` abbiano un corrispettivo configurato su Vercel.
Leggi `src/` cercando `process.env.` con Grep e verifica che nessuna variabile usata sia mancante dall'elenco Vercel.
NON loggare i valori delle variabili, solo i nomi.

## Step 3 — RLS Supabase
Cerca in `src/app/api/` con Grep eventuali query Supabase su tabelle nuove o modificate nell'ultima settimana.
Per ciascuna, verifica che il file usi il client server-side (da `src/lib/supabase/server.ts`) e non il client browser.

## Step 4 — Riepilogo
Riporta un elenco con tre sezioni:
- ✅ Passato: step superati senza problemi
- ⚠️ Attenzione: warning non bloccanti da tenere d'occhio
- ❌ Bloccante: problemi che richiedono fix prima del deploy

Invocazione: /deploy-check. Claude esegue i quattro step in ordine, ferma se trova un problema bloccante, consegna un report strutturato. Tutto questo senza consumare contesto nella sessione principale, perché le skills girano in modo focalizzato sul task corrente.

Come usarli insieme: il workflow di una sessione MVP

Questi cinque meccanismi non sono opzioni tra cui scegliere — si usano in combinazione. Una sessione tipo per aggiungere una nuova funzionalità a un MVP:

Prima di iniziare: CLAUDE.md è già pronto, Claude parte già orientato su stack e convenzioni. Non devi spiegare nulla.

Per capire l'impatto prima di toccare qualcosa: attivi plan mode con /plan e chiedi un'analisi di quali file verranno modificati e quali rischi ci sono con lo schema attuale.

Durante il lavoro: quando cambi area di codice o passi a una task non correlata, /clear prima di iniziare. Se stai ancora nella stessa task ma la sessione si è allungata, /compact per liberare spazio mantenendo il filo.

Quando hai finito di implementare: "Use mvp-reviewer to check the changes in src/app/api/" — il subagent fa il review in contesto isolato, riporta solo le issue trovate.

Per operazioni ripetitive: /new-endpoint user/settings, /deploy-check, qualunque cosa hai codificato nelle tue skills.

Non è un workflow rigido — è un modello mentale. La domanda che devi farti all'inizio di ogni sessione è: cosa sa già Claude grazie al CLAUDE.md? Cosa voglio capire prima di far modificare file? Quanto è pieno il contesto? Posso delegare questa analisi a un subagent?

Gli errori che rallentano tutti all'inizio

Se stai iniziando con Claude Code, questi sono i pattern che consumano tempo senza produrre risultati:

Il CLAUDE.md da 500 righe con tutto il contesto del progetto. Oltre le 200 righe indicate dai docs, Claude inizia a ignorarne parti. Un file corto e focalizzato batte sempre un file esaustivo.

Non fare mai /clear tra task non correlate. Passare dall'autenticazione alla dashboard alla sezione pagamenti nella stessa sessione accumula contesto irrilevante che peggiora le risposte nella seconda metà della giornata. La sessione non è una conversazione che deve continuare per forza — è una finestra di lavoro su un task specifico.

Saltare il plan mode per task ambigui perché sembra un passaggio in più. Il tempo che risparmi non pianificando lo perdi quasi sempre nella correzione successiva. Per task banali e chiari, ok saltarlo. Per tutto quello che tocca più di due o tre file contemporaneamente, i cinque minuti per leggere il piano di Claude vengono recuperati.

Mettere tutto in CLAUDE.md invece di usare skills per le procedure per-task. Il CLAUDE.md deve contenere quello che serve in ogni sessione. Le procedure specifiche per operazioni occasionali appartengono alle skills.

Non usare subagents per le analisi. Ogni volta che chiedi a Claude di leggere molti file per fare un'analisi — review del codice, verifica della sicurezza, esplorazione dell'architettura — stai consumando contesto che poi non hai più disponibile per il lavoro produttivo. I subagents esistono esattamente per questo.

Da dove partire

Il posto giusto da cui cominciare è /init. Lancia il comando nella cartella del tuo progetto, leggi il CLAUDE.md che Claude genera, poi editalo eliminando tutto quello che non supera il test "se la togliessi, Claude farebbe un errore?". Punta a 50-80 righe, non a 200.

Ecco un CLAUDE.md di partenza che puoi copiare e adattare al tuo progetto:

# ./CLAUDE.md

## Stack
- Next.js 15 (App Router, TypeScript strict)
- Supabase (auth + Postgres + Storage)
- Tailwind CSS v4
- Vercel (deploy automatico da main branch)

## Comandi
- Dev server: `npm run dev`
- Build + type check: `npm run build`
- Test: `npm run test`
- Linter: `npm run lint`
- Verifica sempre con `npm run build` dopo modifiche sostanziali

## Regole codice
- TypeScript strict: mai usare `any`, mai usare `as unknown as X` senza commento esplicito
- Componenti React: solo funzionali, niente class component
- Fetch dati lato server: usa React Server Components, non `useEffect` per dati iniziali
- Variabili d'ambiente lato client: solo prefisso `NEXT_PUBLIC_`, mai secrets nel bundle
- Errori: sempre gestiti — niente `.catch()` vuoti, niente `try/catch` senza log o feedback utente

## Supabase — vincoli critici
- NON modificare lo schema del database (tabelle, colonne, RLS) senza chiedere conferma esplicita
- Ogni nuova tabella accessibile da utenti autenticati richiede RLS abilitato
- Non usare la service_role key lato client, mai
- Per query Supabase usa sempre il client server-side in route handler e Server Components

## Struttura cartelle
- `src/app/` — route Next.js (App Router)
- `src/app/api/` — route handler (API endpoints)
- `src/components/` — componenti riutilizzabili
- `src/lib/` — utility, client Supabase, helper
- `src/types/` — tipi TypeScript condivisi

## Non toccare mai senza chiedere
- `src/lib/supabase/` — configurazione client Supabase
- `middleware.ts` — logica auth e redirect
- `.env.local` — non leggere, non modificare, non loggare valori
- Qualsiasi file di migrazione Supabase in `supabase/migrations/`

Poi costruisci il resto gradualmente: plan mode non richiede configurazione ed è già disponibile con Shift+Tab. Il primo subagent e la prima skill li aggiungi quando ti accorgi di ripetere sempre la stessa spiegazione o la stessa sequenza di step. Se preferisci vedere questi meccanismi in azione prima di leggerli, Claude Code in 30 minuti: la guida ufficiale Anthropic — presentata da Boris Cherny, il creatore di Claude Code — copre CLAUDE.md, slash command e workflow strutturato in meno di mezz'ora.

La curva di apprendimento di Claude Code non è nei comandi — è nel cambiare il modo in cui pensi al lavoro. Non "cosa chiedo a Claude?" ma "come struttura la sessione per ottenere il massimo dal contesto disponibile?". Una volta che quel modello mentale è consolidato, lo strumento diventa molto più prevedibile.

Se vuoi seguire come questi pattern evolvono — nuove funzionalità Claude Code, stack AI che builder italiani usano in produzione, tool che vale la pena integrare — la newsletter di Startup Mentors Italia esce ogni martedì mattina e seleziona quello che è rilevante per chi costruisce. La trovi su startupmentor.substack.com.

Fonti

1. Anthropic — Claude Code — Memory system: CLAUDE.md, auto memory, /init: https://code.claude.com/docs/en/memory
2. Anthropic — Claude Code — Permission modes: plan mode, attivazione, workflow 4 fasi: https://code.claude.com/docs/en/permission-modes
3. Anthropic — Claude Code — Best practices: explore-plan-code, gestione contesto, /clear e /compact: https://code.claude.com/docs/en/best-practices
4. Anthropic — Claude Code — Context window: cosa sopravvive a /compact, /context command: https://code.claude.com/docs/en/context-window
5. Anthropic — Claude Code — Sub-agents: definizione, frontmatter, pattern di uso: https://code.claude.com/docs/en/sub-agents
6. Anthropic — Claude Code — Skills: struttura SKILL.md, differenza da CLAUDE.md e subagents: https://code.claude.com/docs/en/skills
7. Anthropic — Claude Code — Overview: capacità, installazione, modello mentale agente: https://code.claude.com/docs/en/overview