Le istruzioni di progetto di Claude: cosa scriverci

Le istruzioni di progetto sono il livello di configurazione che specializza il comportamento di Claude all’interno di un singolo progetto. Il concetto di progetto è trasversale a tre ambienti, claude.ai, l’area Chat di Claude Desktop e l’area Cowork dello stesso Desktop, e in ciascuno di essi un progetto dispone di un campo dedicato alle istruzioni di progetto, distinto dal prompt delle singole chat. A differenza del campo Profilo delle istruzioni generali, qui non c’è una descrizione persistente che resti visibile a campo compilato, solo un placeholder che scompare al primo inserimento e che varia leggermente da ambiente a ambiente, pur mantenendo lo stesso significato di fondo, ad esempio nei progetti Cowork compare la formula «Aggiungi tono, formattazione o regole per guidare il funzionamento di Claude». Si applicano a tutte le conversazioni aperte dal progetto e si sovrappongono alle istruzioni generali. Nella mappa della serie sono il primo livello specifico della gerarchia, quello in cui i meccanismi di prevalenza descritti nell’articolo sulle istruzioni generali diventano operativi nel lavoro quotidiano.

Una nota di confine prima di entrare nel merito. La serie è sui file di configurazione, e questo articolo si concentra esclusivamente sul testo delle istruzioni di progetto. Non tratta i file caricati nel progetto, che sono materiale di lavoro a disposizione di Claude ma non sono istruzioni. Non tratta nemmeno la memoria di progetto, un meccanismo separato di accumulo automatico di informazioni a partire dalle conversazioni, anche se gestibile dall’utente. Sono tutti elementi che caratterizzano l’esperienza dei progetti, ma operano su piani diversi e hanno regole proprie. È anche l’articolo della serie che più si mescola con altri argomenti.

Le pagine che seguono descrivono come queste istruzioni entrano in gioco e come si rapportano alle istruzioni generali. Mostrano come la stessa istruzione di progetto possa comportarsi diversamente a seconda dell’ambiente in cui viene letta, e illustrano cosa ha senso scrivere a questo livello e cosa lasciare altrove. La chiusura, come per gli altri articoli della serie, propone uno scheletro commentato come punto di partenza.

La posizione nella gerarchia

Le istruzioni di progetto sono il primo livello specifico della gerarchia. Stanno sopra le istruzioni generali e si applicano solo al perimetro del progetto. All’apertura di una chat all’interno del progetto, i due livelli vengono composti insieme in un unico prompt di sistema, e da quel momento operano insieme, come se la configurazione effettiva di quella conversazione fosse la sovrapposizione dei due. La metafora utile è quella della stratificazione, le istruzioni generali restano attive e fanno da fondamento, le istruzioni di progetto si sovrappongono per affinare il comportamento di Claude in quel contesto specifico.

In caso di conflitto fra i due livelli prevale quello più specifico, cioè il livello di progetto. La regola di progetto è 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.

Un esempio di conflitto che si risolve per prevalenza, le istruzioni generali chiedono a Claude di rispondere in italiano, le istruzioni di un progetto relativo a una committenza internazionale chiedono di rispondere in inglese. Nelle chat di quel progetto Claude scrive in inglese, fuori dal progetto continua a scrivere in italiano. Non è necessario togliere la regola dalle istruzioni generali, e anzi è preferibile lasciarla, perché continua a valere per tutto il resto.

Un esempio di combinazione su piani diversi, le istruzioni generali chiedono italiano, le istruzioni di un progetto chiedono registro formale. Le due regole non sono in conflitto, una riguarda la lingua, l’altra il registro, e si applicano insieme. Nelle chat di quel progetto Claude risponde in italiano con registro formale.

Vale qui la stessa osservazione fatta nell’articolo precedente sui livelli ancora più specifici. Gli stili di scrittura, trattati nell’articolo dedicato della serie, si stratificano sopra le istruzioni di progetto e ne 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 di progetto, perché vivono al livello più specifico che esista, quello del momento. Se in una chat di un progetto in cui le istruzioni chiedono inglese viene chiesto esplicitamente a Claude di rispondere in italiano per quella risposta, Claude risponde in italiano, salvo nuove istruzioni successive.

Anche per le istruzioni di progetto vale quanto detto per le generali sulla modalità di lettura. Non sono comandi eseguiti meccanicamente, sono contesto che entra nel prompt di sistema insieme ad altri elementi, e Claude interpreta l’insieme. Una conseguenza specifica del livello di progetto è che ogni regola scritta qui si somma a quanto già scritto nelle generali. Conviene scrivere le istruzioni di progetto sapendo che le generali continuano a valere, e limitarsi a esprimere ciò che è effettivamente specifico del progetto. Riprendere alla lettera regole già presenti nelle generali non aggiunge robustezza, aggiunge rumore.

Quando entrano in gioco

Le istruzioni di progetto entrano in gioco a ogni nuova conversazione avviata all’interno di un progetto, in ognuno dei tre ambienti in cui i progetti vivono.

Per quanto riguarda claude.ai e l’area Chat di Claude Desktop i progetti condividono lo stesso spazio server, quindi un progetto creato in un ambiente compare anche nell’altro con le stesse istruzioni associate. Spazio server condiviso però non significa ambiente di esecuzione equivalente. L’interfaccia web di claude.ai non accede al filesystem locale, non può attivare server MCP locali e non può accedere alle skill locali, mentre la Chat in Claude Desktop può fare tutte queste cose, anche se con meccanismi diversi da quelli di Cowork. La conseguenza pratica è che la stessa istruzione di progetto, letta nei due ambienti, può sortire effetti molto diversi. Prima ancora di scrivere le istruzioni, allora, conviene decidere se quel progetto verrà usato in entrambi gli ambienti o solo in uno, perché la decisione orienta cosa è sensato scrivere. Un’istruzione che fa riferimento a percorsi locali o a MCP non disponibili sull’interfaccia web ha senso solo nei progetti destinati all’uso in Desktop. La sezione La stessa istruzione, ambienti diversi entra nel dettaglio di questo punto.

I progetti Cowork sono invece una famiglia separata e locale, vivono solo dentro Claude Desktop, non compaiono in claude.ai e hanno il proprio elenco di istruzioni distinto. La separazione non è solo organizzativa, è strutturale, perché Cowork opera all’interno di un ambiente di esecuzione locale, sul computer dell’utente, in cui Claude può lanciare codice, leggere e scrivere file, attivare server MCP che vivono solo lì. Il dettaglio è nell’articolo dedicato a Cowork, qui basta tenere presente che un progetto Chat e un progetto Cowork sono cose diverse anche quando ruotano attorno allo stesso lavoro.

Il prompt di sistema, una volta composto, resta nella finestra di contesto per tutta la durata della conversazione, e ogni messaggio successivo si appoggia su di esso. Le conversazioni avviate fuori da un progetto, invece, non leggono le istruzioni di progetto, leggono solo le istruzioni generali, perché il prompt di sistema in quel caso si compone soltanto del livello base.

Da questo meccanismo discende anche il momento dell’aggiornamento. Le modifiche entrano in vigore dalle conversazioni successive, perché solo quelle leggono il prompt di sistema aggiornato, le chat già aperte continuano con la versione letta al loro avvio. Se la nuova regola deve applicarsi subito a una conversazione in corso, va richiamata esplicitamente nel turno successivo, oppure va avviata una chat nuova all’interno dello stesso progetto.

Le regole di prevalenza alla prova del contesto

La regola «prevale il livello più specifico» è limpida sulla carta, ma nella pratica va calata in due dinamiche che meritano di essere viste da vicino. La prima riguarda l’asimmetria fra una regola argomentata in un livello e una regola secca in un altro. La seconda riguarda il rapporto fra le istruzioni configurate e i segnali che arrivano dalla conversazione stessa. Anche qui l’esempio della lingua resta il più nitido, e lo riprendo per continuità.

Si pensi a una configurazione in cui le istruzioni generali chiedono di rispondere in italiano, accompagnando la richiesta con una motivazione lunga, ad esempio una nota che spiega il pubblico, l’ambito di lavoro, qualche caso d’uso. Nelle istruzioni di un progetto specifico c’è invece la regola secca «rispondi in inglese». La domanda è quale lingua verrà usata in quel progetto. La risposta resta quella vista nella sezione La posizione nella gerarchia, prevale il livello più specifico, quindi l’inglese, perché la prevalenza è governata dalla specificità del livello e non dalla lunghezza del testo o dalla forza argomentativa. La regola di progetto è scritta apposta per quel contesto, e questo basta.

Va detta però una sfumatura. Il prompt di sistema effettivo è la concatenazione dei due livelli, e l’asimmetria fra una motivazione articolata e un’istruzione di una riga può introdurre un margine di rumore interpretativo, soprattutto in casi limite, ad esempio quando l’utente scrive in italiano e l’argomento è stato discusso in italiano nelle motivazioni delle generali. Non si tratta di un’inversione della prevalenza, è un comportamento residuale che si manifesta come una tendenza a propendere verso la lingua più presente nel contesto. Si previene scrivendo la regola di progetto in modo netto e univoco, e tenendo le motivazioni nelle generali brevi e funzionali. C’è anche un risvolto non tecnico, una motivazione lunga che convive con una regola secca trasmette al lettore-autore una percezione di squilibrio, e questa asimmetria diventa essa stessa fonte di confusione quando si rilegge la propria configurazione settimane o mesi dopo. La logica della stratificazione conviene affidarla alla struttura, non alla retorica.

La seconda dinamica è più interessante e tocca un punto che vale la pena rendere esplicito. Si immagini la stessa configurazione di prima, italiano nelle generali, inglese nel progetto, e si supponga che nella chat del progetto l’utente scriva in italiano. Claude ha tre segnali simultanei, le generali chiedono italiano, il progetto chiede inglese, il messaggio appena ricevuto è in italiano. Il comportamento osservato in casi come questo è che Claude risponda in italiano, non in inglese. La regola di progetto, pur scritta correttamente e in linea con i meccanismi di prevalenza, perde nei fatti.

Non è un’eccezione alla regola, è il modo in cui Claude bilancia il prompt di sistema con il contesto della conversazione. La lingua usata dall’utente nel suo messaggio è essa stessa un’istruzione, implicita ma molto forte, e Claude tende a rispondere nella lingua dell’interlocutore. È lo stesso meccanismo che fa sì che, in assenza di istruzioni esplicite, l’assistente parli sempre la lingua del prompt che riceve. Quando l’istruzione di progetto richiede un comportamento contrario al segnale contestuale, le due forze si confrontano, e in molti casi vince il contesto.

Da qui due principi di metodo che vale la pena fissare. Le istruzioni di progetto, come quelle generali, non sono comandi vincolanti, sono contesto che entra in dialogo con altro contesto. Quando una regola riguarda un elemento soggetto a deriva contestuale, come la lingua, il tono, il livello di formalità, esprimerla una volta sola non basta a renderla rigida. Per ottenere il comportamento atteso anche di fronte a segnali contrari occorre formulare la regola in modo che anticipi esplicitamente il caso di deriva. Per la lingua, una formulazione del tipo «rispondi sempre in inglese, anche se l’utente scrive in italiano» resiste meglio dell’imperativo neutro «rispondi in inglese». La differenza in apparenza è retorica, in pratica è funzionale. La prima formulazione è chiusa rispetto al contesto, la seconda lascia spazio interpretativo alla conversazione. Il secondo principio è di coerenza personale. Se nelle istruzioni di progetto si è scelta una lingua, conviene che anche i prompt nelle chat di quel progetto siano scritti in quella lingua, perché l’incoerenza fra istruzione configurata e comportamento dell’utente è essa stessa un segnale che indebolisce la regola. Una regola di progetto regge meglio quando l’autore agisce come se la regola fosse già operativa, senza chiedere a Claude di tenere ferma una direzione che chi scrive contraddice in pratica.

Vale la pena ricordare, infine, che le istruzioni date nel corso della chat sono sempre l’ultima parola, anche rispetto a regole di progetto formulate in modo blindato. Se in una chat dove le istruzioni di progetto richiedono inglese l’utente chiede esplicitamente «per questa risposta usa l’italiano», Claude risponde in italiano. È il livello più specifico che esista, e la sua specificità batte tutto il resto.

La stessa istruzione, ambienti diversi

Le istruzioni di progetto sono testo, e il testo è identico ovunque venga letto. Quello che cambia da un ambiente all’altro è ciò che Claude riesce effettivamente a fare con quel testo, perché le capacità a disposizione sono diverse fra l’interfaccia web di claude.ai, l’area Chat di Claude Desktop e l’area Cowork dello stesso Desktop. La conseguenza è che la stessa istruzione di progetto, formalmente identica, può sortire effetti diversi a seconda di dove la chat viene aperta. Capire questa differenza è particolarmente importante per i progetti che vivono nello spazio server condiviso fra web e Chat Desktop, dove la stessa istruzione può effettivamente essere letta in entrambi gli ambienti. C’è anche un caso ulteriore, particolare di Cowork, su cui si torna alla fine della sezione, in cui un progetto Cowork può importare un progetto Chat come contesto, ricevendo le sue istruzioni in modalità non editabile e affiancandole a quelle proprie.

Tre esempi rendono concreto il punto.

Il primo riguarda una skill. Le istruzioni di progetto contengono una regola del tipo «in questo progetto attiva sempre la skill di assistenza editoriale». Se la skill è registrata sull’account, l’istruzione funziona ovunque, web, Chat Desktop, Cowork. Se invece è una skill locale, salvata nel filesystem di un singolo computer, funziona solo lì. Sull’interfaccia web di claude.ai non funziona perché la skill non esiste in quell’ambiente, in Claude Desktop su un altro pc dove la skill non è installata non funziona per lo stesso motivo. L’istruzione è scritta correttamente in entrambi i casi, ma l’effetto dipende dalla disponibilità della risorsa che richiama.

Il secondo riguarda un percorso del filesystem. Le istruzioni di progetto contengono una regola del tipo «i materiali di questo progetto sono nella cartella D:\Progetti\Cliente\». Sull’interfaccia web di claude.ai l’istruzione è priva di effetto, perché il browser non ha accesso al filesystem del computer. In Claude Desktop l’istruzione è interpretabile, perché Desktop può leggere il filesystem locale tramite gli strumenti disponibili in Chat e in Cowork, ma con due caveat. Il primo è che vale solo sul pc in cui quella struttura di cartelle esiste, su un altro computer la stessa istruzione si scontra con un percorso che non esiste, e Claude non può fare nulla. Il secondo è che l’accesso effettivo al filesystem dipende dagli MCP attivati e dalle loro configurazioni, che possono differire fra Chat e Cowork anche sullo stesso pc.

Il terzo è un controesempio utile, una regola di stile puro. Le istruzioni di progetto contengono una formulazione del tipo «rispondi sempre in modo conciso, evita preamboli, vai dritto al punto». Questa istruzione è agnostica rispetto all’ambiente di esecuzione, non fa riferimento a strumenti, file, server. L’effetto sarà lo stesso ovunque, web, Chat Desktop, Cowork, su qualsiasi pc. Le regole che riguardano lingua, tono, registro, livello di approfondimento, schema di risposta sono in genere portabili senza problemi, perché vivono interamente nel testo.

Da questi tre esempi si ricava un criterio operativo. Prima di scrivere una regola nelle istruzioni di progetto conviene chiedersi se la regola è autonoma rispetto all’ambiente, oppure se richiede risorse, percorsi o strumenti che vivono solo in alcuni ambienti. Le regole autonome stanno bene a questo livello, sono portabili e robuste. Le regole che dipendono da risorse locali stanno bene solo nei progetti destinati a un singolo ambiente, cioè Claude Desktop, e in quel caso vale la pena dichiararlo esplicitamente nella prima riga delle istruzioni, ad esempio scrivendo che «questo progetto è pensato per essere usato solo in Claude Desktop». Una nota di questo tipo non vincola Claude, vincola il lettore-autore quando rilegge la propria configurazione. È un piccolo presidio contro la confusione futura.

Resta il caso anticipato in apertura, l’eredità delle istruzioni di un progetto Chat dentro un progetto Cowork. Quando si crea un progetto Cowork si può scegliere di importare un progetto Chat come contesto. In quel caso le istruzioni del progetto Chat compaiono nelle impostazioni del progetto Cowork in modalità di sola lettura, non editabili, e si affiancano al campo istruzioni proprio di Cowork, che resta editabile. Il prompt di sistema effettivo della chat Cowork si compone così di tre strati, le istruzioni generali, le istruzioni del progetto Chat ereditato, le istruzioni del progetto Cowork. È una stratificazione interna allo stesso livello gerarchico, non un nuovo livello, e segue la stessa logica vista nella sezione La posizione nella gerarchia, in caso di conflitto fra due regole prevale la più specifica, in questo caso quella scritta direttamente nel progetto Cowork. La conseguenza pratica è significativa per chi sa già che un progetto Chat farà anche da base a un progetto Cowork. Le istruzioni del progetto Chat vanno scritte tenendo conto che potranno arrivare in un ambiente con capacità più ampie, evitando però di anticipare regole che hanno senso solo in Cowork, perché queste sarebbero rumore in più nelle chat aperte direttamente dal progetto Chat. Le specificità Cowork stanno meglio nel campo istruzioni proprio di Cowork, lasciando il progetto Chat pulito sul suo perimetro. La trattazione completa di Cowork, incluso il meccanismo dell’ereditarietà, è nell’articolo successivo della serie.

Criteri di collocazione

Il criterio guida è la specificità. Nelle istruzioni di progetto vanno solo le regole che riguardano quel progetto e che non avrebbero senso applicate ovunque. Tutto ciò che è generale appartiene alle istruzioni generali, tutto ciò che è specifico dell’ambiente di esecuzione locale appartiene alle istruzioni Cowork, tutto ciò che dura una conversazione appartiene alla chat o agli stili di scrittura.

Rientrano bene nelle istruzioni di progetto le specificità del contesto di lavoro che caratterizzano quel progetto. Il committente o il cliente per cui il progetto è stato creato, l’ambito tematico, gli interlocutori con cui si interagisce, il tipo di output atteso. Sono informazioni che orientano il modo in cui Claude legge le richieste e formula le risposte all’interno del progetto, e non hanno senso fuori da lì.

Rientrano bene anche le preferenze specifiche che si discostano dal default delle istruzioni generali. La lingua, se diversa da quella di default. Il registro, se diverso. La lunghezza, il livello di approfondimento, il formato delle risposte. Tutto ciò che si vuole impostare diversamente rispetto al livello base, e solo per questo progetto. Vale lo stesso per le scelte formali sulla scrittura, schema delle risposte, uso del grassetto e del corsivo, convenzioni di formattazione. Quando si vuole una formattazione stabilmente diversa dal default per un intero progetto, il posto è qui, gli stili di scrittura sono uno strumento più adatto alle variazioni che durano il tempo di una conversazione o di una serie breve di chat.

Rientrano bene le regole metodologiche specifiche. Se il progetto è di brainstorming, può avere senso allentare il rigore di verifica delle fonti che vale come default nelle generali. Se il progetto è di analisi rigorosa, può avere senso al contrario rinforzarlo. Se il progetto richiede una particolare attenzione a certi tipi di errore o a certe distinzioni concettuali, si può scriverlo qui.

Rientrano bene le indicazioni sugli strumenti e le skill che servono in quel progetto, purché siano disponibili negli ambienti in cui il progetto verrà aperto. Una skill di account che si vuole tenere attiva sempre nel progetto, un MCP da privilegiare per le ricerche, una libreria di riferimenti specifica. Va tenuto presente quanto detto nella sezione precedente sulla portabilità, le risorse locali, file, cartelle, skill o MCP installati su un singolo computer, stanno bene solo nei progetti destinati a Claude Desktop, e in quel caso conviene segnalarlo nel testo, riservando comunque al campo istruzioni di Cowork le specificità che dipendono dalle capacità peculiari di quell’ambiente.

Non rientrano, e vanno spostate altrove, le regole che valgono ovunque. Se una regola si applica indistintamente a tutti i lavori dell’utente, il suo posto sono le istruzioni generali. Tenerla nelle istruzioni di un progetto la rende invisibile in tutti gli altri, e prima o poi va riscritta, replicata, dimenticata da qualche parte. La tentazione di duplicarla per sicurezza è una delle trappole più comuni, e viene ripresa nella sezione sugli anti-pattern.

Non rientrano nemmeno le regole che dipendono dalle capacità peculiari di Cowork, esecuzione di codice, scrittura di file in directory di output, automazioni ricorrenti. In un progetto Chat queste regole sono testo che Claude non può tradurre in azione, perché l’ambiente non gliene dà gli strumenti, e appesantiscono il prompt di sistema senza beneficio. Il loro posto è il campo istruzioni di un progetto Cowork, e questa è una distinzione diversa da quella sulle risorse locali genericamente intese, file e MCP installati sul computer, che restano interpretabili anche in Chat Desktop e che vivono bene nelle istruzioni di un progetto Chat di Desktop.

Non rientrano i compiti puntuali e le richieste specifiche. Se un compito è di una conversazione, va nella chat di quella conversazione. Se è di una serie breve di chat all’interno del progetto, può comunque vivere come istruzione di apertura nei singoli prompt, non nel campo istruzioni del progetto. Le istruzioni di progetto sono persistenti e si applicano a tutte le conversazioni successive, vanno usate per le regole che hanno effettivamente questa pervasività dentro il perimetro del progetto.

Un’osservazione finale che chiude la sezione e prepara quella successiva. Nelle istruzioni di progetto la pulizia conta più della completezza. Una configurazione di progetto breve, asciutta, focalizzata su ciò che è davvero specifico, produce un comportamento più affidabile di una configurazione lunga che ripete cose già dette nelle generali. Il livello di progetto esiste per dire la differenza, non per ribadire il default.

Esempi concreti di collocazione e di conflitto

Quattro casi, scelti per illustrare le situazioni più frequenti che si incontrano nella pratica. I primi due sono conflitti fra livelli che si risolvono per prevalenza, il terzo è un’aggiunta non conflittuale, il quarto è una combinazione su piani diversi.

Il primo esempio è il classico della committenza internazionale. Le istruzioni generali chiedono a Claude di rispondere in italiano. Si crea un progetto per una committenza internazionale in cui tutti i documenti vanno in inglese. Nelle istruzioni di progetto si scrive «rispondi sempre in inglese, anche se l’utente scrive in italiano». Nelle chat di quel progetto Claude scrive in inglese, fuori dal progetto continua a scrivere in italiano. La regola generale non viene rimossa, perché continua a valere ovunque tranne lì dentro. La formulazione blindata della regola di progetto, che anticipa il caso in cui l’utente possa scrivere in italiano, riduce il rischio di deriva contestuale visto nella sezione Le regole di prevalenza alla prova del contesto.

Il secondo esempio riguarda il metodo, ed è meno banale del primo perché tocca un aspetto qualitativo del comportamento di Claude. Le istruzioni generali chiedono verifica sistematica delle fonti, segnalazione delle assunzioni non verificate, distinzione esplicita fra fatti e speculazioni. Si crea un progetto dedicato al brainstorming creativo, in cui il rigore metodologico ostacola più di quanto aiuti la generazione di ipotesi. Nelle istruzioni di progetto si scrive una regola che allenta la verifica in favore della produzione di idee, ad esempio «in questo progetto privilegia la generazione di ipotesi rispetto alla verifica, segnalando alla fine quali punti meritano un approfondimento successivo». Nelle chat del progetto Claude opera in modalità brainstorming, fuori torna al rigore metodico del default. Anche qui la regola generale resta nelle generali, perché continua ad essere utile nella maggior parte dei lavori. Si è specializzato il comportamento per un contesto che richiede un’attitudine diversa, senza intaccare il livello base.

Il terzo esempio non è un conflitto ma un’aggiunta. Le istruzioni generali non attivano alcuna skill di default. Si crea un progetto dedicato alla produzione di articoli per il blog, in cui si vuole che la skill di assistenza editoriale sia sempre attiva senza doverla richiamare a ogni chat. Nelle istruzioni di progetto si scrive una regola del tipo «in questo progetto attiva sempre la skill di assistenza editoriale per la produzione di tutti i contenuti scritti». Il livello di progetto introduce un comportamento che il livello base non prevedeva, e che ha senso solo nel perimetro del progetto. Se la skill è di account, l’istruzione funziona in tutti gli ambienti in cui il progetto può essere aperto. Se è una skill locale, funziona solo in Claude Desktop e solo sul computer su cui la skill è installata, in linea con quanto detto nella sezione La stessa istruzione, ambienti diversi.

Il quarto esempio è quello della combinazione su piani diversi, che non richiede di scegliere fra una regola e l’altra. Le istruzioni generali chiedono di rispondere in modo articolato, con stile narrativo e un livello di approfondimento medio-alto. Si crea un progetto editoriale dedicato a una rivista che pubblica testi brevi. Nelle istruzioni di progetto si scrive «la lunghezza massima delle risposte in questo progetto è di 800 parole, salvo diversa indicazione esplicita». Le due regole non sono in conflitto, una riguarda lo stile e la profondità, l’altra il limite quantitativo. Si combinano. Nelle chat di quel progetto Claude risponderà in stile narrativo articolato, mantenendo la profondità desiderata, entro le 800 parole. Quando le regole agiscono su piani distinti non c’è bisogno di scegliere, la stratificazione produce un comportamento più ricco senza dover negoziare priorità.

In tutti i casi vale il principio enunciato all’inizio dell’articolo, le istruzioni di progetto specializzano le generali, non le sostituiscono. Quando una regola può essere risparmiata al livello specifico perché il livello base la copre già, è sempre preferibile farlo. La specializzazione conta solo dove serve, cioè dove il progetto richiede un comportamento diverso da quello di default.

Un template di configurazione commentato

Lo scheletro che segue è pensato come punto di partenza per le istruzioni di un progetto, non come modello da replicare. Il criterio di fondo è quello visto nella sezione sui criteri di collocazione, qui va solo ciò che è specifico del progetto e si discosta dal default delle istruzioni generali. Le sezioni sono indicative, possono essere fuse, divise o rinominate in base alla natura del progetto. Quello che conta è che ogni blocco esprima differenze, non default.

## Contesto del progetto

[Per chi è stato creato il progetto, ambito tematico, interlocutori
abituali, tipo di output atteso. Solo ciò che orienta Claude in modo
specifico per questo lavoro, non un riassunto del lavoro stesso.]

## Preferenze specifiche

[Lingua, registro, lunghezza, formato di risposta, scelte formali di
scrittura, solo se diverse da quelle delle istruzioni generali. Se una
preferenza coincide con il default non va ripetuta qui.]

## Metodo specifico per il progetto

[Eventuali deviazioni dal metodo di default delle istruzioni generali,
ad esempio l'allentamento del rigore di verifica per i progetti di
brainstorming, o un rinforzo specifico per i progetti di analisi.]

## Strumenti e risorse del progetto

[Skill, MCP, file e cartelle eventualmente presenti e pertinenti al
progetto, da elencare solo quando effettivamente caratterizzano il
lavoro. Per le risorse locali, dichiarare in apertura se il progetto
è destinato all'uso in Claude Desktop e su quale computer.]

Qualche osservazione su come è costruito lo scheletro. Le quattro sezioni rispecchiano la struttura del template per le istruzioni generali, viste nell’articolo precedente, con due differenze pensate apposta per il livello di progetto. La prima è l’assenza della sezione Profilo, che non si replica perché il profilo dell’utente è già nelle generali e qui sarebbe ridondanza. La seconda è la trasformazione della sezione Strumenti e skill in Strumenti e risorse del progetto, più specifica e con una dimensione di portabilità che al livello base non c’era.

La sezione Contesto del progetto è quella che caratterizza maggiormente il livello, e va riempita con misura. Va detto a Claude per chi sta lavorando, su cosa, e con che tipo di output, ma evitando il riassunto enciclopedico del progetto stesso. Le informazioni che servono sono quelle che orientano il comportamento, non quelle che descrivono in profondità il dominio, perché la documentazione di dominio è più efficace come materiale caricato nei file del progetto, dove Claude può consultarla quando le serve, piuttosto che condensata nelle istruzioni dove rischia di diluire la priorità delle regole.

La sezione Preferenze specifiche va scritta tenendo presente la regola d’oro, ciò che coincide con il default non va qui. Se nelle istruzioni generali si è scelto l’italiano e il progetto resta in italiano, non si scrive italiano nel progetto. Si scrive solo dove ci si discosta. La stessa logica vale per il registro, la lunghezza, le scelte formali. Una sezione asciutta, che dica solo le differenze, è più efficace di una sezione completa che ribadisce il default.

La sezione Metodo specifico per il progetto è la più pregiata e anche la più trascurata, perché è la più astratta. È il posto in cui si scrive non cosa Claude deve fare, ma come deve affrontare il lavoro. Per i progetti di analisi può rinforzare la verifica delle fonti, per i progetti di brainstorming può allentarla, per i progetti che richiedono particolare attenzione a certi tipi di errore può segnalarli esplicitamente. Andare oltre il default delle generali in questa sezione cambia il modo in cui Claude si pone, non solo cosa risponde.

La sezione Strumenti e risorse del progetto è il punto di intersezione più delicato con la portabilità. Va precisato che la sezione ha senso solo quando il progetto si appoggia effettivamente a strumenti o risorse specifici, in molti progetti può restare vuota. Le skill di account, gli MCP disponibili in tutti gli ambienti, le indicazioni di metodo sull’uso degli strumenti, sono regole portabili e stanno bene qui. Le risorse locali, i file su disco, le skill locali, gli MCP non disponibili nell’interfaccia web, vanno qui solo nei progetti destinati all’uso in Claude Desktop. In quel caso conviene aprire la sezione con una dichiarazione esplicita del tipo «questo progetto è pensato per essere usato in Claude Desktop, su un computer che ha installato i seguenti elementi». La dichiarazione è soprattutto per l’autore quando rilegge la propria configurazione mesi dopo, ed è il presidio operativo contro la confusione che si produce sui progetti con dipendenze locali non dichiarate.

Anti-pattern ricorrenti

Quattro errori si ripetono con sufficiente frequenza da meritare una trattazione distesa. Sono i comportamenti che, nei fatti, separano una configurazione di progetto efficace da una che produce risultati incoerenti senza che si capisca subito perché. Tre derivano dalle tentazioni proprie del livello di progetto, il quarto è la specializzazione, per questo livello, dell’errore di portabilità già visto nel precedente articolo.

Il primo errore è la duplicazione di regole già presenti nelle istruzioni generali. Si scrive nel progetto una regola che esiste già al livello base, di solito perché si vuole essere sicuri che venga applicata, oppure perché non ci si fida che le generali siano davvero attive in quel contesto. Il risultato è che la stessa regola compare in due posti, e il prompt di sistema effettivo della chat la contiene due volte. Questo non rinforza la regola, anzi la indebolisce, perché l’asimmetria fra una formulazione articolata nelle generali e una formulazione abbreviata nel progetto, o viceversa, introduce un margine interpretativo che Claude deve risolvere da solo. Anche quando le due formulazioni sono identiche al carattere, la duplicazione è un costo di manutenzione, perché qualsiasi aggiornamento futuro va replicato in entrambi i posti, e prima o poi si dimentica di farlo. La soluzione è semplice nell’enunciato e disciplinata nell’applicazione, le istruzioni generali esprimono il default, le istruzioni di progetto esprimono solo le differenze. Quando si è tentati di ripetere una regola per sicurezza, conviene resistere, e fidarsi del meccanismo di stratificazione.

Il secondo errore è speculare al primo, ed è l’accumulo nelle istruzioni di un progetto di regole che in realtà varrebbero per tutti i progetti. Si lavora a un progetto specifico, ci si accorge che una certa regola sarebbe utile, la si scrive lì. Mesi dopo si apre un altro progetto e la stessa regola, mai trasferita, non agisce più. Il progetto in cui la regola è stata scritta diventa una specie di prima approssimazione della propria configurazione generale, una bozza non ufficiale di ciò che dovrebbe stare nelle generali. Il problema non è solo l’invisibilità della regola negli altri progetti, è che la propria configurazione complessiva si frammenta in pezzi sparsi, ognuno scritto in un momento diverso e con formulazioni leggermente differenti. La soluzione è una pratica di promozione, ogni volta che si scrive una regola nelle istruzioni di un progetto vale la pena chiedersi se valga solo lì o ovunque. Se la risposta è ovunque, la regola va spostata nelle generali, e la versione del progetto va rimossa o ridotta alle eventuali specializzazioni residue. Una revisione periodica delle istruzioni di progetto serve esattamente a questo, a riconoscere le regole che hanno guadagnato pervasività nel tempo e a promuoverle al livello giusto.

Il terzo errore è la confusione fra istruzione di progetto e prompt di task. Si scrive nel campo istruzioni del progetto qualcosa che è in realtà un compito specifico, una richiesta puntuale, un brief per una singola conversazione. Il sintomo tipico è un’istruzione che inizia con un imperativo molto concreto del tipo «scrivi un articolo su…» o «analizza il documento allegato e produci un riassunto». Queste sono richieste, non regole, e il loro posto è il prompt della singola chat, non la configurazione persistente del progetto. Quando finiscono nelle istruzioni di progetto, accadono due cose. La prima è che la richiesta si applica come contesto a tutte le chat successive del progetto, anche a quelle che non avrebbero alcuna ragione di tenere conto di quel compito specifico. La seconda è che la richiesta tende a invecchiare, diventa obsoleta quando il compito è stato completato, e resta lì come rumore residuo che continua a influenzare il comportamento di Claude senza che l’utente se ne accorga. La soluzione è una distinzione di ruolo, le istruzioni di progetto contengono regole pervasive che valgono per tutto il lavoro nel progetto, le richieste e i compiti puntuali stanno nei prompt delle singole chat. Una buona istruzione di progetto è scritta in modo da essere ancora pertinente fra sei mesi, una richiesta puntuale è scritta per essere consumata e dimenticata.

Il quarto errore è la dipendenza implicita dall’ambiente. Si scrive nelle istruzioni di un progetto una regola che presuppone risorse locali, file in un percorso, una skill installata sul disco, un MCP disponibile solo in Desktop, senza dichiarare in apertura che il progetto è pensato per quell’ambiente. La regola funziona perfettamente fino a quando il progetto viene aperto altrove, sull’interfaccia web, su un altro computer, con una configurazione di MCP diversa, e a quel punto fallisce silenziosamente. Silenziosamente è la parte importante, Claude non può dire «questa istruzione non vale qui», semplicemente non riesce a eseguirla, e l’utente vede comportamenti incoerenti senza capirne la causa. La soluzione è il presidio della dichiarazione esplicita di destinazione, già introdotto nella sezione sulla portabilità e ripreso nel template. Quando un progetto ha dipendenze locali, la prima riga delle istruzioni dichiara dove il progetto è destinato a essere aperto e quali risorse devono essere disponibili, ad esempio «questo progetto è pensato per essere usato in Claude Desktop su un computer che ha la cartella D:\Progetti\Cliente\ e la skill X installata localmente». La dichiarazione non cambia il comportamento di Claude, ma cambia il comportamento dell’autore, che quando si trova ad aprire il progetto in un ambiente sbagliato ha sotto gli occhi la ragione per cui le cose non funzionano. È un anti-pattern di disciplina, non di tecnica, e richiede di scrivere una riga in più ogni volta che si configurano dipendenze locali. È poco, e ripaga in chiarezza nel tempo.

In tutti e quattro i casi vale un’osservazione di metodo. La revisione periodica delle istruzioni di progetto, 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 le istruzioni Cowork

Le istruzioni di progetto sono il livello in cui la configurazione di Claude diventa concretamente specializzata per il contesto di lavoro, e in cui i meccanismi di prevalenza visti nell’articolo precedente smettono di essere astratti e iniziano a produrre effetti tangibili nelle conversazioni quotidiane. Una configurazione di progetto scritta con disciplina, che dice solo le differenze rispetto al default e dichiara apertamente le proprie dipendenze dall’ambiente, è la base operativa di un lavoro più affidabile, in cui Claude si comporta in modo prevedibile dentro il perimetro del progetto e fuori di esso.

Il prossimo articolo della serie affronta le istruzioni Cowork, cioè il livello che vive solo all’interno dell’area Cowork di Claude Desktop e che governa l’ambiente di esecuzione locale, con tutto ciò che ne consegue in termini di file, percorsi, server MCP e attività ricorrenti. È il livello in cui le considerazioni sulla portabilità accennate qui diventano centrali, e in cui il rapporto fra istruzioni di progetto e istruzioni Cowork, già introdotto nella sezione sull’ereditarietà, riceve una trattazione completa.