Le istruzioni Cowork di Claude: l’ambiente locale

Cowork è un ambiente di Claude Desktop e vive solo localmente, sul filesystem della macchina su cui è installato. Le istruzioni Cowork si configurano da Impostazioni > Cowork, in un campo di testo libero accompagnato dalla descrizione «Le istruzioni qui si applicano a tutte le sessioni Cowork. Usa questo spazio per preferenze, convenzioni o contesto che Claude dovrebbe sempre conoscere.». Si applicano a tutte le sessioni Cowork e convivono con le istruzioni generali senza sostituirle. Nella mappa della serie sono il livello dedicato alle regole utili nel contesto di lavoro locale di Cowork.

Come Cowork anche le sue istruzioni sono locali, attive nel filesystem del singolo computer e non si sincronizzano fra macchine diverse. Chi usa Claude Desktop su più pc può avere tante configurazioni Cowork quante sono le installazioni. Sono inoltre di ambiente, riguardano un’area di Claude Desktop in cui l’assistente esegue codice, opera sul filesystem, attiva skill e server MCP e delega compiti ad agenti. Questo cambia il tipo di regole che ha senso scrivere qui. La combinazione delle due cose, località e ambiente di esecuzione, definisce il perimetro del livello e orienta gran parte delle scelte di configurazione che ne discendono.

Le pagine che seguono descrivono come queste istruzioni entrano in gioco, come si collocano nella gerarchia rispetto alle istruzioni generali, e cosa ha senso scrivere a questo livello. La chiusura, come per gli altri articoli della serie, propone uno scheletro commentato come punto di partenza.

Quando entrano in gioco

Le istruzioni Cowork entrano in gioco a ogni sessione di lavoro avviata nell’area Cowork di Claude Desktop. Ogni volta che si apre una nuova chat in Cowork, queste istruzioni vengono composte nel prompt di sistema insieme alle istruzioni generali nella finestra di contesto. Da quel momento valgono per tutta la durata della sessione.

L’ambiente in cui operano è la differenza che orienta il tipo di regole. Cowork è un ambiente di esecuzione locale in cui Claude esegue codice, opera sul filesystem, attiva skill e server MCP, sia locali sia di account. Può anche delegare compiti ad agenti che operano in modo autonomo, eventualmente strutturati su più livelli quando un agente a sua volta delega a sub-agenti. Queste capacità sono peculiari di Cowork e sono assenti, o presenti con meccanismi e limiti diversi, nelle altre aree consumer di Claude.

Sul momento dell’aggiornamento il meccanismo è lo stesso degli altri livelli. Quando si modificano le istruzioni Cowork e si salva, la nuova versione entra in vigore dalle sessioni successive. Le sessioni già aperte continuano con la versione letta al loro avvio, perché è in quel momento che il prompt di sistema viene composto. Se una nuova regola deve applicarsi a una sessione in corso, va richiamata esplicitamente nel turno successivo, oppure va avviata una sessione nuova.

Resta poi un aspetto pratico della località. Le istruzioni Cowork restano sul computer su cui sono state configurate e non seguono l’utente quando passa a un’altra macchina. La configurazione di un pc va replicata manualmente sull’altro, oppure mantenuta consapevolmente diversa. Quando si lavora su più pc con Claude Desktop installato, conviene decidere se le configurazioni Cowork debbano essere allineate o possano divergere. Nel primo caso le si aggiorna insieme quando si modifica una di esse. Nel secondo caso si configura ciascuno secondo le sue esigenze, per esempio se i due pc sono dedicati a usi diversi con strutture di cartelle differenti.

La posizione nella gerarchia

Le istruzioni Cowork sono un livello specifico dell’ambiente Cowork e si stratificano sopra le istruzioni generali quando una chat viene aperta in quell’area. All’apertura di una sessione i due livelli vengono composti insieme nel prompt di sistema. Da quel momento operano insieme, come se la configurazione effettiva fosse la sovrapposizione dei due. La metafora utile è la stessa già vista negli altri articoli della serie. Le istruzioni generali restano attive e fanno da fondamento, le istruzioni Cowork si sovrappongono per affinare il comportamento di Claude in quel contesto.

In caso di conflitto fra i due livelli prevale quello più specifico, cioè quello Cowork. La regola Cowork è stata scritta apposta per quel contesto, e in caso di contraddizione con le generali è un’indicazione esplicita dell’autore. Se invece le due regole operano su piani diversi, si combinano senza bisogno di scegliere fra loro.

Il perimetro delle istruzioni Cowork è stretto, valgono solo nelle sessioni avviate dall’area Cowork di Claude Desktop. Le sessioni avviate altrove, su claude.ai, sull’app per smartphone o anche nell’area Chat di Claude Desktop dello stesso computer, non leggono le istruzioni Cowork. La stessa regola che in Cowork prevale sulle generali, fuori da Cowork non esiste come prevalenza, semplicemente perché non viene letta.

Vale qui la stessa osservazione fatta negli articoli precedenti sui livelli ancora più specifici. Quando si lavora dentro un progetto Cowork, le istruzioni di progetto si stratificano sopra le istruzioni Cowork e ne possono prevalere sul perimetro del progetto. Gli stili di scrittura, trattati nell’articolo dedicato della serie, si stratificano ancora sopra e possono prevalere sul piano della formulazione delle risposte. Le istruzioni date nel corso di una chat sono l’ultima parola, anche rispetto a una regola Cowork formulata in modo blindato, perché vivono al livello più specifico che esista, quello del momento.

Cosa scrivere nelle istruzioni Cowork

Il criterio guida per le istruzioni Cowork è la specificità all’ambiente. Vanno qui le regole che hanno senso quando Claude lavora con accesso al filesystem, esecuzione di codice, skill e server MCP. Fuori da quel contesto sarebbero fuori posto. Tutto ciò che è pervasivo a tutti i lavori dell’utente appartiene alle istruzioni generali. Tutto ciò che è specifico di un singolo progetto appartiene alle istruzioni del progetto. I compiti puntuali stanno nei prompt delle singole chat.

Rientrano bene nelle istruzioni Cowork le convenzioni operative legate all’ambiente di esecuzione. Nomi e formati dei file, posizione dei file di output, gestione dei backup prima di modificare file esistenti. Indicazioni sulla produzione di codice, dalla versione del linguaggio target alla gestione degli errori e allo stile dei commenti. Sono regole che presuppongono un ambiente in cui Claude effettivamente legge e scrive sul disco e talvolta esegue codice. In un ambiente solo conversazionale non avrebbero significato.

Rientrano bene le regole sull’uso delle skill e degli strumenti di ricerca. Quali skill consultare come prima fonte, come integrarle con altri strumenti, in che ordine usare i tool nativi rispetto agli MCP. Quando preferire un MCP locale a uno di account. Vale qui la stessa logica vista nei primi articoli della serie. Le skill di account funzionano ovunque, quelle locali solo sulla macchina su cui sono installate. Una regola Cowork che richiama una skill locale è coerente con il livello, perché Cowork è già di per sé locale.

Rientrano bene le regole sull’uso degli agenti. Quando delegare e quando eseguire direttamente, livello di autonomia degli agenti, momenti in cui Claude si ferma a chiedere conferma e ambiti in cui può procedere fino al completamento. Sono regole che hanno senso solo dove gli agenti sono disponibili, e dove i compiti possono richiedere sequenze lunghe di passi senza supervisione continua. Conviene estendere agli agenti anche le regole più generali del livello, ad esempio sulle priorità fra strumenti, perché un agente che applica criteri diversi da quelli del Claude principale produce risultati incoerenti. La regola si propaga lungo la catena, quando un agente a sua volta delega a sub-agenti i criteri vanno mantenuti su tutti i livelli.

Non rientrano, e vanno spostate altrove, alcune categorie. Le regole che valgono ovunque appartengono alle istruzioni generali. Se una preferenza si applica indistintamente a tutto il lavoro, scriverla nelle istruzioni Cowork la rende invisibile fuori dall’ambiente, e prima o poi va replicata altrove. Le istruzioni di progetto Cowork raccolgono ciò che è specifico del singolo progetto. Inserire queste specificità nelle istruzioni Cowork generiche diluisce il livello con regole che riguardano solo una parte dei lavori. I compiti puntuali, le richieste specifiche, i prompt di task vanno direttamente nella chat che li riceve. Sono regole consumate al primo turno e non hanno motivo di restare nel prompt di sistema delle conversazioni successive.

Quattro esempi rendono concrete le situazioni più frequenti.

Il primo è un caso di specializzazione che si risolve per prevalenza. Le istruzioni generali chiedono di rispondere in italiano e di scrivere i contenuti in prosa narrativa. Nelle istruzioni Cowork si stabilisce che i file di documentazione tecnica destinati a un repository pubblico siano scritti in inglese. Il formato prevede elenchi di feature, prerequisiti e step di installazione. Nelle sessioni Cowork che producono questi file prevale la regola Cowork, perché il contesto la rende pertinente. Fuori dall’ambiente Cowork la regola generale continua a valere ovunque.

Il secondo è una combinazione su piani diversi che non richiede di scegliere. Le istruzioni generali chiedono italiano. Le istruzioni Cowork chiedono che i file creati abbiano nomi descrittivi in italiano con trattini come separatore. Ogni file destinato alla pubblicazione viene salvato anche come copia di backup nella cartella dedicata. Le tre regole, lingua, nomenclatura e backup, operano su piani diversi e si applicano insieme senza bisogno di scegliere fra loro.

Il terzo è un caso di regola che sembrerebbe pertinente alle istruzioni Cowork ma in realtà appartiene alle istruzioni generali. Si scrive nelle Cowork «verifica sempre la data delle fonti web e scarta quelle più vecchie di sei mesi sui temi a rapida evoluzione». La regola riguarda la verifica delle fonti, è un metodo di lavoro che ha senso ovunque Claude faccia ricerche, non solo in Cowork. Il suo posto sono le istruzioni generali. Se ci sono specificità sull’uso degli strumenti di ricerca in Cowork, ad esempio una priorità fra tool, quelle sì restano qui. La regola metodologica generale va promossa al livello base.

Il quarto è un caso di regola che sembrerebbe pertinente ma appartiene alle istruzioni di progetto Cowork. Si scrive nelle Cowork «per i contenuti relativi al cliente XYZ usa sempre la terminologia del glossario nella cartella D:\Progetti\XYZ\glossario.md». La regola fa riferimento a un cliente specifico e a una cartella specifica, non a tutto il lavoro in Cowork. Il suo posto è il campo istruzioni di un progetto Cowork dedicato a quel cliente. Lì la regola vive nel suo perimetro naturale e non interferisce con altri lavori.

Anche nelle istruzioni Cowork la sintesi paga, ma non al prezzo di omettere convenzioni operative che caratterizzano davvero questo livello. Il punto di equilibrio sta nella pertinenza, ogni regola dovrebbe dire qualcosa di specifico per Cowork. Una configurazione che ripete cose già dette nelle generali o anticipa specificità che varrebbero solo per certi progetti diluisce le regole davvero pertinenti. Il livello esiste per dire ciò che è specifico dell’ambiente Cowork, non per ribadire il default né per anticipare il particolare.

Un template di configurazione commentato

Lo scheletro che segue è pensato come punto di partenza, non come modello da replicare. Il criterio di fondo è quello visto nella sezione precedente, qui va solo ciò che è specifico dell’ambiente Cowork. Le sezioni sono indicative, possono essere fuse, divise o rinominate in base al proprio modo di lavorare. Quello che conta è che ogni blocco contenga regole legate al fatto che Cowork esegue codice, opera sul filesystem e attiva skill e MCP.

## File e output

[Convenzioni sui nomi dei file, formati di salvataggio, posizione
delle cartelle di output, gestione dei backup prima di modificare
file esistenti. Indicazioni che presuppongono accesso effettivo
al filesystem.]

## Skill e strumenti

[Quali skill consultare come prima fonte, in che ordine, come
integrarle con altri strumenti. Priorità fra tool nativi e server
MCP, preferenze fra MCP locali e di account. Solo le indicazioni
che valgono per tutto il lavoro in Cowork.]

## Produzione di codice

[Versione del linguaggio target, gestione degli errori di base,
stile dei commenti. Convenzioni di formato e organizzazione del
codice prodotto.]

## Agenti

[Quando delegare compiti ad agenti, livello di autonomia,
momenti di verifica obbligatoria, regole generali del livello
da estendere agli agenti e da mantenere lungo la catena
quando un agente delega a sub-agenti.]

## Workflow operativi (opzionale)

[Procedure ricorrenti che riguardano l'intero ambiente Cowork.
Sequenze tipiche di passi per gestire una categoria di compiti,
verifiche obbligatorie prima di certe azioni.]

Qualche osservazione su come è costruito lo scheletro. Le cinque sezioni rispecchiano le categorie di regole tipiche di questo livello e tralasciano i temi che appartengono ad altri. Non c’è una sezione Profilo, perché il profilo dell’utente è nelle generali. Non c’è una sezione Preferenze di default, perché le preferenze pervasive su lingua, registro e stile generale appartengono alle generali. Qui si scrive solo dove ci si discosta per ragioni legate all’ambiente.

La sezione File e output è quella che caratterizza maggiormente il livello. Tutte le regole su nomi, formati, posizione e backup hanno senso solo dove Claude tocca davvero il filesystem. Va riempita con cura, è il punto in cui la configurazione produce gli effetti più visibili nel lavoro quotidiano. Va riempita anche con misura, evitando di anticipare convenzioni che varrebbero solo per certi progetti.

La sezione Skill e strumenti è la più delicata sul piano della portabilità tra macchine. Una regola che richiama una skill di account funziona ovunque. Una regola che richiama una skill locale funziona solo sulla macchina su cui la skill è installata. Per Cowork, che è già di per sé locale, una regola che presuppone una skill locale non è un anti-pattern. Diventa un problema solo se la stessa skill non è installata sui pc su cui Cowork viene usato. In quel caso la regola va vincolata alla configurazione effettiva di ciascuna macchina.

La sezione Produzione di codice va tenuta misurata. Le indicazioni di stile producono effetti se Cowork viene usato regolarmente per scrivere codice, hanno meno valore se l’attività di codifica è occasionale. Conviene scriverle solo dopo essere arrivati a una preferenza stabile, altrimenti il rischio è di vincolare Claude a convenzioni che si vorranno cambiare presto.

La sezione Agenti è la più tipica di Cowork. È il solo ambiente consumer di Claude in cui l’uso di agenti è disponibile, anche in catene a più livelli quando un agente a sua volta delega a sub-agenti. Le regole qui dicono dove e quando delegare, con quale autonomia, e come trasferire agli agenti i criteri del livello. Una configurazione che non si esprime sugli agenti lascia il comportamento al default di Claude. Su task lunghi questo può produrre risultati incoerenti, perché un agente può scegliere criteri diversi da quelli del Claude principale, e l’effetto si amplifica nelle catene a più livelli, dove ogni passaggio può aggiungere una propria deviazione.

La sezione Workflow operativi è opzionale e va affrontata solo se ci sono procedure ricorrenti che caratterizzano davvero il modo di lavorare in Cowork. Una sequenza di passi che si ripete ogni volta che si produce una certa tipologia di file, una verifica obbligatoria prima di certe azioni, un protocollo di salvataggio. Si distingue dalle altre sezioni perché riguarda il quando e il come ordinare le azioni, mentre le altre riguardano i contenuti di ciascuna azione.

Anti-pattern ricorrenti

Quattro errori si ripetono con sufficiente frequenza da meritare una trattazione distesa. Sono i comportamenti che separano una configurazione Cowork efficace da una che produce risultati incoerenti senza che si capisca subito perché.

Il primo è l’inserimento nelle istruzioni Cowork di regole che varrebbero ovunque. Si scrive nelle Cowork una preferenza di metodo, una convenzione linguistica, una regola di verifica delle fonti. La si formula mentre si lavora in Cowork, e Cowork è il campo che si ha sotto gli occhi. Il risultato è che la regola si applica solo in Cowork. Negli altri ambienti, claude.ai, app per smartphone, area Chat di Claude Desktop, non viene letta, anche se varrebbe altrettanto bene anche lì. La soluzione è semplice nell’enunciato e disciplinata nell’applicazione. Ogni volta che si scrive una regola nelle Cowork vale la pena chiedersi se vale solo lì o ovunque. In caso di risposta «ovunque» va promossa nelle istruzioni generali, e la versione Cowork va rimossa o ridotta a eventuali specializzazioni residue.

Il secondo è speculare al primo, ed è l’accumulo nelle istruzioni Cowork di specificità che riguardano singoli progetti Cowork. Si lavora a un progetto specifico, si individua una convenzione utile, la si scrive nelle Cowork pensando «così la trovo sempre». Il problema è che la convenzione si applica anche alle sessioni di altri progetti dove non c’entra nulla. Lì compare come rumore residuo che orienta il comportamento di Claude in modo inappropriato. La soluzione è la disciplina della collocazione, ogni regola che riguarda un singolo progetto Cowork va nel campo istruzioni di quel progetto. Lì vive nel suo perimetro naturale e non interferisce con il resto.

Il terzo è la dipendenza implicita dalle macchine sotto l’ipotesi di portabilità. Si scrive nelle Cowork una regola che richiama un percorso del filesystem o una skill locale. Cowork è già di per sé locale e la dipendenza è coerente con il livello. Fin qui nessun problema. Il problema nasce quando Claude Desktop viene installato su un secondo pc. Le istruzioni Cowork del secondo pc partono vuote. La stessa regola, replicata o no, si scontra con un percorso diverso o una skill non installata. La regola in sé non era sbagliata, sbagliata era l’ipotesi implicita che la configurazione fosse la stessa ovunque. La soluzione è duplice. Dichiarare nella configurazione di un pc le dipendenze locali presupposte, in modo che il lettore-autore le veda sotto gli occhi quando rilegge la sua configurazione. Decidere consapevolmente se le configurazioni di pc diversi vanno tenute allineate o lasciate divergere, e in entrambi i casi gestirle con una procedura di manutenzione coerente.

Il quarto è la configurazione che si esprime sugli agenti senza estendersi alla catena. Si scrive una regola operativa per Claude, ad esempio sulle priorità fra strumenti. La si formula come se valesse solo per il Claude principale che riceve direttamente la richiesta dell’utente. Quando il Claude principale delega a un agente, la regola può essere interpretata come riferita solo al primo. La formulazione tipica parla di «Claude» o di «il sistema», senza specificare chi è incluso quando ci sono catene di delega. Su task lunghi che richiedono catene di delega, l’effetto è una progressiva deriva dalle regole impostate. La soluzione è l’estensione esplicita. Formulazioni come «questa priorità vale anche per i sub-agenti» propagano la regola lungo tutta l’esecuzione. Senza un’estensione esplicita, la regola vincola solo il primo passo.

In tutti e quattro i casi vale un’osservazione di metodo. La revisione periodica delle istruzioni Cowork, fatta a freddo a distanza di settimane dalla scrittura, è il modo più economico per intercettare questi errori prima che producano effetti. Le configurazioni che restano efficaci nel tempo sono quelle riviste con disciplina, non quelle scritte una volta sola e dimenticate.

Verso gli stili di scrittura

Le istruzioni Cowork sono il livello in cui la configurazione di Claude si lega all’ambiente di esecuzione locale. Le scelte di scrittura producono qui effetti tangibili sui file, sul codice, sulle catene di delega che operano sul computer dell’utente. Una configurazione Cowork scritta con disciplina dichiara apertamente le dipendenze dalle macchine ed estende le regole agli agenti che operano lungo la catena. È la base di un ambiente di lavoro che si comporta in modo coerente sessione dopo sessione, anche su task lunghi e parzialmente automatizzati.

Il prossimo articolo della serie affronta gli stili di scrittura, cioè il livello che opera in modo ortogonale agli altri tre. Non istruisce Claude su come comportarsi in generale, ma su come formulare le risposte, intervenendo su formato, tono e registro. È un livello che si attiva e si disattiva per conversazione. Si stratifica sopra tutti gli altri visti finora, prevalendo sul piano della forma anche quando le regole sottostanti dicono il contrario. È il quarto e ultimo livello della serie, e la sua specificità diventa più chiara nei casi pratici dell’articolo dedicato.