Claude Code ha più di cento comandi. Te ne bastano 27

Prima sessione in un progetto#

/init#

Lancialo la prima volta che apri Claude Code in un progetto. Legge il codice e scrive un CLAUDE.md di partenza, il file di istruzioni che Claude Code carica in ogni sessione. Consideralo una bozza: il comando si lancia una volta, poi il file lo curi tu.

/init

/memory#

Apre i tuoi CLAUDE.md per modificarli e gestisce l’auto-memory, cioè le note che Claude Code scrive da solo. Ti serve quando un’istruzione va cambiata e non ricordi in quale file sta.

/memory

/permissions#

Alias: /allowed-tools.

Apre le regole dei permessi, spiegate nella pagina sui permessi: allow (lo strumento parte senza chiedere), ask (chiede ogni volta), deny (vietato). Ci trovi anche le cartelle di lavoro e i blocchi recenti dell’auto mode, in cui a lasciar passare gli strumenti è un classificatore, non tu. Aprilo quando una conferma torna sempre uguale: una regola allow la toglie.

/permissions

/mcp#

Gestisce i server MCP, i programmi che collegano Claude Code a servizi esterni come GitHub o Jira, e i loro login OAuth, come spiega la pagina sugli MCP. Senza argomenti mostra i server e il loro stato: se un servizio esterno smette di rispondere, guarda qui per primo.

/mcp

Durante il lavoro#

Mentre Claude lavora, un comando va in coda e parte a fine turno. Alcuni partono subito: fra questi /btw, /model, /effort e /usage.

/plan#

Prima di toccare un file, Claude esplora il progetto e ti consegna un piano di lavoro: in plan mode di norma non modifica i sorgenti, e il piano resta in un file in ~/.claude/plans/. Se dopo il comando scrivi il compito, parte subito. Serve prima di un cambiamento che tocca molti file, e per farti spiegare un progetto che non conosci senza rischiare modifiche. Con il modello opusplan, dice la pagina sulla configurazione dei modelli, pianifica Opus ed esegue Sonnet. Quando il piano è pronto, Ctrl+G lo apre nel tuo editor per riscriverlo; poi scegli: Claude parte in auto mode, parte ma ogni modifica la confermi tu, oppure resta in plan mode e gli chiedi correzioni.

/plan sposta la validazione dei form in un modulo condiviso

/context#

Mostra in una griglia colorata cosa occupa il contesto, cioè tutto quello che il modello ha davanti a ogni richiesta. Aggiunge suggerimenti quando qualcosa pesa troppo. Lancialo quando devi scegliere se andare avanti, compattare o ripartire da zero. Con all, in schermo intero, apre il dettaglio voce per voce.

/context all

/compact#

Riassume la conversazione fin qui e libera contesto. Dopo il comando puoi scrivere cosa deve restare nel riassunto: così decidi tu cosa sopravvive. Lancialo quando chiudi una parte del lavoro e vuoi continuare nella stessa sessione.

/compact tieni il piano e i comandi di test

/btw#

Una domanda al volo (by the way, «a proposito») sulla sessione, anche mentre Claude lavora, senza fermarlo. La risposta compare in un riquadro che si chiude e non entra nella conversazione: il contesto resta com’era. Ti serve per chiedere a che punto è, o per farti rispiegare un passaggio.

/btw quale file stavi modificando?

/model#

Cambia il modello e lo salva come predefinito per le sessioni nuove. Senza argomento apre un selettore; con il nome del modello ci va dritto. Serve quando il compito chiede un modello più potente, o quando ne basta uno più leggero.

/model

/effort#

Regola l’effort del modello, cioè quanto lavora prima di risponderti: da low a xhigh, poi max e auto. Alzalo per un bug difficile, abbassalo per le domande veloci. Se lo cambi a metà turno, vale dal messaggio dopo.

/effort high

/usage#

Alias: /cost, /stats.

Mostra in una schermata sola i costi della sessione, i limiti del tuo piano e le statistiche d’uso. Parte subito, anche mentre Claude lavora: guardalo quando ti avvicini ai limiti, o prima di lanciare un lavoro lungo.

/usage

/goal#

Gli dici quando il lavoro è finito, e Claude va avanti da solo finché non lo è. Dopo ogni turno un secondo modello legge la conversazione e controlla la condizione: se non è ancora vera, Claude riparte. La pagina sui goal lo consiglia per i lavori lunghi con una fine verificabile, come portare un modulo su una nuova API finché ogni chiamata compila e i test passano.

Gira anche da script, senza interfaccia, con claude -p "/goal …", e sopravvive alla ripresa della sessione. /goal clear lo toglie. Il secondo modello non lancia comandi e non apre file: scrivi una condizione che l’output di Claude possa dimostrare. Il goal non cambia i permessi: serve l’auto mode, il modo di partenza nel terminale (da script aggiungi --permission-mode auto).

/goal npm test passa senza errori e nessun test esistente è stato modificato; oppure fermati dopo 20 turni

In parallelo#

/background#

Alias: /bg.

Stacca la sessione e la lascia lavorare da sola: il terminale torna libero, e puoi anche chiuderlo. Il testo dopo il comando è l’ultima istruzione prima di staccare; se Claude stava rispondendo, la risposta va avanti. Con la sessione si spostano i comandi e i subagenti in background, e i /loop.

Dalla shell, claude agents ti mostra in una schermata tutte le sessioni in background: chi lavora e chi aspetta una tua risposta. Lo spiega la pagina sulla vista agenti: è una funzione ancora in anteprima (research preview). Due avvertenze. Ogni sessione pesa sui limiti del piano come una normale. E quella che stacchi con /background non va in una copia separata: continua a modificare i file dove stava, e se intanto li tocchi anche tu rischi conflitti.

/background lancia tutti i test e correggi quelli che falliscono

/tasks#

Alias: /bashes.

Mostra e gestisce il lavoro in background di questa sessione: comandi lunghi e subagenti, anche quelli già finiti. Parte subito, anche mentre Claude risponde. Aprilo quando vuoi sapere cosa gira ancora, o fermare qualcosa che non serve più.

/tasks

/subtask#

Manda in parallelo un subagente che parte con tutta la conversazione di adesso: non devi rispiegargli niente. Lavora in background mentre tu vai avanti, e i suoi passaggi restano fuori dal tuo contesto: quando ha finito, nella conversazione torna solo il risultato. L’esempio della pagina sui subagenti è quello qui sotto: il subagente scrive i test delle modifiche fatte finora, e tu intanto continui a implementare. Mentre lavora lo vedi in un pannello sotto il prompt: con Enter apri la sua trascrizione e gli scrivi, con x lo fermi. Occhio ai file che tocca: di solito /rewind non annulla le sue modifiche, e la documentazione non dice che lavori in una copia separata.

/subtask scrivi i test unitari per le modifiche al parser fatte finora

/batch#

Prende una modifica grande che attraversa tutto il progetto e la divide fra tanti subagenti che lavorano in parallelo, come dice la pagina dei comandi. Prima esplora il codice e spezza il lavoro in 5–30 unità indipendenti. Poi lancia un subagente per unità, ognuno nel suo worktree, cioè una copia di lavoro separata del repository: così non si pestano i piedi. Ogni subagente fa la sua parte, lancia i test e apre una PR (la proposta di modifica), oppure ti dice com’è andata. Se le parti dipendono l’una dall’altra, non è lo strumento giusto.

/batch porta src/ da JavaScript a TypeScript

/loop#

Alias: /proactive.

Ti fa da sentinella: ripete un prompt a intervalli e tiene d’occhio una cosa che cambia da sola, come un deploy o una PR.

• Con l’intervallo (10m, 2h, 1d) il ritmo è fisso.
• Senza intervallo lo regola Claude, fra un minuto e un’ora: breve se una build sta finendo, lungo se tutto tace.
• Senza prompt cura la PR del branch: commenti di revisione, controlli automatici falliti, conflitti.
• Al posto del prompt puoi passargli una tua skill: /loop 20m /review-pr 1234.

Gira solo con la sessione aperta, o in background con /bg. Se la riprendi, i loop a intervallo fisso tornano. In ogni caso un loop scade dopo 7 giorni, dice la pagina sulle attività pianificate. Ogni giro è un turno, e consuma token.

/loop 5m controlla se il deploy è finito e dimmi com’è andata

Prima di consegnare#

/diff#

Mostra le modifiche che non hai ancora messo in un commit, comprese quelle di Claude, e te le divide anche turno per turno. Guardalo prima di ogni commit, per vedere cosa è cambiato davvero.

/diff

/code-review#

Alias: /review.

Ti dà un revisore che non ha visto nascere il codice: gira in background, in un subagente che non vede la conversazione, come spiegano la pagina sulla revisione in locale e la pagina delle skill. Cerca bug e ti porta i risultati quando ha finito.

• Senza argomenti guarda le modifiche del tuo branch, anche quelle senza commit; se no gli dai una PR, come nell’esempio qui sotto (livello high, PR 1234), un intervallo di commit o una cartella.
• Il livello va da low (pochi risultati, con meno falsi positivi) a max, che allarga la ricerca.
• Con --fix applica le correzioni, che passano dai tuoi permessi; con --comment pubblica i risultati come commenti sulla PR.

Le modifiche di un --fix in background non si annullano con /rewind: per quelle serve git.

/code-review high 1234

/security-review#

Cerca vulnerabilità nelle modifiche del tuo branch: iniezioni (input esterno che finisce dentro un comando o una query), problemi di autenticazione, dati esposti. /code-review cerca errori di correttezza, questo cerca falle di sicurezza. Lancialo prima di aprire una PR, soprattutto se hai toccato il login o i dati degli utenti.

/security-review

Tra una sessione e l’altra#

/clear#

Alias: /new, /reset.

Apre una conversazione nuova, con il contesto vuoto: niente di quello che vi siete detti arriva alla richiesta dopo. La memoria del progetto resta, e la conversazione di prima resta sul disco: la riprendi con /resume. Finché non chiudi Claude Code, ci torni anche dal menu di /rewind.

/clear

/resume#

Alias: /continue.

Riprende una conversazione di prima, con tutto il suo contesto. Senza argomento apre l’elenco delle sessioni; con un nome o un ID ci va dritto. Ti serve per i lavori di più giorni: la sessione di ieri riparte da dove l’avevi lasciata. Dalla shell fai lo stesso con claude --resume e il nome.

/resume login-sistemato

/branch#

Crea un ramo della conversazione (non di git) da questo punto e ti ci sposta. Serve per provare una strada senza perdere l’altra: per esempio, a metà lavoro vuoi vedere dove porta un approccio con Redis.

/branch prova-con-redis

/fork#

Copia la conversazione in una nuova sessione in background, e tu resti qui. Se aggiungi un prompt, la copia parte subito con quello. È una sessione a sé, con una sua riga in claude agents e, di norma, un suo worktree. Serve quando un compito deve andare avanti da solo, con tutto il contesto di adesso.

/fork scrivi i test del modulo dei pagamenti

Quando qualcosa va storto#

/rewind#

Alias: /undo, /checkpoint.

Ti lascia provare la strada più audace, perché se va male torni indietro. Claude Code salva un checkpoint a ogni tuo messaggio, come spiega la pagina sui checkpoint. Scegli il messaggio, poi cosa fare:

• riporti al punto di allora il codice, la conversazione o tutti e due; con il solo codice i file tornano com’erano, e nella conversazione resta perché la strada era sbagliata;
• con «Summarize from here» riassumi da quel messaggio in poi, per esempio una lunga sessione di debug, e le istruzioni iniziali restano intatte; con «Summarize up to here» riassumi la parte prima.

Se riporti indietro la conversazione, il tuo prompt di allora ricompare nel campo: lo correggi e lo rimandi. Ci arrivi anche con Esc Esc, ma solo a riga vuota.

/rewind

/doctor#

Alias: /checkup.

Quando qualcosa non va e non sai da dove cominciare, parti da qui. Controlla installazione, impostazioni, estensioni e CLAUDE.md, e propone correzioni che applica dopo il tuo sì. Se claude non parte proprio, la guida ai problemi dice di lanciare claude doctor dalla shell, che fa solo la diagnosi.

/doctor

/bug#

Alias: /share.

Segnala un bug ad Anthropic, anche mentre Claude lavora. Prima dell’invio una schermata ti fa scegliere quanta conversazione allegare, e non parte niente senza il tuo sì. Per i suggerimenti sul prodotto c’è /feedback, che dalla 2.1.212 è un comando a parte.

/bug la barra di stato sparisce dopo /clear

Crea il tuo comando#

Un comando tuo è una skill: un file di istruzioni con un nome. Lo metti in .claude/skills/<nome>/SKILL.md se vale per il progetto, in ~/.claude/skills/<nome>/SKILL.md se vale per te in tutti i progetti. I vecchi file in .claude/commands/ funzionano ancora; se c’è lo stesso nome nei due posti, vince la skill. Tutti i campi sono nella pagina delle skill.

Io, a fine compito, aggiorno il mio HANDOFF.md. Questa skill ne prepara la bozza:

---
description: Prepara una nota di passaggio sul lavoro della sessione, da copiare in HANDOFF.md
argument-hint: "[argomento]"
disable-model-invocation: true
allowed-tools: Bash(git status *)
---

Prepara una nota di passaggio sul lavoro di oggi su $0.

I file cambiati, secondo git:

!`git status --short`

Scrivi cosa è fatto, cosa resta da fare e il comando per ripartire.
Non modificare nessun file: mostrami solo il testo.

Il nome del comando è quello della cartella, quindi la lanci così:

/passaggio "refactor del login"

$0 è il primo argomento, $1 il secondo, e $ARGUMENTS li prende tutti insieme. Le virgolette tengono insieme più parole: senza, $0 sarebbe solo «refactor». La riga che comincia con ! gira prima che il testo arrivi a Claude, e al suo posto Claude trova l’output di git. Se il comando fallisce, per esempio fuori da un repository, si ferma tutta la skill.

Ultima cosa, il costo. La descrizione di ogni skill che Claude può lanciare da solo sta nel contesto: tutte insieme hanno l’1 % della finestra, e ognuna si taglia a 1.536 caratteri. Oltre il budget perdono la descrizione per prime quelle che usi meno. /skill-doctor ti dice quali non usi e quanto ti costano. Con disable-model-invocation: true, come nell’esempio, la descrizione resta fuori. Il resto della dieta è nell’igiene di Claude Code.

Più di cento comandi, 27 che contano. Da domani, almeno uno per ogni momento della giornata. Fine.