Come usare una side chat in Claude Code senza deviare il lavoro

Una side chat di Claude Code serve a fare una domanda usando il contesto della sessione senza aggiungere quello scambio al thread principale. È utile per capire un passaggio, controllare un'assunzione o confrontare due alternative mentre il lavoro resta orientato allo stesso risultato.

Il vantaggio dipende dal confine. Se usi /btw per chiedere una modifica, prendere una decisione o aprire un secondo incarico, la conversazione laterale nasconde informazioni che il lavoro principale dovrebbe conoscere. La regola pratica è semplice: esplora di lato, ma approva e modifica nel thread che possiede il task.

Che cosa fa davvero una side chat

Nella versione Desktop di Claude Code, la side chat può leggere ciò che è già presente nel thread principale fino al momento in cui la apri. Il suo contenuto, però, non viene aggiunto alla conversazione principale. Quando la chiudi, riprendi il lavoro dal punto in cui lo avevi lasciato.

Questo comportamento risolve un problema preciso. Durante una sessione puoi voler sapere che cosa fa una funzione, perché un test usa un certo fixture o quali conseguenze avrebbe un'alternativa. Inserire tutte queste esplorazioni nel thread principale allunga il contesto e può spostare l'attenzione dal compito concordato.

La separazione non significa che la side chat sia “privata” o priva di conseguenze. Usa il contesto della sessione e può quindi leggere informazioni già disponibili a Claude. Trattala con gli stessi limiti di dati e accessi del progetto. La differenza riguarda il flusso della conversazione, non un nuovo perimetro di sicurezza.

Decidi se il dubbio è laterale

Prima di aprire /btw, classifica la richiesta in una delle tre destinazioni.

Una domanda può iniziare come esplorazione e diventare una decisione. Non c'è nulla di sbagliato: basta cambiare canale quando cambia l'impatto. Se dalla side chat emerge che il test è inaffidabile e va riscritto, torna nel thread principale con la conclusione e chiedi di aggiornare il piano prima di modificare il file.

Il filtro protegge anche dal problema opposto: aprire una nuova sessione per ogni curiosità. Una domanda circoscritta che usa il contesto corrente non ha bisogno di un secondo incarico, una nuova memoria e un handoff.

Formula una domanda con un confine

Una buona domanda laterale dichiara oggetto, scopo e limite. Invece di scrivere “spiegami questo codice”, prova:

Considera il diff già presente nella sessione.
Spiega perché il test `scadenza_token` usa un clock finto.
Confronta questa scelta con l'uso dell'orologio reale.
Non proporre modifiche ai file: mi serve soltanto capire il trade-off.

Il limite finale evita che una richiesta di comprensione diventi una proposta di refactoring non richiesta. Puoi aggiungere il formato utile: tre punti, una tabella, un esempio minimo. Non serve ricopiare tutto il contesto, perché la side chat vede il thread principale fino a quel momento; indica però il file, il diff o la decisione a cui ti riferisci per ridurre l'ambiguità.

Se la domanda contiene due problemi, separali. “Spiegami il test e poi correggilo” unisce esplorazione e modifica. La prima parte può stare nella side chat; la seconda deve tornare al thread principale con scope e criterio di accettazione.

Usa il contesto senza riaprire tutto

Il valore della side chat sta nel poter riferirsi al lavoro corrente. Non devi creare un riassunto completo per chiedere che cosa significa un errore già visibile o quale assunzione sostiene il piano.

Indica il punto esatto:

• “nel secondo blocco del piano”;

• “nel diff di parser.ts”;

• “nell'errore del test appena eseguito”;

• “nella scelta tra cache locale e remota”.

Poi formula una domanda che possa chiudersi. “Quali sono i due rischi principali di questa scelta?” produce un risultato verificabile. “Dimmi tutto quello che pensi” apre un secondo percorso senza un criterio di fine.

Non usare la side chat per conservare un'informazione che deve sopravvivere alla sessione. Se emerge una convenzione del repository, va nel file di istruzioni appropriato. Se emerge una decisione, va nel registro o nel documento di progetto. Se è soltanto una spiegazione utile in quel momento, può restare laterale.

Non affidare modifiche alla side chat

La documentazione descrive la side chat come un ramo che non aggiunge il proprio scambio al thread principale. Questo è un ottimo motivo per non usarla come canale di modifica.

Immagina di chiedere lateralmente: “Sarebbe meglio rinominare questo campo?”. La risposta propone expires_at, tu approvi e subito chiedi di applicarlo. Il thread principale, però, non contiene la motivazione né la decisione. Alla ripresa può continuare con il nome precedente o produrre un riepilogo incoerente.

Per una modifica, usa questo passaggio:

1. chiudi l'esplorazione laterale;

2. riassumi la conclusione in una frase;

3. indica i file o il piano interessati;

4. chiedi nel thread principale di confermare l'impatto;

5. applica la modifica soltanto dopo l'aggiornamento del mandato.

La duplicazione è intenzionale: trasforma un'idea in una decisione visibile. Non copiare l'intera side chat; porta soltanto ciò che il lavoro principale deve conoscere.

Riporta una conclusione nel thread principale

Usa una ricevuta di rientro con tre campi:

Conclusione: il clock finto rende deterministico il test sulla scadenza.
Impatto: nessuna modifica richiesta al codice; aggiungere una nota nel piano di test.
Decisione richiesta: confermi che la nota entri nella consegna?

Se la conclusione non cambia nulla, non serve riportarla. Il valore della side chat è anche evitare che ogni curiosità diventi parte permanente del lavoro. Se invece cambia criterio di accettazione, scope o implementazione, il rientro è obbligatorio.

Chiedi al thread principale di ripetere la nuova decisione con le proprie parole quando l'impatto è alto. Questo piccolo readback scopre equivoci prima che diventino modifiche. Se la decisione coinvolge altre persone o sessioni, aggiorna il file condiviso che le governa: il transcript non è un broadcast affidabile.

Conserva soltanto ciò che diventa decisione

Una conversazione laterale può produrre tre tipi di risultato:

• una spiegazione transitoria, utile soltanto per capire;

• un'ipotesi da provare;

• una decisione che cambia il lavoro.

La prima può scomparire con la sessione. La seconda entra in una lista di prove con un criterio di conferma o smentita. La terza va nel documento canonico con data, motivazione e conseguenze. Conservare tutto crea rumore; non conservare una decisione crea perdita di contesto.

Nel programma per costruire il tuo Second Brain con l'AI questo confine è centrale: conversazioni, memoria e file non hanno la stessa responsabilità. La side chat aiuta a esplorare senza deviare; i file mantengono ciò che deve attraversare strumenti e sessioni.