Quasi tutti i CLAUDE.md sono pieni di istruzioni scritte per i modelli di prima: «ricontrolla tutto», IMPORTANTE in maiuscolo, procedure passo passo per cose che il modello sa già fare.
Opus 5.5 segue le istruzioni più da vicino e più alla lettera dei modelli per cui quelle righe erano state scritte, quindi gli avanzi adesso costano. Fa i controlli in più, applica troppo le regole urlate, pianifica troppo, e ogni token lo paghi tu.
Anthropic l’ha misurato. Su un test di assistenza clienti portato da Opus 4.8 a Opus 5.5, togliere quei vecchi schemi ha tagliato i costi di un altro 9%, e la precisione è salita di circa 2 punti sullo stesso modello. Anthropic ha anche messo un comando nella sua skill ufficiale per Claude Code che li trova nei tuoi file e propone la correzione. Questa guida spiega cosa cerca e come si usa.
Il post di Anthropic: Reducing cost and improving performance with Claude Platform
Perché le vecchie istruzioni peggiorano un modello nuovo
I modelli di prima si lasciavano guidare poco, quindi servivano prompt energici: si scriveva CRITICAL, MUST e ALWAYS, e si metteva in fila ogni passaggio. I modelli di adesso rispondono da vicino a quello che gli dici, quindi lo stesso testo esagera.
- Una regola in maiuscolo scatta anche dove non doveva.
- Una riga tipo «controlla il tuo lavoro due volte» compra un secondo giro di strumenti e ragionamento che non serviva.
- Una procedura passo passo fa seguire al modello il tuo piano invece del suo, che è migliore.
Nel test di Anthropic il costo è sceso proprio perché quelle chiamate in più e quel ragionamento doppio sono spariti.
Le tre abitudini che cerca
Ognuna ha un aspetto riconoscibile e una riscrittura semplice.
I rituali del «ricontrolla due volte»
«Double-check your work.» «Verifica due volte prima di rispondere.»
Al suo posto: cancellalo. Se un controllo conta davvero, nomina il controllo: «Fai girare i test prima di fare il commit».
Gli ordini in maiuscolo
«CRITICAL: YOU MUST ALWAYS…», «IMPORTANT: NEVER…», «Sii il più accurato possibile!!»
Al suo posto: dillo una volta, a voce normale, col motivo: «Usa questo strumento quando X, perché Y».
Le procedure passo passo
«Pensa passo passo.» «Passo 1: leggi. Passo 2: pianifica. Passo 3: …»
Al suo posto: descrivi l’obiettivo e il livello di qualità, non il metodo. Tieni i passi esatti solo dove una sola sequenza è sicura.
Segnala anche gli esempi vecchi scritti per i modelli di prima, le regole che si contraddicono, i nomi di modelli superati e le impostazioni datate nel codice che chiama l’API.
Chi l’ha fatto
Il comando si chiama e fa parte della skill ufficiale di Anthropic, nel repository anthropics/skills su GitHub. L’ha aggiunto CJ Avilla di Anthropic ad agosto 2026, e Lance Martin, l’autore del post qui sopra, ha aggiornato la skill con le indicazioni per Opus 5.5.
Uno sviluppatore che l’ha usato, Dan McAteer, ha raccontato che ha trovato una settantina di cose da sistemare fra le sue skill di Claude Code, il CLAUDE.md e l’AGENTS.md.
Installa la skill parte 1 · una volta sola
- In Claude Code, aggiungi il catalogo delle skill di Anthropic.
Il catalogoda scrivere in Claude Code
/plugin marketplace add anthropics/skills
- Installa la skill claude-api.
La skillda scrivere in Claude Code
/plugin install claude-api@anthropic-agent-skills
Lancia l’audit parte 2
Apri il tuo progetto e lancia il comando. Fa l’inventario di tutto quello che il modello legge come testo: CLAUDE.md, i file SKILL.md, i file di istruzioni degli agenti, i prompt di sistema, le descrizioni degli strumenti e il codice che costruisce le richieste.
L’auditda scrivere dentro il progetto
/claude-api prompt-audit
- Per controllare solo alcuni file, nominali nella richiesta, per esempio .
- In cima al rapporto controlla le due ipotesi che ha fatto: quali file ha guardato e per quale modello. Se una delle due è sbagliata, rilancialo nominando quella giusta.
Leggi il rapporto, prendi le modifiche parte 3
- Ogni problema trovato ha il file e la riga, il testo esatto, lo schema a cui corrisponde, perché è superato per il modello di destinazione, quanto è sicuro, e cosa propone: togliere, riscrivere, spostare, aggiungere o solo segnalare.
- Le modifiche proposte sono separate, una per problema. Non cambia niente finché non le applichi tu: prendi quelle su cui sei d’accordo, una alla volta dove conta.
- Prova prima e dopo su una copia: i tuoi test, se li hai, o un piccolo lavoro che mette alla prova la regola. Se un taglio peggiora le cose, rimetti la regola nella sua forma più semplice.
- Rilancialo a ogni modello nuovo. Una riga che aiuta una generazione diventa zavorra per quella dopo.
Cosa tiene
- Il contesto che sai solo tu: il tuo pubblico, il tuo prodotto, il tuo ambiente, il tuo livello di qualità, e i motivi dietro le tue regole.
- Le procedure esatte per le operazioni delicate, dove una sola sequenza è sicura: comandi distruttivi, accessi, passaggi di conformità.
- I dettagli del contratto di ogni strumento: cosa vuol dire ogni parametro, i limiti, i casi in cui fallisce.
- I divieti contro errori che il modello nuovo fa ancora.
- Una riga sul ruolo, e un solo riepilogo delle regole chiave alla fine.
La lunghezza non è il problema
Il danno viene da istruzioni precise e superate, non dalla lunghezza. Un file più corto non è per forza un file migliore.
Prima di fidarti
Ogni riga tolta è un’ipotesi finché non l’hai provata. Prima di cancellare una riga, cerca le sue parole esatte nel resto del progetto: test, classificatori e programmi che leggono i log a volte cercano proprio quel testo. E fanne un’abitudine: ogni volta che Anthropic fa uscire un modello nuovo, rilancia l’audit.