Vai al contenuto

Le istruzioni di Cowork

Le istruzioni di Cowork si applicano ovviamente all'area Cowork di Claude Desktop. Qui l'assistente esegue codice, opera sul filesystem, attiva skill e server MCP locali, e delega compiti ad agenti che operano in modo autonomo. Le istruzioni 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.».

Il capitolo indica cosa ha senso scrivere a questo livello e cosa lasciare altrove. Propone un template come proposta di partenza e raccoglie gli anti-pattern ricorrenti.

Quando vengono lette

Le istruzioni di Cowork vengono lette all'avvio di ogni sessione di lavoro nell'area Cowork di Claude Desktop, e si compongono nel prompt di sistema della conversazione insieme alle istruzioni generali. Da quel momento valgono per tutta la durata della sessione.

Nella configurazione sono da considerare anche due aspetti particolari.

Il primo riguarda l'uso su macchine diverse, le istruzioni di Cowork vivono nel filesystem della singola macchina su cui Claude Desktop è installato e non si sincronizzano fra computer diversi. Chi usa Claude Desktop su più pc può avere tante configurazioni di Cowork quante sono le installazioni. Conviene decidere se le configurazioni debbano essere allineate o possano divergere. Nel primo caso le si aggiorna insieme quando se ne modifica una, replicando la stessa configurazione manualmente. Nel secondo caso si configura ciascuna macchina secondo le sue esigenze, per esempio se i due pc sono dedicati a usi diversi con strutture di cartelle differenti.

Il secondo riguarda i progetti Cowork, le cui chat ricevono un prompt di sistema composto dalle istruzioni generali, da quelle di Cowork e da quelle del progetto. Se poi il progetto Cowork viene creato partendo da un progetto Chat ed eredita quindi in sola lettura le istruzioni del progetto Chat, il prompt di sistema in quel progetto Cowork comprende anche le istruzioni del progetto Chat ereditato. Le istruzioni di Cowork restano attive in tutte le sessioni Cowork, dentro o fuori da un progetto, e fanno da fondamento a quelle di progetto.

Criteri di collocazione

Nelle istruzioni di Cowork vanno le regole che hanno senso solo in un ambiente in cui Claude esegue codice, opera sul filesystem, attiva skill e server MCP, delega ad agenti. Sono regole operative legate all'esecuzione locale, fuori da quel contesto sarebbero fuori posto.

Rientrano bene le convenzioni operative legate all'ambiente di esecuzione. Nomi e formati dei file, posizione delle cartelle 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.

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 un'osservazione di portabilità inversa rispetto a quella vista nei capitoli precedenti. Le skill di account funzionano ovunque, le skill locali solo sulla macchina su cui sono installate. Una regola di Cowork che richiama una skill locale è coerente con il livello, perché Cowork è già di per sé locale.

Rientrano 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. 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 passaggi.

Una nota finale sulla pertinenza. Nelle istruzioni di 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 ribadisce regole già attive nelle generali o che anticipa specificità di singoli progetti diluisce le regole davvero utili. Il livello esiste per dire ciò che è specifico dell'ambiente Cowork.

Esempi di collocazione

Un esempio rende concreto cosa va a questo livello e riguarda la gestione degli agenti. Si lavora regolarmente con catene di delega in cui Claude assegna porzioni del lavoro ad agenti autonomi che a loro volta possono delegare a sub-agenti. Si vuole che le priorità fra strumenti decise nelle istruzioni di Cowork valgano lungo tutta la catena. La regola «le priorità fra strumenti definite in queste istruzioni si applicano anche agli agenti delegati e ai loro sub-agenti» propaga il criterio lungo l'esecuzione. Senza una regola esplicita di estensione, gli agenti possono scegliere strumenti diversi da quelli del Claude principale, e sui lavori lunghi questo produce risultati incoerenti.

Un template di configurazione commentato

Il template che segue è pensato come proposta di partenza per le istruzioni di Cowork, non come modello da replicare. Il criterio di fondo è quello visto nella sezione Criteri di collocazione. 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.

## 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.]

Le cinque sezioni rispecchiano le categorie di regole tipiche di Cowork. Non c'è una sezione Profilo né una sezione Preferenze di default, perché quei contenuti vivono al livello base. 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 è coerente con il livello. Diventa un problema solo se la stessa skill non è installata sugli altri pc su cui Cowork viene usato e si vuole importare la stessa configurazione. 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. 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. Sui lavori lunghi questo può produrre risultati incoerenti, perché un agente può scegliere criteri diversi da quelli del Claude principale. L'effetto si amplifica nelle catene a più livelli, dove ogni passaggio può aggiungere una propria deviazione.

La sezione Workflow operativi è opzionale. 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 nota più estesa.

  • Il primo è l'inserimento nelle istruzioni di Cowork di regole che varrebbero ovunque. Si scrive in 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 nelle sessioni Cowork. Negli altri ambienti non viene letta, anche se varrebbe altrettanto bene anche lì. Il rimedio è promuovere la regola al livello giusto, le istruzioni generali, lasciando in Cowork solo l'eventuale specializzazione legata all'ambiente. La pratica della promozione e della retrocessione delle regole è trattata in modo sistematico al capitolo 7.

  • Il secondo è speculare al primo. È l'accumulo nelle istruzioni di Cowork di specificità che riguardano singoli progetti Cowork. Si lavora a un progetto specifico, si individua una convenzione utile, la si scrive in 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 ambito naturale e non interferisce con il resto.

  • Il terzo è la dipendenza implicita dalla macchina, combinata con l'aspettativa di portabilità. Si scrive in 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 di 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 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. Sui lavori 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.

Una rilettura periodica delle istruzioni di Cowork aiuta a intercettare questi errori sul nascere. Vale soprattutto perché alcuni di essi maturano nel tempo, man mano che si aggiungono regole senza rivedere quelle già presenti.