Le istruzioni di progetto¶

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 si trova in claude.ai, sia web che mobile, e in Claude Desktop, sia nell'area Chat che nell'area Cowork. 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. Il campo mostra solo un placeholder che scompare al primo inserimento e che varia leggermente da ambiente a ambiente, pur mantenendo lo stesso significato di fondo. Nei progetti Cowork compare ad esempio la formula «Aggiungi tono, formattazione o regole per guidare il funzionamento di Claude».

Questo capitolo si concentra 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 esplicite. Non tratta nemmeno la memoria di progetto, un meccanismo separato di accumulo automatico di informazioni a partire dalle conversazioni. Sono tutti elementi che definiscono l'esperienza dei progetti, ma operano su piani diversi con scopi diversi.

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 progetto vengono lette all'avvio di ogni nuova chat aperta dentro il progetto, e si compongono nel prompt di sistema della conversazione insieme alle istruzioni generali. Le chat avviate fuori dal progetto non leggono queste istruzioni, il loro prompt di sistema contiene solo il livello base.

Due aspetti tecnici cambiano il modo in cui conviene configurarle.

Gli ambienti in cui i progetti vivono. Claude.ai e l'area Chat di Claude Desktop condividono lo stesso spazio server, quindi un progetto creato in un ambiente compare anche nell'altro con le stesse istruzioni associate. I progetti Cowork sono invece un gruppo separato e locale e vivono solo dentro Claude Desktop. La separazione non è solo organizzativa, è strutturale, perché Cowork opera all'interno di un ambiente di esecuzione locale sul computer dell'utente. Il dettaglio è nel capitolo 5, qui basta tenere presente che un progetto Chat e un progetto Cowork sono cose diverse anche quando riguardano lo stesso lavoro.
Lo scarto fra spazio server condiviso e capacità effettive degli ambienti web e Desktop. Lo stesso progetto Chat può essere aperto sia da claude.ai sia da Claude Desktop, e in entrambi i casi le istruzioni associate sono testualmente identiche. Quello che cambia è ciò che Claude riesce a fare con quel testo, perché le capacità a disposizione differiscono fra i due ambienti. La sezione successiva entra nel dettaglio di questo punto.

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 differiscono 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ò funzionare in modi 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 viene effettivamente letta in entrambi gli ambienti.

Tre esempi chiariscono 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. Se invece è una skill locale, salvata nel filesystem di un singolo computer, funziona solo in Claude Desktop su quel pc. Sull'interfaccia web di claude.ai non funziona perché la skill non esiste in quell'ambiente. Lo stesso vale in Claude Desktop su un altro device in cui la skill non è installata. 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, con due avvertenze. 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. Inoltre l'accesso effettivo al filesystem dipende dai tool attivati e dalle loro configurazioni, che possono differire fra Chat e Cowork anche sullo stesso pc.
Il terzo è un controesempio utile. 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 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 mesi dopo.

C'è anche un caso ulteriore, particolare di 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, 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 blocchi, le istruzioni generali, le istruzioni del progetto Chat ereditato, le istruzioni del progetto Cowork. È una stratificazione interna e segue le stesse regole di prevalenza viste al capitolo 2. Per chi sa 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. Quelle stanno meglio nel campo istruzioni proprio di Cowork, lasciando il progetto Chat pulito sul proprio ambito. Il quadro completo è al capitolo 5.

Le regole di prevalenza alla prova del contesto¶

La regola «a parità di forza il livello più specifico prevale» è semplice nell'enunciato, e descrive abbastanza bene come si compongono i livelli di configurazione. Nella pratica vanno valutate con attenzione due dinamiche specifiche del livello di progetto che producono comportamenti che la sola regola gerarchica non basta a prevedere. La prima riguarda il rapporto fra come è formulata una regola di progetto e come è formulata la regola corrispondente nelle generali, nel caso la regola sia condivisa nei due livelli. La seconda riguarda il rapporto fra le istruzioni configurate e i segnali che arrivano dalla conversazione stessa.

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 coerente con quanto visto al capitolo 2 dice che prevale il livello più specifico, quindi l'inglese, perché la prevalenza è governata dalla specificità del livello e non dalla lunghezza del testo. La regola di progetto è scritta apposta per quel contesto, e questo basta.

Va detta però una sfumatura. L'asimmetria fra una motivazione articolata e un'istruzione minimale può introdurre un margine 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 è un'inversione della prevalenza, ma si può manifestare 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 all'autore una percezione di squilibrio quando rilegge la propria configurazione 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, 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. 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 sensibile al contesto 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 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. 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'utente agisce come se la regola fosse già operativa, senza chiedere a Claude di tenere ferma una direzione che chi scrive contraddice in pratica.

Quanto detto fin qui è stato anticipato nel capitolo 2 come dimensione della forza dell'istruzione e troverà esposizione completa al capitolo 9. Il livello di progetto è quello in cui la dimensione della forza si manifesta più spesso, perché è il primo livello in cui il conflitto fra istruzione configurata e contesto della conversazione diventa frequente.

Criteri di collocazione¶

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 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, 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. 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, è corretto 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. Vale la considerazione di portabilità della sezione La stessa istruzione, ambienti diversi. Le risorse locali funzionano solo nei progetti destinati a Claude Desktop, e in quel caso conviene segnalarlo nel testo.

Le istruzioni di progetto non vanno usati per compiti puntuali o richieste che vivono il tempo di una conversazione.

Una nota finale, la pulizia conta più della completezza, per cui 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 di collocazione¶

Il criterio si chiarisce con tre esempi tipici.

Il contesto di un cliente specifico. Si lavora per un'azienda con un proprio glossario di termini interni, persone identificate per ruolo, abitudini comunicative specifiche, ad esempio una preferenza per le sintesi numerate e una richiesta di evitare emoji. Nessuna di queste informazioni ha senso applicata ai lavori per altri clienti, e nessuna è una regola di metodo abbastanza generale da stare nelle generali. Il loro posto sono le istruzioni del progetto dedicato a quel cliente, dove formano il contesto operativo entro cui Claude legge le richieste e formula le risposte.
L'attivazione persistente di una skill o di un MCP. Si gestisce un progetto editoriale in cui ogni testo prodotto deve passare per una skill di assistenza editoriale che applica le convenzioni redazionali della testata. La regola «in questo progetto attiva sempre la skill di assistenza editoriale per la produzione di tutti i contenuti scritti» nelle istruzioni di progetto risparmia di richiamarla a ogni chat. È una regola che ha senso solo dentro l'ambito del progetto editoriale, perché negli altri progetti la stessa skill non serve o serve in modo diverso. Per la portabilità vale quanto visto nella sezione La stessa istruzione, ambienti diversi. Una skill di account funziona in tutti gli ambienti in cui il progetto può essere aperto, una skill locale solo dentro Claude Desktop e solo sul computer in cui è installata.
Variazione del default delle generali per un contesto specifico. Riprendendo l'esempio del capitolo 3 dal lato del progetto, si pensi a un progetto di brainstorming creativo in cui il rigore di verifica delle fonti che vale come default nelle generali ostacola la generazione di ipotesi. Una regola di progetto che allenta la verifica in favore della produzione di idee è la specializzazione operativa di una metodologia generale, scritta apposta per il contesto in cui quella variazione serve. La regola generale resta nelle generali, perché continua a valere nella maggior parte dei lavori, e il progetto si limita a dire la differenza.

Un template di configurazione commentato¶

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

Le quattro sezioni rispecchiano la struttura del template per le istruzioni generali, viste al capitolo 3, 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. La documentazione di dominio è più efficace come materiale caricato nei file del progetto, dove Claude può consultarla quando 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 specifica l'uso dell'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ù importante 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à. 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, file su disco, skill locali, 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».

Anti-pattern ricorrenti¶

Quattro errori si ripetono con sufficiente frequenza da meritare una nota più estesa. Sono i comportamenti che, nei fatti, separano una configurazione di progetto efficace da una che produce risultati incoerenti senza che si capisca subito perché.

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é più banalmente ci si è dimenticati d'averla già inserita nel livello base. 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. 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, la duplicazione è un costo di manutenzione. Qualsiasi aggiornamento futuro va replicato in entrambi i posti, e prima o poi si dimentica di farlo. Quando si è tentati di ripetere una regola per sicurezza, conviene resistere e fidarsi del meccanismo di stratificazione.
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. La soluzione è una pratica di promozione. Ogni volta che si scrive una regola nelle istruzioni di un progetto vale la pena chiedersi se vale 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, riconoscere le regole che hanno guadagnato pervasività nel tempo e promuoverle al livello giusto.
La confusione fra istruzione di progetto e richiesta puntuale. 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». Sono richieste, non regole, e il loro posto è il prompt della singola chat. Quando finiscono nelle istruzioni di progetto, si applicano come contesto a tutte le chat successive del progetto, anche a quelle che non avrebbero ragione di tenerne conto, e tendono a invecchiare diventando rumore residuo. 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.
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. 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 è la dichiarazione esplicita di destinazione, già introdotta nella sezione La stessa istruzione, ambienti diversi. 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. È 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.