Prompt di Claude Code: 25 prompt pronti all’uso e come scriverne di propri

I clienti che utilizzano un buono scaduto ricevono un errore 500 al momento del checkout. Esamina il file @src/checkout/coupons.ts e i relativi test. Il comportamento previsto è la visualizzazione di un messaggio di buono non valido senza la creazione di un ordine. Scrivi un test che fallisca e che riproduca l’errore, quindi correggilo senza modificare il comportamento relativo ai coupon validi. Esegui [comando di test del checkout] e mostra i risultati prima e dopo. Se non riesci a riprodurre l’errore, segnala cosa hai verificato prima di modificare l’implementazione.

Aggiungi un selettore di date a [percorso del modulo di prenotazione]. Segui le convenzioni relative ai componenti e alla convalida riportate in @src/components/TimeSelect.tsx. Gli utenti devono poter selezionare [date consentite], mentre [date non disponibili] devono rimanere disabilitate. Non aggiungere librerie. Esegui [comando di test del componente] e [comando di verifica dei tipi] e segnala eventuali criteri non coperti da tali controlli.

Suddividi il file @src/reports/export.py in funzioni più piccole, preservandone gli input, il formato di output e il comportamento in caso di errore. Esegui il [comando di test export] prima di apportare modifiche e segnala eventuali errori esistenti. Dopo la rifattorizzazione, riesegui i test e mostra entrambi i risultati. Non modificare l’interfaccia pubblica né i file non correlati.

“Claude verifica ogni singola modifica che integro su claude.ai/code utilizzando l’estensione Claude per Chrome. Apre un browser, testa l’interfaccia utente e ripete il processo finché il codice non funziona e l’esperienza utente risulta soddisfacente. ”

Esamina il file README, la configurazione del progetto e la struttura delle directory di primo livello di questo repository. Segui i riferimenti solo se necessario per spiegare: cosa fa l’applicazione; i suoi punti di ingresso principali e i componenti principali; dove si trovano i test e quali comandi il repository definisce per eseguirli. Cita i percorsi dei file a supporto della tua spiegazione. Distingui il comportamento documentato dalle tue deduzioni personali e segnala tutto ciò che non riesci a determinare. Non leggere i file contenenti informazioni riservate o di ambiente, non esaminare le dipendenze installate e non modificare alcun file. Concludi indicando i tre file che dovrei leggere per primi e il motivo.

Esamina la cronologia Git di [file, funzione o classe], concentrandoti su [comportamento o questione di progettazione]. Identifica i commit che hanno introdotto o modificato in modo sostanziale tale comportamento. Per ogni commit rilevante, fornisci il relativo hash, riepiloga la modifica e spiega le motivazioni documentate nel messaggio di commit o nella discussione collegata a cui puoi accedere. Etichetta le ragioni dedotte come “inferenze”. Se la cronologia non spiega una decisione, segnalalo. Non modificare i file né la cronologia Git.

Traccia cosa succede quando si verifica [un'azione dell'utente o un evento di sistema], partendo da [un percorso, un gestore o una cartella noti]. Segui le chiamate rilevanti attraverso la convalida, la logica di business e qualsiasi scrittura sul database o richiesta esterna. Elenca i file e le funzioni nell'ordine di esecuzione, con i riferimenti alle righe, se disponibili. Spiega i principali percorsi di errore e identifica i test esistenti che coprono il flusso. Segnala qualsiasi connessione che non riesci a confermare dal codice. Non eseguire il flusso, non chiamare servizi esterni e non effettuare modifiche ai file.

Pianifica come implementare [funzionalità/funzione] nell’[area del repository]. Il comportamento previsto è [requisiti] e queste aree devono rimanere invariate: [vincoli]. Esamina il codice pertinente e i test esistenti. Identifica i file che devono essere modificati, l’ordine di implementazione ed eventuali rischi di compatibilità o di migrazione dei dati. Mappa ogni requisito a un test proposto o ad altra fase di verifica. Elenca separatamente le questioni irrisolte e le ipotesi. Non implementare ancora la funzione. Inviami il piano affinché io possa esaminarlo.

Voglio realizzare [breve descrizione] per [utenti e caso d'uso]. Leggi prima [i file o i requisiti pertinenti], poi usa AskUserQuestion per chiarire le decisioni che potrebbero influire in modo sostanziale sull'implementazione. Concentrati sui casi limite, sulla gestione dei dati, sulle autorizzazioni, sul comportamento previsto dell'interfaccia utente e sui compromessi. Non porre domande a cui il contesto fornito risponde già. Una volta risolte le decisioni chiave, redigi una bozza di specifica che copra i requisiti, i criteri di accettazione, i vincoli e ciò che è fuori dall’ambito. Evidenzia eventuali ipotesi residue. Mostrami la specifica prima di salvarla in [percorso della specifica] e non sovrascrivere un file esistente senza approvazione.

Valuta l’impatto della modifica di [funzione, componente o interfaccia] dal [comportamento attuale] al [comportamento proposto]. Cerca nel [repository o nell’ambito della directory] la sua definizione, i chiamanti diretti, le importazioni e i test correlati. Elenca i file che potrebbero richiedere modifiche e spiega in che modo ciascuno di essi potrebbe essere interessato, indicando i riferimenti al file e alla riga, ove disponibili. Segnalare le chiamate risolte dinamicamente, i consumatori esterni o altre dipendenze che non è possibile verificare. Identificare eventuali questioni di compatibilità che richiedono una risposta prima dell’implementazione. Non modificare i file; restituire la valutazione dell’impatto e attendere la mia revisione.

Aggiungi [funzionalità/funzione] a [file o pagina] con questo comportamento: [criteri di accettazione]. Esamina [l’implementazione esistente] e segui le sue convenzioni per il recupero dei dati, la gestione degli errori e l’organizzazione dei componenti. Utilizza solo le librerie già installate nel progetto. Mantieni le modifiche entro [ambito] e preserva [il comportamento esistente o l’interfaccia pubblica]. Aggiungi o aggiorna i test per i criteri di accettazione. Esegui [comando di test] e [comando di controllo dei tipi o lint], quindi segnala i file modificati, i risultati e eventuali controlli che non è stato possibile completare. Se il modello esistente è in conflitto con un requisito, spiega il conflitto prima di procedere.

Implementa [nome della funzione] nel [file] per soddisfare [requisiti]. Copri il [caso normale], il [caso limite] e il [comportamento in caso di input non valido]. Esegui prima il [comando di test pertinente] e segnala eventuali errori esistenti. Scrivi i test per il comportamento richiesto, quindi eseguili prima dell’implementazione. Verifica che i nuovi test falliscano per il motivo previsto. Implementa la funzione ed esegui nuovamente i test. Non indebolire le asserzioni, non saltare i test né modificare il comportamento previsto per farli superare. Se i requisiti sono in conflitto con i test esistenti, fermati e spiega il conflitto. Mostra i risultati prima e dopo.

Implementa il design allegato in [componente o pagina], utilizzando i componenti e gli stili esistenti del progetto. Mantieni [il comportamento richiesto] ed evita modifiche al di fuori dell’[ambito]. Utilizza [il browser configurato o lo strumento di screenshot] per acquisire [il percorso locale] alle [dimensioni del viewport] con [i dati di test e lo stato dell’interfaccia utente]. Se lo strumento o l’applicazione non sono disponibili, segnala ciò che è necessario anziché dichiarare di aver effettuato un controllo visivo. Confronta la cattura con il riferimento, concentrandoti su [layout, spaziatura, tipografia o altri criteri di accettazione]. Effettua fino a [numero] cicli di correzione, quindi segnala le differenze rimanenti. Non alterare l’immagine di riferimento. Esegui [i test dei componenti pertinenti] e [il comando di verifica dei tipi o di compilazione]. Includi lo screenshot acquisito e i risultati effettivi della verifica nel tuo riepilogo/riassunto.

Gli utenti riscontrano [sintomo] quando [trigger o input]. Il comportamento atteso è [risultato atteso]. Inizia esaminando [cartella, funzione o flusso] e i test correlati. Crea un test che fallisca e che riproduca il comportamento segnalato. Se non riesci a riprodurlo, spiega cosa hai verificato e quali informazioni mancano prima di modificare l’implementazione. Una volta riprodotto, risolvi la causa senza modificare [comportamento che deve rimanere inalterato]. Esegui il nuovo test e [comando di test correlato]. Mostra l’errore prima della correzione, i risultati successivi e eventuali errori rimanenti.

Il [comando di compilazione] fallisce in [ambiente locale o CI] con questo output: [log degli errori anonimizzato]. Esamina il codice e la configurazione pertinenti per identificare la causa. Verifica eventuali differenze nell’ambiente o nelle dipendenze se l’errore non si riproduce localmente. Apporta la modifica minima necessaria a risolvere la causa. Non disabilitare i controlli, non sopprimere gli errori, non saltare i test e non allentare le impostazioni del compilatore solo per ottenere una build che superi i test. Riesegui la build dopo la modifica. Se continua a fallire dopo [numero] tentativi di correzione, interrompi e segnala ciò che hai provato, l’errore attuale e il prossimo passaggio diagnostico. Riassumi la causa e includi il risultato effettivo della build.

Aiutami a circoscrivere un bug prima di proporre una correzione. Comportamento osservato: [cosa succede] Comportamento previsto: [cosa dovrebbe succedere] Quando si verifica: [condizioni o frequenza] Cosa ho provato: [passaggi e risultati] Poni una domanda alla volta, scegliendo quella che meglio permette di distinguere tra le possibili cause. Non ripetere domande a cui le informazioni fornite danno già una risposta. Una volta raccolte prove sufficienti, riepiloga/riassumi la spiegazione più plausibile, ciò che rimane incerto e il test più semplice in grado di confermarla o escluderla. Non effettuare ancora modifiche ai file.

Utilizza un subagente per revisionare [la differenza o il ramo rispetto alla base] rispetto al [piano approvato o al file dei requisiti]. Se i requisiti mancano o sono ambigui, segnalalo prima di valutare la completezza. Verifica che ogni requisito sia implementato, che i casi limite rilevanti siano sottoposti a test e che eventuali modifiche non esulino dall’ambito concordato. Esamina il codice circostante, se necessario, per comprendere le differenze. Segnala i problemi di correttezza e i requisiti non soddisfatti indicando i riferimenti al file e alla riga, il loro impatto e le prove a sostegno di ciascun riscontro. Distingui i problemi confermati dalle questioni irrisolte. Non inventare riscontri per raggiungere una quota né includere preferenze stilistiche non pertinenti. Non effettuare modifiche ai file.

Esamina [i file o i diff] alla ricerca di rischi di iniezione, controlli di autorizzazione mancanti, informazioni riservate esposte e gestione non sicura degli input degli utenti. Verifica i chiamanti rilevanti e la logica di convalida prima di segnalare un risultato. Per ogni problema, identifica il file e le righe interessate, le condizioni necessarie per triggerarlo, il probabile impatto e una soluzione suggerita. Distingui un percorso vulnerabile confermato da un problema che richiede ulteriori test. Non riprodurre i valori segreti nel rapporto, non modificare i file e non eseguire test sui servizi attivi. Indica quali aree sono state esaminate e cosa rimane fuori dall’ambito di analisi.

Riassumi come hai verificato la modifica completata rispetto ai [criteri di accettazione]. Per ciascun criterio, elenca il controllo effettuato, il comando esatto (ove applicabile) e il risultato osservato. Includi l’output pertinente, con le informazioni riservate e i dati sensibili oscurati. Identifica separatamente eventuali errori preesistenti. Distingui chiaramente i controlli superati, quelli falliti e quelli non eseguiti. Spiega eventuali controlli saltati o limiti nella copertura. Non descrivere l’intera modifica come verificata se alcuni criteri rimangono non controllati.

Rifattorizza [file o modulo] per [un obiettivo specifico, come la suddivisione di una funzione di grandi dimensioni o la rimozione di callback annidati]. Mantieni l’interfaccia pubblica, i valori di ritorno, il comportamento in caso di errore e gli effetti collaterali. Esegui [il comando di test pertinente] prima della modifica per stabilire una linea di riferimento. Se fallisce, segnala gli errori prima di procedere. Identifica eventuali comportamenti non coperti dai test esistenti e aggiungi test mirati dove necessario. Esegui la rifattorizzazione senza apportare modifiche non correlate o creare nuove dipendenze. Non indebolire le asserzioni esistenti per adattarle all’implementazione. Rieseguire i test e [comando di controllo dei tipi o lint]. Mostrare i risultati prima e dopo, riepilogare le modifiche strutturali e segnalare qualsiasi comportamento che non è stato possibile verificare.

Individua gli utilizzi di [vecchia API o libreria] all’interno dell’[ambito della directory], escludendo i file generati e quelli forniti da terze parti. Elenca i file interessati e qualsiasi configurazione condivisa o dipendenza che la migrazione potrebbe coinvolgere. Proponi tre file rappresentativi per una migrazione pilota alla [nuova API o versione], utilizzando la [guida alla migrazione o un esempio esistente]. Spiega perché li hai selezionati e segnala eventuali modifiche di comportamento necessarie. Attendi la mia approvazione prima di apportare modifiche. Dopo l’approvazione, migra solo i file pilota e le dipendenze condivise esplicitamente approvate. Esegui [i test pertinenti] e [il comando di build o di controllo dei tipi]. Non estendere la migrazione ad altri file. Segnala le differenze, i risultati dei test, i problemi di compatibilità e le eventuali modifiche necessarie all’approccio di migrazione. Interrompi il processo per la revisione prima di proseguire con i file rimanenti.

Esamina il ramo corrente, lo stato di Git e il diff per [funzionalità/funzione o correzione]. Identifica i file relativi a questa modifica ed elenca separatamente quelli non correlati o non tracciati. Redigi una bozza del messaggio di commit seguendo il formato degli ultimi 10 commit. Prepara una descrizione della richiesta pull che indichi cosa è cambiato, perché, i test effettivamente eseguiti ed eventuali limitazioni residue. Mostra l’elenco dei file proposto, il messaggio di commit e la descrizione della PR prima di mettere in staging o pubblicare qualsiasi cosa. Attendi la mia approvazione. Dopo l’approvazione, metti in staging solo i file concordati, esegui il commit sul [ramo della funzionalità], esegui il push su [remoto] e apri una richiesta pull sul [ramo di base]. Non modificare i commit esistenti, non eseguire force-push né unire. Invia l’hash del commit e il link alla PR.

Redigi una sezione README per [modulo] rivolta a [lettore, ad esempio un ingegnere backend che entra a far parte del progetto]. Tratta i prerequisiti, la configurazione, i tre comandi che userà più spesso e gli errori comuni gestiti dal codice o dalla documentazione esistente. Verifica i nomi dei comandi e le opzioni confrontandoli con [script del pacchetto, Makefile, guida della CLI o configurazione CI]. Segnala tutto ciò che non riesci a confermare. Prova i comandi locali sicuri in [ambiente di test], se disponibile. Prima di eseguire comandi che installano dipendenze, eliminano file, migrano dati, effettuano il deploy o accedono a servizi esterni, spiega i loro effetti e chiedi l’approvazione. Distingui chiaramente i comandi che hai eseguito con esito positivo da quelli verificati solo rispetto alla configurazione o alla documentazione. Mostra la sezione README proposta prima di effettuare la modifica [del percorso della documentazione] e conserva i contenuti non pertinenti.

Esamina [percorso verso CLAUDE.md] alla luce della struttura attuale del repository, degli script e delle convenzioni. Non effettuare ancora modifiche al file. Individua le istruzioni obsolete, i duplicati, le contraddizioni e le regole che potrebbero essere dedotte in modo affidabile dal codice. Spiega ogni rimozione proposta, anziché eliminare le istruzioni solo per accorciare il file. Suggerisci comandi di compilazione o di test mancanti solo quando puoi verificarli negli script del progetto, in un Makefile, nella configurazione CI o nella documentazione esistente. Citare la fonte per ogni aggiunta. Restituire un diff proposto che preservi i vincoli importanti del progetto. Contrassegnare le istruzioni specifiche per un’attività che si adatterebbero meglio a una skill o a una regola a livello di percorso e attendere l’approvazione prima di applicare le modifiche.

Proponi un hook di comando Claude Code che esegua [comando del formattatore esistente] dopo che sono state apportate modifiche con "Modifica" o "Scrivi" a [modelli di file]. Esamina prima la configurazione esistente in claude/settings.json e la configurazione del formattatore. Utilizza la configurazione PostToolUse appropriata per la versione installata di Claude Code. Formatta solo il file interessato, gestisci i percorsi in modo sicuro ed escludi [file generati o altri percorsi esclusi]. Non installare dipendenze né sostituire hook esistenti. Mostra il confronto (diff) delle impostazioni proposte e spiega come verranno segnalati gli errori del formattatore. Attendi l’approvazione prima di applicarlo. Dopo l’approvazione, testalo con un file temporaneo nel progetto e riporta il risultato. Indica quali percorsi di modifica copre e quali no, incluse le modifiche apportate tramite comandi della shell.

Controlla [strumento] –help e la guida relativa ai sottocomandi pertinenti all’[attività]. Non installare lo strumento se manca; segnala invece tale prerequisito. Proponi i comandi esatti necessari per completare l’attività. Spiega i loro input, output e se scrivono file, modificano risorse remote o utilizzano credenziali. Includi un’opzione di simulazione (dry-run) se lo strumento ne prevede una. Segnala eventuali configurazioni o autorizzazioni mancanti e chiedi chiarimenti piuttosto che indovinare nomi di risorse o destinazioni. Attendi l’approvazione prima di eseguire i comandi dell’attività. Dopo l’approvazione, esegui solo i comandi concordati e segnala i loro risultati effettivi, inclusi eventuali errori o passaggi incompleti.

Confronta [invoices.csv] e [pagamenti.csv] utilizzando [ID fattura o chiave di corrispondenza]. Non modificare i file di origine. Applica queste regole: [valuta e tolleranza di arrotondamento], [ripartizione dei pagamenti parziali] e [gestione di rimborsi, crediti e pagamenti in eccesso]. Se manca una regola o una corrispondenza è ambigua, segnalala anziché assegnare automaticamente il pagamento. Mantieni gli ID delle righe di origine. Per ogni fattura, mostra l’importo fatturato, i pagamenti applicati e il saldo residuo. Segnalare gli ID duplicati, le fatture non abbinate, i pagamenti non abbinati e i saldi al di fuori della tolleranza. Riconciliare separatamente i totali delle fatture e dei pagamenti. Contabilizzare ogni riga di origine senza conteggi doppi; se un pagamento è suddiviso tra più fatture, mostrare ogni allocazione e confermare che le allocazioni non superino l’importo del pagamento. Scrivere i risultati in [nuovi percorsi di output] e riepilogare/riassumere le eccezioni che richiedono una revisione.

Scrivi uno script che riepiloghi [export.csv] per il periodo compreso tra [data di inizio e ora, incluse] e [data di fine, escluse], utilizzando [fuso orario] e [colonna data]. Raggruppa i record in base alle [regole di categoria] e calcola le [metriche richieste]. Gestisci gli ID duplicati e i valori mancanti secondo le [regole]. Non modificare il file di input. Esegui lo script sul [file di input esatto]. Riporta il numero di righe incluse ed escluse, i totali per categoria e i record che non è stato possibile classificare. Confronta i risultati per [tre categorie] con i conteggi verificati in modo indipendente nel [file di riferimento]. Se tali conteggi non sono disponibili, indica che la convalida indipendente è ancora in sospeso. Mostra le discrepanze e salva il report nel [nuovo percorso di output].

Leggi [file o cartella specificati] e redigi una bozza di [tipo e lunghezza del documento] destinata a [destinatari], trattando [domande o argomenti]. Corrobora ogni affermazione fattuale con il nome di un file e, se disponibile, un riferimento a una pagina, una sezione o una riga. Distingui le citazioni dirette dalle parafrasi e non considerare una proposta o un documento obsoleto come una decisione attuale confermata. Segnala le fonti contraddittorie, le informazioni mancanti e le affermazioni che non puoi verificare. Non colmare le lacune con supposizioni né effettuare modifiche ai file di origine. Restituisci la bozza con i relativi riferimenti e un breve elenco di questioni irrisolte per il revisore.

Per adattare un modello, sostituisci i suoi segnaposto con i dettagli del tuo progetto e decidi cosa deve fare Claude prima di apportare le modifiche. Segui questi passaggi per preparare la richiesta e verificare il risultato.

Per una modifica piccola e ben definita, puoi chiedere a Claude di implementarla direttamente. Per codice che non conosci, modifiche che interessano più file o requisiti non risolti, inizia con un piano.

Premi Shift+Tab fino a quando non compare la modalità Plan, oppure avvia Claude Code con il comando claude --permission-mode plan. In questa modalità, Claude può ispezionare i file ed eseguire comandi in sola lettura senza effettuare modifiche al tuo codice sorgente. Esamina i file, le dipendenze e i test proposti prima di approvare l'implementazione. Premi Ctrl+G per aprire il piano proposto nel tuo editor.

Fornisci a Claude le informazioni necessarie per comprendere l’attività: un riferimento a un file, un log degli errori depurato, uno screenshot o un documento dei requisiti. Usa il simbolo @ seguito dal percorso del file per includerne il contenuto.

Scegli l’insieme più piccolo possibile di fonti utili. Includere un intero log o una directory può aggiungere materiale irrilevante e consumare contesto. Rimuovi le credenziali e i dati sensibili prima della condivisione dei log e verifica che Claude disponga degli strumenti necessari per recuperare eventuali URL di documentazione che fornisci.

Ad esempio, il comando `cat error.log | claude -p "Spiega questo errore"` invia un log tramite una richiesta non interattiva. Utilizzalo solo dopo aver verificato il contenuto del file. Questo è il valore pratico dell’IA contestuale: fornire al modello informazioni rilevanti per l’attività da svolgere.

Quando aggiungi una funzionalità/funzione, individua un componente o una funzione simile nel repository. Indica a Claude quali convenzioni seguire, come il client API, la logica di validazione, la gestione degli errori o la struttura dei test.

“Segui come @src/widgets/Weather.tsx recupera e memorizza i dati nella cache” fornisce a Claude un riferimento concreto. Indica inoltre eventuali differenze richieste dalla nuova funzionalità/funzione, in modo che non venga copiato un comportamento ormai obsoleto. Queste convenzioni dovrebbero riflettere il flusso di lavoro di sviluppo software del tuo team.

Per le modifiche al codice, specifica il comando di test, build o lint pertinente e il comportamento che dovrebbe verificare. Per la ricerca, richiedi i riferimenti ai file o gli ID dei commit. Per il lavoro sull'interfaccia utente, fornisci un'immagine di riferimento e una modalità configurata per catturare l'implementazione nello stesso viewport.

Chiedi a Claude di fornire la reportistica relativa a ciò che ha effettivamente verificato, inclusi gli errori e i controlli saltati. Verifica se le prove soddisfano i requisiti; una build superata non garantisce che ogni comportamento richiesto funzioni correttamente.

Per attività più lunghe, Claude Code offre anche una condizione /goal e gli hook Stop. Il valutatore degli obiettivi analizza le prove emerse nella conversazione anziché ispezionare autonomamente i file o eseguire test. Un hook Stop configurato può bloccare il completamento, ma presenta dei limiti per quanto riguarda i blocchi ripetuti. Nessuno dei due sostituisce i test appropriati e la revisione umana.

Se le ripetute correzioni non risolvono un problema, fermati e individua cosa non era chiaro nella richiesta originale. Salva le informazioni utili, lo stato attuale di Git e il lavoro rimanente prima di cancellare la conversazione.

La guida alle best practice di Anthropic consiglia di ricominciare da capo dopo due correzioni infruttuose sullo stesso problema. Utilizza il comando /clear, quindi fornisci un prompt rivisto che includa ciò che hai imparato. L'azzeramento della conversazione non annulla le modifiche apportate ai file.

Premi Esc per interrompere una risposta in esecuzione. Con il prompt vuoto, premi Esc due volte per aprire il menu di riavvolgimento e scegliere cosa ripristinare. Il riavvolgimento non annulla tutti gli effetti esterni, quindi utilizza i checkpoint di Git e procedure di ripristino separate per le modifiche ai database o ai servizi remoti.

Salva le linee guida relative all’intero progetto nel file CLAUDE.md, le procedure ripetibili nelle skill e le istruzioni per file specifici nelle regole con ambito di percorso. Utilizza gli hook per azioni legate a eventi specifici, come l’esecuzione di un formattatore dopo una modifica.

Scegli in base al momento in cui l'istruzione deve essere applicata:

I requisiti relativi a una singola funzionalità vanno solitamente inseriti nel prompt dell’attività o nelle specifiche relative a essa, piuttosto che nel file CLAUDE.md. L’aggiunta di istruzioni temporanee a un file a livello di progetto rende più difficile distinguerle dalle convenzioni che dovrebbero essere applicate in tutto il repository.

Ad esempio, inserisci il comando di test del progetto nel file CLAUDE.md, inserisci le convenzioni specifiche per i componenti in una regola con ambito di percorso e salva una procedura di revisione ricorrente come skill. Rivedi questi file quando i comandi o le convenzioni cambiano, proprio come faresti con qualsiasi altra documentazione del progetto.

I prompt, il file CLAUDE.md e le competenze guidano il comportamento di Claude; tuttavia, non garantiscono che un’istruzione venga seguita. Gli hook possono eseguire controlli in occasione di eventi configurati, ma la loro affidabilità dipende dal tipo di hook e dall’implementazione.

Un hook di comando esegue uno script. Un prompt o un hook di agente si basa sul giudizio di un modello. Come spiega la guida alle best practice di Anthropic: «Un prompt o un hook di agente chiede a un altro modello di decidere, quindi non è deterministico». Per una regola che deve essere applicata, utilizza controlli di autorizzazione appropriati e testa il comando o l’hook HTTP pertinente, verificandone anche la gestione degli errori.

I sottoagenti personalizzati rappresentano un altro modo per organizzare le attività ricorrenti. Definisci uno specialista in `claude/agents/` quando è necessario un ruolo di revisione specifico o un ambito di applicazione distinto per lo strumento, anziché aggiungere ogni istruzione relativa allo specialista alla sessione principale. Queste guide sul modello Claude più adatto al lavoro e sui tipi di agenti IA forniscono ulteriori informazioni di contesto.

Se il tuo team gestisce prompt su diversi prodotti di intelligenza artificiale, dai un'occhiata a questi strumenti di ingegneria dei prompt per gestire le librerie oltre a Claude Code.

Quando una sessione produce un risultato incompleto o inadeguato, verifica se la richiesta ha lasciato irrisolte decisioni importanti. Questi cinque errori possono rendere più difficile la diagnosi e la revisione del lavoro.

L'istruzione “Esamina il repository” fornisce a Claude poche indicazioni su quali file siano rilevanti o su quando interrompere l'analisi. Potresti ricevere un riepilogo/riassunto generico senza una risposta al problema che ha dato origine alla richiesta.

Indica il comportamento o la decisione che devi comprendere, individua una posizione di partenza e definisci l’output atteso. Ad esempio: “Traccia il modo in cui questo endpoint verifica le autorizzazioni e cita le funzioni pertinenti”. Se utilizzi subagenti, assegna a ciascuno di essi una domanda circoscritta, anziché delegare la stessa ricerca senza restrizioni.

Passare da una funzionalità/funzione a un bug non correlato e poi a una richiesta di documentazione fa sì che la conversazione continui a riportare un contesto che potrebbe non essere pertinente all’attività corrente. Riferimenti come «quel file» o «l’approccio precedente» diventano ambigui.

Utilizza sessioni separate per attività non correlate. Se più sessioni devono apportare modifiche al repository, utilizza alberi di lavoro Git separati in modo che non modifichino la stessa directory di lavoro. Una breve curiosità: il comando /btw di Claude Code mantiene lo scambio fuori dalla cronologia principale della conversazione.

Una build può superare i test anche se una funzionalità/funzione si comporta in modo errato. Una suite di test può superare i test semplicemente perché non ha mai verificato l’input che causa l’errore. Chiedere a Claude di «eseguire i test» non chiarisce quali requisiti tali test verifichino.

Mappa i criteri di accettazione a controlli specifici. Per la correzione di un bug, richiedi la prova che il test di riproduzione abbia dato esito negativo prima della modifica e positivo dopo. Mantieni visibili i criteri non testati, anziché considerare un singolo comando riuscito come verifica dell’intera modifica.

Un file CLAUDE.md in continua espansione può contenere comandi obsoleti, regole duplicate e istruzioni che contraddicono i requisiti specifici dell’attività. L’aggiunta di formulazioni più rigorose non risolve tali conflitti.

Confronta il file con il repository attuale. Rimuovi le indicazioni obsolete, chiarisci le regole in conflitto e sposta le istruzioni di applicazione limitata in regole o competenze con ambito di percorso. Se un requisito deve essere applicato, configura e testa i controlli appropriati invece di affidarti a ripetuti promemoria.

Una revisione può evidenziare contemporaneamente difetti effettivi, aspetti incerti e suggerimenti facoltativi di refactoring. L’applicazione di ogni suggerimento può ampliare la portata delle modifiche senza migliorare il comportamento richiesto.

Chiedi le prove e l’impatto alla base di ogni risultato. Assegna priorità ai problemi di correttezza e ai requisiti non soddisfatti, approfondisci le affermazioni incerte ed escludi dal diff corrente i miglioramenti non pertinenti. Un revisore dovrebbe essere in grado di segnalare l’assenza di risultati rilevanti quando le prove supportano tale conclusione.

Per adattare un modello, sostituisci i suoi segnaposto con i dettagli del tuo progetto e decidi cosa deve fare Claude prima di apportare le modifiche. Segui questi passaggi per preparare la richiesta e verificare il risultato.

Per una modifica piccola e ben definita, puoi chiedere a Claude di implementarla direttamente. Per codice che non conosci, modifiche che interessano più file o requisiti non risolti, inizia con un piano.

Premi Shift+Tab fino a quando non compare la modalità Plan, oppure avvia Claude Code con il comando claude --permission-mode plan. In questa modalità, Claude può ispezionare i file ed eseguire comandi in sola lettura senza effettuare modifiche al tuo codice sorgente. Esamina i file, le dipendenze e i test proposti prima di approvare l'implementazione. Premi Ctrl+G per aprire il piano proposto nel tuo editor.

Fornisci a Claude le informazioni necessarie per comprendere l’attività: un riferimento a un file, un log degli errori depurato, uno screenshot o un documento dei requisiti. Usa @ seguito dal percorso del file per includerne il contenuto.

Scegli l’insieme più piccolo possibile di fonti utili. Includere un intero log o una directory può aggiungere materiale irrilevante e consumare contesto. Rimuovi le credenziali e i dati sensibili prima della condivisione dei log e verifica che Claude disponga degli strumenti necessari per recuperare eventuali URL di documentazione che fornisci.

Ad esempio, il comando `cat error.log | claude -p "Spiega questo errore"` invia un log tramite una richiesta non interattiva. Utilizzalo solo dopo aver verificato il contenuto del file. Questo è il valore pratico dell’IA contestuale: fornire al modello informazioni rilevanti per l’attività da svolgere.

Quando aggiungi una funzionalità/funzione, individua un componente o una funzione simile nel repository. Indica a Claude quali convenzioni seguire, come il client API, la logica di validazione, la gestione degli errori o la struttura dei test.

“Segui come @src/widgets/Weather.tsx recupera e memorizza i dati nella cache” fornisce a Claude un riferimento concreto. Indica inoltre eventuali differenze richieste dalla nuova funzionalità/funzione, in modo che non venga copiato un comportamento ormai obsoleto. Queste convenzioni dovrebbero riflettere il flusso di lavoro di sviluppo software del tuo team.

Per le modifiche al codice, specifica il comando di test, build o lint pertinente e il comportamento che dovrebbe verificare. Per la ricerca, richiedi i riferimenti ai file o gli ID dei commit. Per il lavoro sull'interfaccia utente, fornisci un'immagine di riferimento e una modalità configurata per catturare l'implementazione nello stesso viewport.

Chiedi a Claude di riportare ciò che ha effettivamente verificato, inclusi gli errori e i controlli saltati. Verifica se le prove soddisfano i requisiti; una build superata non garantisce che ogni comportamento richiesto funzioni correttamente.

Per attività più lunghe, Claude Code offre anche una condizione /goal e gli hook Stop. Il valutatore degli obiettivi analizza le prove emerse nella conversazione anziché ispezionare autonomamente i file o eseguire test. Un hook Stop configurato può bloccare il completamento, ma presenta dei limiti per quanto riguarda i blocchi ripetuti. Nessuno dei due sostituisce i test appropriati e la revisione umana.

Se le ripetute correzioni non risolvono un problema, fermati e individua cosa non era chiaro nella richiesta originale. Salva le informazioni utili, lo stato attuale di Git e il lavoro rimanente prima di cancellare la conversazione.

La guida alle best practice di Anthropic consiglia di ricominciare da capo dopo due correzioni infruttuose sullo stesso problema. Utilizza il comando /clear, quindi fornisci un prompt rivisto che includa ciò che hai imparato. L'azzeramento della conversazione non annulla le modifiche apportate ai file.

Premi Esc per interrompere una risposta in esecuzione. Con il prompt vuoto, premi Esc due volte per aprire il menu di riavvolgimento e scegliere cosa ripristinare. Il riavvolgimento non annulla tutti gli effetti esterni, quindi utilizza i checkpoint di Git e procedure di ripristino separate per le modifiche ai database o ai servizi remoti.

Salva le linee guida relative all’intero progetto nel file CLAUDE.md, le procedure ripetibili nelle skill e le istruzioni per file specifici nelle regole con ambito di percorso. Utilizza gli hook per azioni legate a eventi specifici, come l’esecuzione di un formattatore dopo una modifica.

Scegli in base al momento in cui l’istruzione deve essere applicata:

I requisiti relativi a una singola funzionalità/funzione vanno solitamente inseriti nel prompt dell’attività o nelle specifiche relative a essa, piuttosto che nel file CLAUDE.md. L’aggiunta di istruzioni temporanee a un file a livello di progetto rende più difficile distinguerle dalle convenzioni che dovrebbero essere applicate in tutto il repository.

Ad esempio, inserisci il comando di test del progetto nel file CLAUDE.md, inserisci le convenzioni specifiche per i componenti in una regola con ambito di percorso e salva una procedura di revisione ricorrente come skill. Rivedi questi file quando i comandi o le convenzioni cambiano, proprio come faresti con qualsiasi altra documentazione di progetto.

I prompt, il file CLAUDE.md e le competenze guidano il comportamento di Claude; tuttavia, non garantiscono che un’istruzione venga seguita. Gli hook possono eseguire controlli in occasione di eventi configurati, ma la loro affidabilità dipende dal tipo di hook e dall’implementazione.

Un hook di comando esegue uno script. Un prompt o un hook di agente si basa sul giudizio di un modello. Come spiega la guida alle best practice di Anthropic: «Un prompt o un hook di agente chiede a un altro modello di decidere, quindi non è deterministico». Per una regola che deve essere applicata, utilizzare controlli di autorizzazione appropriati e testare il comando o l’hook HTTP pertinente, verificandone anche la gestione degli errori.

I sottoagenti personalizzati rappresentano un altro modo per organizzare le attività ricorrenti. Definisci uno specialista in `claude/agents/` quando è necessario un ruolo di revisione specifico o un ambito di applicazione distinto per lo strumento, anziché aggiungere ogni istruzione relativa allo specialista alla sessione principale. Queste guide sul modello Claude più adatto al lavoro e sui tipi di agenti IA forniscono ulteriori informazioni di contesto.

Se il tuo team gestisce prompt su diversi prodotti di intelligenza artificiale, dai un'occhiata a questi strumenti di ingegneria dei prompt per gestire le librerie oltre a Claude Code.

Quando una sessione produce un risultato incompleto o inadeguato, verifica se la richiesta ha lasciato irrisolte decisioni importanti. Questi cinque errori possono rendere più difficile la diagnosi e la revisione del lavoro.

L'istruzione “Analizza il repository” fornisce a Claude poche indicazioni su quali file siano rilevanti o su quando interrompere l'analisi. Potresti ricevere un riepilogo/riassunto generico senza una risposta al problema che ha dato origine alla richiesta.

Indica il comportamento o la decisione che devi comprendere, individua una posizione di partenza e definisci l’output atteso. Ad esempio: “Traccia il modo in cui questo endpoint verifica le autorizzazioni e cita le funzioni pertinenti”. Se utilizzi subagenti, assegna a ciascuno di essi una domanda circoscritta, anziché delegare la stessa ricerca senza restrizioni.

Passare da una funzionalità/funzione a un bug non correlato e poi a una richiesta di documentazione fa sì che la conversazione continui a riportare un contesto che potrebbe non essere pertinente all’attività corrente. Riferimenti come «quel file» o «l’approccio precedente» diventano ambigui.

Utilizza sessioni separate per attività non correlate. Se più sessioni devono apportare modifiche al repository, utilizza alberi di lavoro Git separati in modo che non modifichino la stessa directory di lavoro. Una breve curiosità: il comando /btw di Claude Code mantiene lo scambio fuori dalla cronologia principale della conversazione.

Una build può superare i test anche se una funzionalità/funzione si comporta in modo errato. Una suite di test può superare i test semplicemente perché non ha mai verificato l’input che causa l’errore. Chiedere a Claude di «eseguire i test» non chiarisce quali requisiti tali test verifichino.

Mappa i criteri di accettazione a controlli specifici. Per la correzione di un bug, richiedi la prova che il test di riproduzione abbia dato esito negativo prima della modifica e positivo dopo. Mantieni la visibilità dei criteri non testati, anziché considerare un singolo comando riuscito come verifica dell’intera modifica.

Un file CLAUDE.md in continua espansione può contenere comandi obsoleti, regole duplicate e istruzioni che contraddicono i requisiti specifici dell’attività. L’aggiunta di formulazioni più rigorose non risolve tali conflitti.

Confronta il file con il repository attuale. Rimuovi le indicazioni obsolete, chiarisci le regole in conflitto e sposta le istruzioni di applicazione limitata in regole o competenze con ambito di percorso. Se un requisito deve essere applicato, configura e testa i controlli appropriati invece di affidarti a ripetuti promemoria.

Una revisione può evidenziare contemporaneamente difetti effettivi, aspetti incerti e suggerimenti facoltativi di refactoring. L’applicazione di ogni suggerimento può ampliare la portata delle modifiche senza migliorare il comportamento richiesto.

Chiedi le prove e l’impatto alla base di ogni risultato. Assegna priorità ai problemi di correttezza e ai requisiti non soddisfatti, approfondisci le affermazioni incerte ed escludi dal diff corrente i miglioramenti non pertinenti. Un revisore dovrebbe essere in grado di segnalare l’assenza di risultati rilevanti quando le prove supportano tale conclusione.

Per adattare un modello, sostituisci i suoi segnaposto con i dettagli del tuo progetto e decidi cosa deve fare Claude prima di apportare le modifiche. Segui questi passaggi per preparare la richiesta e verificare il risultato.

Per una modifica piccola e ben definita, puoi chiedere a Claude di implementarla direttamente. Per codice che non conosci, modifiche che interessano più file o requisiti non risolti, inizia con un piano.

Premi Shift+Tab fino a quando non compare la modalità Plan, oppure avvia Claude Code con il comando claude --permission-mode plan. In questa modalità, Claude può ispezionare i file ed eseguire comandi in sola lettura senza effettuare modifiche al tuo codice sorgente. Esamina i file, le dipendenze e i test proposti prima di approvare l'implementazione. Premi Ctrl+G per aprire il piano proposto nel tuo editor.

Fornisci a Claude le informazioni necessarie per comprendere l’attività: un riferimento a un file, un log degli errori depurato, uno screenshot o un documento dei requisiti. Usa il simbolo @ seguito dal percorso del file per includerne il contenuto.

Scegli l’insieme più piccolo possibile di origini dati utili. Includere un intero log o una directory può aggiungere materiale irrilevante e consumare contesto. Rimuovi le credenziali e i dati sensibili prima della condivisione dei log e verifica che Claude disponga degli strumenti necessari per recuperare eventuali URL di documentazione che fornisci.

Ad esempio, il comando `cat error.log | claude -p "Spiega questo errore"` invia un log tramite una richiesta non interattiva. Utilizzalo solo dopo aver verificato il contenuto del file. Questo è il valore pratico dell’IA contestuale: fornire al modello informazioni rilevanti per l’attività da svolgere.

Quando aggiungi una funzionalità/funzione, individua un componente o una funzione simile nel repository. Indica a Claude quali convenzioni seguire, come il client API, la logica di validazione, la gestione degli errori o la struttura dei test.

“Segui come @src/widgets/Weather.tsx recupera e memorizza i dati nella cache” fornisce a Claude un riferimento concreto. Indica inoltre eventuali differenze richieste dalla nuova funzionalità/funzione, in modo che non venga copiato un comportamento ormai obsoleto. Queste convenzioni dovrebbero riflettere il flusso di lavoro di sviluppo software del tuo team.

Per le modifiche al codice, specifica il comando di test, build o lint pertinente e il comportamento che dovrebbe verificare. Per la ricerca, richiedi i riferimenti ai file o gli ID dei commit. Per il lavoro sull'interfaccia utente, fornisci un'immagine di riferimento e una modalità configurata per catturare l'implementazione nello stesso viewport.

Chiedi a Claude di fornire la reportistica relativa a ciò che ha effettivamente verificato, inclusi gli errori e i controlli saltati. Verifica se le prove soddisfano i requisiti; una build superata non garantisce che ogni comportamento richiesto funzioni correttamente.

Per attività più lunghe, Claude Code offre anche una condizione /goal e gli hook Stop. Il valutatore degli obiettivi analizza le prove emerse nella conversazione anziché ispezionare autonomamente i file o eseguire test. Un hook Stop configurato può bloccare il completamento, ma presenta dei limiti per quanto riguarda i blocchi ripetuti. Nessuno dei due sostituisce i test appropriati e la revisione umana.

Se le ripetute correzioni non risolvono un problema, fermati e individua cosa non era chiaro nella richiesta originale. Salva le informazioni utili, lo stato attuale di Git e il lavoro rimanente prima di cancellare la conversazione.

La guida alle best practice di Anthropic consiglia di ricominciare da capo dopo due correzioni infruttuose sullo stesso problema. Utilizza il comando /clear, quindi fornisci un prompt rivisto che includa ciò che hai imparato. L'azzeramento della conversazione non annulla le modifiche apportate ai file.

Premi Esc per interrompere una risposta in esecuzione. Con il prompt vuoto, premi Esc due volte per aprire il menu di riavvolgimento e scegliere cosa ripristinare. Il riavvolgimento non annulla tutti gli effetti esterni, quindi utilizza i checkpoint di Git e procedure di ripristino separate per le modifiche ai database o ai servizi remoti.

Salva le linee guida relative all’intero progetto nel file CLAUDE.md, le procedure ripetibili nelle skill e le istruzioni per file specifici nelle regole con ambito di percorso. Utilizza gli hook per azioni legate a eventi specifici, come l’esecuzione di un formattatore dopo una modifica.

Scegli in base al momento in cui l’istruzione deve essere applicata:

I requisiti relativi a una singola funzionalità/funzione vanno solitamente inseriti nel prompt dell’attività o nelle specifiche relative a essa, piuttosto che nel file CLAUDE.md. L’aggiunta di istruzioni temporanee a un file a livello di progetto rende più difficile distinguerle dalle convenzioni che dovrebbero essere applicate in tutto il repository.

Ad esempio, inserisci il comando di test del progetto nel file CLAUDE.md, inserisci le convenzioni specifiche per i componenti in una regola con ambito di percorso e salva una procedura di revisione ricorrente come skill. Rivedi questi file quando i comandi o le convenzioni cambiano, proprio come faresti con qualsiasi altra documentazione di progetto.

I prompt, il file CLAUDE.md e le competenze guidano il comportamento di Claude; tuttavia, non garantiscono che un’istruzione venga seguita. Gli hook possono eseguire controlli in occasione di eventi configurati, ma la loro affidabilità dipende dal tipo di hook e dall’implementazione.

Un hook di comando esegue uno script. Un prompt o un hook di agente si basa sul giudizio di un modello. Come spiega la guida alle best practice di Anthropic: «Un prompt o un hook di agente chiede a un altro modello di decidere, quindi non è deterministico». Per una regola che deve essere applicata, utilizzare controlli di autorizzazione appropriati e testare il comando o l’hook HTTP pertinente, verificandone anche la gestione degli errori.

I subagenti personalizzati rappresentano un altro modo per organizzare le attività ricorrenti. Definisci uno specialista in claude/agents/ quando è necessario un ruolo di revisione specifico o un ambito di applicazione distinto per lo strumento, anziché aggiungere ogni istruzione relativa allo specialista alla sessione principale. Queste guide al miglior modello Claude per il lavoro e ai tipi di agenti IA forniscono ulteriori informazioni di contesto.

Se il tuo team gestisce prompt su diversi prodotti di intelligenza artificiale, dai un'occhiata a questi strumenti di ingegneria dei prompt per gestire le librerie oltre a Claude Code.

Quando una sessione produce un risultato incompleto o inadeguato, verifica se la richiesta ha lasciato irrisolte decisioni importanti. Questi cinque errori possono rendere più difficile la diagnosi e la revisione del lavoro.

L'istruzione “Esamina il repository” fornisce a Claude poche indicazioni su quali file siano rilevanti o su quando interrompere l'analisi. Potresti ricevere un riepilogo/riassunto generico senza una risposta al problema che ha dato origine alla richiesta.

Indica il comportamento o la decisione che devi comprendere, identifica una posizione di partenza e definisci l’output atteso. Ad esempio: “Traccia il modo in cui questo endpoint verifica le autorizzazioni e cita le funzioni pertinenti”. Se utilizzi dei subagenti, assegna a ciascuno di essi una domanda circoscritta, anziché delegare la stessa ricerca senza restrizioni.

Passare da una funzionalità/funzione a un bug non correlato e poi a una richiesta di documentazione fa sì che la conversazione continui a riportare un contesto che potrebbe non essere pertinente all’attività corrente. Riferimenti come «quel file» o «l’approccio precedente» diventano ambigui.

Utilizza sessioni separate per attività non correlate. Se più sessioni devono apportare modifiche al repository, utilizza alberi di lavoro Git separati in modo che non modifichino la stessa directory di lavoro. Una breve curiosità: il comando /btw di Claude Code mantiene lo scambio fuori dalla cronologia principale della conversazione.

Una build può superare i test anche se una funzionalità/funzione si comporta in modo errato. Una suite di test può superare i test semplicemente perché non ha mai verificato l’input che causa l’errore. Chiedere a Claude di «eseguire i test» non chiarisce quali requisiti tali test verifichino.

Mappa i criteri di accettazione a controlli specifici. Per la correzione di un bug, richiedi la prova che il test di riproduzione abbia dato esito negativo prima della modifica e positivo dopo. Mantieni visibili i criteri non testati, anziché considerare un singolo comando riuscito come verifica dell’intera modifica.

Un file CLAUDE.md in continua espansione può contenere comandi obsoleti, regole duplicate e istruzioni che contraddicono i requisiti specifici dell’attività. L’aggiunta di formulazioni più rigorose non risolve tali conflitti.

Confronta il file con il repository attuale. Rimuovi le indicazioni obsolete, chiarisci le regole in conflitto e sposta le istruzioni di applicazione limitata in regole o competenze con ambito di percorso. Se un requisito deve essere applicato, configura e testa i controlli appropriati invece di affidarti a ripetuti promemoria.

Una revisione può evidenziare contemporaneamente difetti effettivi, aspetti incerti e suggerimenti facoltativi di rifattorizzazione. L’applicazione di ogni suggerimento può ampliare la portata delle modifiche senza migliorare il comportamento richiesto.

Chiedi le prove e l’impatto alla base di ogni risultato. Assegna priorità ai problemi di correttezza e ai requisiti non soddisfatti, approfondisci le affermazioni incerte ed escludi dal diff corrente i miglioramenti non pertinenti. Un revisore dovrebbe essere in grado di segnalare l’assenza di risultati rilevanti quando le prove supportano tale conclusione.

Per adattare un modello, sostituisci i suoi segnaposto con i dettagli del tuo progetto e decidi cosa deve fare Claude prima di apportare le modifiche. Segui questi passaggi per preparare la richiesta e verificare il risultato.

Per una modifica piccola e ben definita, puoi chiedere a Claude di implementarla direttamente. Per codice che non conosci, modifiche che interessano più file o requisiti non risolti, inizia con un piano.

Premi Shift+Tab fino a quando non compare la modalità Plan, oppure avvia Claude Code con il comando claude --permission-mode plan. In questa modalità, Claude può ispezionare i file ed eseguire comandi in sola lettura senza effettuare modifiche al tuo codice sorgente. Esamina i file, le dipendenze e i test proposti prima di approvare l'implementazione. Premi Ctrl+G per aprire il piano proposto nel tuo editor.

Fornisci a Claude le informazioni necessarie per comprendere l’attività: un riferimento a un file, un log degli errori depurato, uno screenshot o un documento dei requisiti. Usa @ seguito dal percorso del file per includerne il contenuto.

Scegli l’insieme più piccolo possibile di fonti utili. Includere un log o una directory intera può aggiungere materiale irrilevante e consumare contesto. Rimuovi le credenziali e i dati sensibili prima della condivisione dei log e verifica che Claude disponga degli strumenti necessari per recuperare gli URL della documentazione che fornisci.

Ad esempio, il comando `cat error.log | claude -p "Spiega questo errore"` invia un log tramite una richiesta non interattiva. Utilizzalo solo dopo aver verificato il contenuto del file. Questo è il valore pratico dell’IA contestuale: fornire al modello informazioni rilevanti per l’attività da svolgere.

Quando aggiungi una funzionalità/funzione, individua un componente o una funzione simile nel repository. Indica a Claude quali convenzioni seguire, come il client API, la logica di validazione, la gestione degli errori o la struttura dei test.

“Segui come @src/widgets/Weather.tsx recupera e memorizza i dati nella cache” fornisce a Claude un riferimento concreto. Indica inoltre eventuali differenze richieste dalla nuova funzionalità/funzione, in modo che non venga copiato un comportamento ormai obsoleto. Queste convenzioni dovrebbero riflettere il flusso di lavoro di sviluppo software del tuo team.

Per le modifiche al codice, specifica il comando di test, build o lint pertinente e il comportamento che dovrebbe verificare. Per la ricerca, richiedi i riferimenti ai file o gli ID dei commit. Per il lavoro sull'interfaccia utente, fornisci un'immagine di riferimento e una modalità configurata per catturare l'implementazione nello stesso viewport.

Chiedi a Claude di riportare ciò che ha effettivamente verificato, inclusi gli errori e i controlli saltati. Verifica se le prove soddisfano i requisiti; una build superata non garantisce che ogni comportamento richiesto funzioni correttamente.

Per attività più lunghe, Claude Code offre anche una condizione /goal e gli hook Stop. Il valutatore degli obiettivi analizza le prove emerse nella conversazione anziché ispezionare autonomamente i file o eseguire test. Un hook Stop configurato può bloccare il completamento, ma presenta dei limiti per quanto riguarda i blocchi ripetuti. Nessuno dei due sostituisce i test appropriati e la revisione umana.

Se le ripetute correzioni non risolvono un problema, fermati e individua cosa non era chiaro nella richiesta originale. Salva le informazioni utili, lo stato attuale di Git e il lavoro rimanente prima di cancellare la conversazione.

La guida alle best practice di Anthropic consiglia di ricominciare da capo dopo due correzioni infruttuose sullo stesso problema. Utilizza il comando /clear, quindi fornisci un prompt rivisto che includa ciò che hai imparato. L'azzeramento della conversazione non annulla le modifiche apportate ai file.

Premi Esc per interrompere una risposta in esecuzione. Con il prompt vuoto, premi Esc due volte per aprire il menu di riavvolgimento e scegliere cosa ripristinare. Il riavvolgimento non annulla tutti gli effetti esterni, quindi utilizza i checkpoint di Git e procedure di ripristino separate per le modifiche ai database o ai servizi remoti.

Salva le linee guida relative all’intero progetto nel file CLAUDE.md, le procedure ripetibili nelle skill e le istruzioni per file specifici nelle regole con ambito di percorso. Utilizza gli hook per azioni legate a eventi specifici, come l’esecuzione di un formattatore dopo una modifica.

Scegli in base al momento in cui l’istruzione deve essere applicata:

I requisiti relativi a una singola funzionalità vanno solitamente inseriti nel prompt dell’attività o nelle specifiche relative a essa, piuttosto che nel file CLAUDE.md. L’aggiunta di istruzioni temporanee a un file a livello di progetto rende più difficile distinguerle dalle convenzioni che dovrebbero essere applicate in tutto il repository.

Ad esempio, inserisci il comando di test del progetto nel file CLAUDE.md, inserisci le convenzioni specifiche per i componenti in una regola con ambito di percorso e salva una procedura di revisione ricorrente come skill. Rivedi questi file quando i comandi o le convenzioni cambiano, proprio come faresti con qualsiasi altra documentazione di progetto.

I prompt, il file CLAUDE.md e le competenze guidano il comportamento di Claude; tuttavia, non garantiscono che un’istruzione venga seguita. Gli hook possono eseguire controlli in occasione di eventi configurati, ma la loro affidabilità dipende dal tipo di hook e dall’implementazione.

Un hook di comando esegue uno script. Un prompt o un hook di agente si basa sul giudizio di un modello. Come spiega la guida alle best practice di Anthropic: «Un prompt o un hook di agente chiede a un altro modello di decidere, quindi non è deterministico». Per una regola che deve essere applicata, utilizza controlli di autorizzazione appropriati e testa il comando o l’hook HTTP pertinente, verificandone anche la gestione degli errori.

I subagenti personalizzati rappresentano un altro modo per organizzare le attività ricorrenti. Definisci uno specialista in claude/agents/ quando è necessario un ruolo di revisione specifico o un ambito di applicazione distinto per lo strumento, anziché aggiungere ogni istruzione relativa allo specialista alla sessione principale. Queste guide sul miglior modello Claude per il lavoro e sui tipi di agenti IA forniscono ulteriori informazioni di contesto.

Se il tuo team gestisce prompt su diversi prodotti di intelligenza artificiale, dai un'occhiata a questi strumenti di ingegneria dei prompt per gestire le librerie oltre a Claude Code.

Quando una sessione produce un risultato incompleto o inadeguato, verifica se la richiesta ha lasciato irrisolte decisioni importanti. Questi cinque errori possono rendere più difficile la diagnosi e la revisione del lavoro.

L'istruzione “Esamina il repository” fornisce a Claude poche indicazioni su quali file siano rilevanti o su quando interrompere l'analisi. Potresti ricevere un riepilogo/riassunto generico senza una risposta al problema che ha dato origine alla richiesta.

Indica il comportamento o la decisione che devi comprendere, individua una posizione di partenza e definisci l’output atteso. Ad esempio: “Traccia il modo in cui questo endpoint verifica le autorizzazioni e cita le funzioni pertinenti”. Se utilizzi subagenti, assegna a ciascuno di essi una domanda circoscritta, anziché delegare la stessa ricerca senza restrizioni.

Passare da una funzionalità/funzione a un bug non correlato e poi a una richiesta di documentazione fa sì che la conversazione continui a riportare un contesto che potrebbe non essere pertinente all’attività corrente. Riferimenti come «quel file» o «l’approccio precedente» diventano ambigui.

Utilizza sessioni separate per attività non correlate. Se più sessioni devono apportare modifiche al repository, utilizza alberi di lavoro Git separati in modo che non modifichino la stessa directory di lavoro. Una breve curiosità: il comando /btw di Claude Code mantiene lo scambio fuori dalla cronologia principale della conversazione.

Una build può superare i test anche se una funzionalità/funzione si comporta in modo errato. Una suite di test può superare i test semplicemente perché non ha mai verificato l’input che causa l’errore. Chiedere a Claude di «eseguire i test» non chiarisce quali requisiti tali test verifichino.

Mappa i criteri di accettazione a controlli specifici. Per la correzione di un bug, richiedi la prova che il test di riproduzione abbia dato esito negativo prima della modifica e positivo dopo. Mantieni la visibilità dei criteri non testati, anziché considerare un singolo comando riuscito come verifica dell’intera modifica.

Un file CLAUDE.md in continua espansione può contenere comandi obsoleti, regole duplicate e istruzioni che contraddicono i requisiti specifici dell’attività. L’aggiunta di formulazioni più rigorose non risolve tali conflitti.

Confronta il file con il repository attuale. Rimuovi le indicazioni obsolete, chiarisci le regole in conflitto e sposta le istruzioni di applicazione limitata in regole o competenze con ambito di percorso. Se un requisito deve essere applicato, configura e testa i controlli appropriati invece di affidarti a ripetuti promemoria.

Una revisione può evidenziare contemporaneamente difetti effettivi, aspetti incerti e suggerimenti facoltativi di rifattorizzazione. L’applicazione di ogni suggerimento può ampliare la portata delle modifiche senza migliorare il comportamento richiesto.

Chiedi le prove e l’impatto alla base di ogni riscontro. Assegna priorità ai problemi di correttezza e ai requisiti non soddisfatti, approfondisci le affermazioni incerte ed escludi dal diff corrente i miglioramenti non pertinenti. Un revisore dovrebbe essere in grado di segnalare l’assenza di riscontri rilevanti quando le prove supportano tale conclusione.

Per adattare un modello, sostituisci i suoi segnaposto con i dettagli del tuo progetto e decidi cosa deve fare Claude prima di apportare le modifiche. Segui questi passaggi per preparare la richiesta e verificare il risultato.

Per una modifica piccola e ben definita, puoi chiedere a Claude di implementarla direttamente. Per codice che non conosci, modifiche che interessano più file o requisiti non risolti, inizia con un piano.

Premi Shift+Tab fino a quando non compare la modalità Plan, oppure avvia Claude Code con il comando claude --permission-mode plan. In questa modalità, Claude può ispezionare i file ed eseguire comandi in sola lettura senza effettuare modifiche al tuo codice sorgente. Esamina i file, le dipendenze e i test proposti prima di approvare l'implementazione. Premi Ctrl+G per aprire il piano proposto nel tuo editor.

Fornisci a Claude le informazioni necessarie per comprendere l’attività: un riferimento a un file, un log degli errori depurato, uno screenshot o un documento dei requisiti. Usa il simbolo @ seguito dal percorso del file per includerne il contenuto.

Scegli l’insieme più piccolo possibile di fonti utili. Includere un log o una directory intera può aggiungere materiale irrilevante e consumare contesto. Rimuovi le credenziali e i dati sensibili prima della condivisione dei log e verifica che Claude disponga degli strumenti necessari per recuperare eventuali URL di documentazione da te forniti.

Ad esempio, il comando `cat error.log | claude -p "Spiega questo errore"` invia un log tramite una richiesta non interattiva. Utilizzalo solo dopo aver verificato il contenuto del file. Questo è il valore pratico dell’IA contestuale: fornire al modello informazioni rilevanti per l’attività da svolgere.

Quando aggiungi una funzionalità/funzione, individua un componente o una funzione simile nel repository. Indica a Claude quali convenzioni seguire, come il client API, la logica di validazione, la gestione degli errori o la struttura dei test.

“Segui come @src/widgets/Weather.tsx recupera e memorizza i dati nella cache” fornisce a Claude un riferimento concreto. Indica inoltre eventuali differenze richieste dalla nuova funzionalità/funzione, in modo che non venga copiato un comportamento ormai obsoleto. Queste convenzioni dovrebbero riflettere il flusso di lavoro di sviluppo software del tuo team.

Per le modifiche al codice, specifica il comando di test, build o lint pertinente e il comportamento che dovrebbe verificare. Per la ricerca, richiedi i riferimenti ai file o gli ID dei commit. Per il lavoro sull'interfaccia utente, fornisci un'immagine di riferimento e una modalità configurata per catturare l'implementazione nello stesso viewport.

Chiedi a Claude di riportare ciò che ha effettivamente verificato, inclusi gli errori e i controlli saltati. Verifica se le prove soddisfano i requisiti; una build superata non garantisce che ogni comportamento richiesto funzioni correttamente.

Per attività più lunghe, Claude Code offre anche una condizione /goal e gli hook Stop. Il valutatore degli obiettivi analizza le prove emerse nella conversazione anziché ispezionare autonomamente i file o eseguire test. Un hook Stop configurato può bloccare il completamento, ma presenta dei limiti per quanto riguarda i blocchi ripetuti. Nessuno dei due sostituisce i test appropriati e la revisione umana.

Se le ripetute correzioni non risolvono un problema, fermati e individua cosa non era chiaro nella richiesta originale. Salva le informazioni utili, lo stato attuale di Git e il lavoro rimanente prima di cancellare la conversazione.

La guida alle best practice di Anthropic consiglia di ricominciare da capo dopo due correzioni infruttuose sullo stesso problema. Utilizza il comando /clear, quindi fornisci un prompt rivisto che includa ciò che hai imparato. L'azzeramento della conversazione non annulla le modifiche apportate ai file.

Premi Esc per interrompere una risposta in esecuzione. Con il prompt vuoto, premi Esc due volte per aprire il menu di riavvolgimento e scegliere cosa ripristinare. Il riavvolgimento non annulla tutti gli effetti esterni, quindi utilizza i checkpoint di Git e procedure di ripristino separate per le modifiche ai database o ai servizi remoti.

Salva le linee guida relative all’intero progetto nel file CLAUDE.md, le procedure ripetibili nelle skill e le istruzioni per file specifici nelle regole con ambito di percorso. Utilizza gli hook per azioni legate a eventi specifici, come l’esecuzione di un formattatore dopo una modifica.

Scegli in base al momento in cui l’istruzione deve essere applicata:

I requisiti relativi a una singola funzionalità vanno solitamente inseriti nel prompt dell’attività o nelle specifiche relative a essa, piuttosto che nel file CLAUDE.md. L’aggiunta di istruzioni temporanee a un file a livello di progetto rende più difficile distinguerle dalle convenzioni che dovrebbero essere applicate in tutto il repository.

Ad esempio, inserisci il comando di test del progetto nel file CLAUDE.md, inserisci le convenzioni specifiche per i componenti in una regola con ambito di percorso e salva una procedura di revisione ricorrente come skill. Rivedi questi file quando i comandi o le convenzioni cambiano, proprio come faresti con qualsiasi altra documentazione del progetto.

I prompt, il file CLAUDE.md e le competenze guidano il comportamento di Claude; tuttavia, non garantiscono che un’istruzione venga seguita. Gli hook possono eseguire controlli in occasione di eventi configurati, ma la loro affidabilità dipende dal tipo di hook e dall’implementazione.

Un hook di comando esegue uno script. Un prompt o un hook di agente si basa sul giudizio di un modello. Come spiega la guida alle best practice di Anthropic: «Un prompt o un hook di agente chiede a un altro modello di decidere, quindi non è deterministico». Per una regola che deve essere applicata, utilizzare controlli di autorizzazione appropriati e testare il comando o l’hook HTTP pertinente, verificandone anche la gestione degli errori.

I subagenti personalizzati rappresentano un altro modo per organizzare le attività ricorrenti. Definisci uno specialista in claude/agents/ quando è necessario un ruolo di revisione specifico o un ambito di applicazione distinto per lo strumento, anziché aggiungere ogni istruzione relativa allo specialista alla sessione principale. Queste guide al miglior modello Claude per il lavoro e ai tipi di agenti IA forniscono ulteriori informazioni di contesto.

Se il tuo team gestisce prompt su diversi prodotti di IA, dai un'occhiata a questi strumenti di ingegneria dei prompt per gestire le librerie oltre a Claude Code.

Quando una sessione produce un risultato incompleto o inadeguato, verifica se la richiesta ha lasciato irrisolte decisioni importanti. Questi cinque errori possono rendere più difficile la diagnosi e la revisione del lavoro.

L'istruzione “Analizza il repository” fornisce a Claude poche indicazioni su quali file siano rilevanti o su quando interrompere l'analisi. Potresti ricevere un riepilogo/riassunto generico senza una risposta al problema che ha dato origine alla richiesta.

Indica il comportamento o la decisione che devi comprendere, individua una posizione di partenza e definisci l’output atteso. Ad esempio: “Traccia il modo in cui questo endpoint verifica le autorizzazioni e cita le funzioni pertinenti”. Se utilizzi subagenti, assegna a ciascuno di essi una domanda circoscritta, anziché delegare la stessa ricerca senza restrizioni.

Passare da una funzionalità/funzione a un bug non correlato e poi a una richiesta di documentazione fa sì che la conversazione continui a riportare un contesto che potrebbe non essere pertinente all’attività corrente. Riferimenti come «quel file» o «l’approccio precedente» diventano ambigui.

Utilizza sessioni separate per attività non correlate. Se più sessioni devono apportare modifiche al repository, utilizza alberi di lavoro Git separati in modo che non modifichino la stessa directory di lavoro. Una breve curiosità: il comando /btw di Claude Code mantiene lo scambio fuori dalla cronologia principale della conversazione.

Una build può superare i test anche se una funzionalità/funzione si comporta in modo errato. Una suite di test può superare i test semplicemente perché non ha mai verificato l’input che causa l’errore. Chiedere a Claude di «eseguire i test» non chiarisce quali requisiti tali test verifichino.

Mappa i criteri di accettazione a controlli specifici. Per la correzione di un bug, richiedi la prova che il test di riproduzione abbia dato esito negativo prima della modifica e positivo dopo. Mantieni visibili i criteri non testati, anziché considerare un singolo comando riuscito come verifica dell’intera modifica.

Un file CLAUDE.md in continua espansione può contenere comandi obsoleti, regole duplicate e istruzioni che contraddicono i requisiti specifici dell’attività. L’aggiunta di formulazioni più rigorose non risolve tali conflitti.

Confronta il file con il repository attuale. Rimuovi le indicazioni obsolete, chiarisci le regole in conflitto e sposta le istruzioni di applicazione limitata in regole o competenze con ambito di percorso. Se un requisito deve essere applicato, configura e testa i controlli appropriati invece di affidarti a ripetuti promemoria.

Una revisione può evidenziare contemporaneamente difetti effettivi, aspetti incerti e suggerimenti facoltativi di rifattorizzazione. L’applicazione di ogni suggerimento può ampliare la portata delle modifiche senza migliorare il comportamento richiesto.

Chiedi le prove e l’impatto alla base di ogni riscontro. Assegna priorità ai problemi di correttezza e ai requisiti non soddisfatti, approfondisci le affermazioni incerte ed escludi dal diff corrente i miglioramenti non pertinenti. Un revisore dovrebbe essere in grado di segnalare l’assenza di riscontri che richiedono un intervento quando le prove supportano tale conclusione.

Per adattare un modello, sostituisci i suoi segnaposto con i dettagli del tuo progetto e decidi cosa deve fare Claude prima di apportare le modifiche. Segui questi passaggi per preparare la richiesta e verificare il risultato.

Per una modifica piccola e ben definita, puoi chiedere a Claude di implementarla direttamente. Per codice che non conosci, modifiche che interessano più file o requisiti non risolti, inizia con un piano.

Premi Shift+Tab fino a quando non compare la modalità Plan, oppure avvia Claude Code con il comando claude --permission-mode plan. In questa modalità, Claude può ispezionare i file ed eseguire comandi in sola lettura senza effettuare modifiche al tuo codice sorgente. Esamina i file, le dipendenze e i test proposti prima di approvare l'implementazione. Premi Ctrl+G per aprire il piano proposto nel tuo editor.

Fornisci a Claude le informazioni necessarie per comprendere l’attività: un riferimento a un file, un log degli errori depurato, uno screenshot o un documento dei requisiti. Usa il simbolo @ seguito dal percorso del file per includerne il contenuto.

Scegli l’insieme più piccolo possibile di fonti utili. Includere un log o una directory intera può aggiungere materiale irrilevante e consumare contesto. Rimuovi le credenziali e i dati sensibili prima della condivisione dei log e verifica che Claude disponga degli strumenti necessari per recuperare eventuali URL di documentazione che fornisci.

Ad esempio, il comando `cat error.log | claude -p "Spiega questo errore"` invia un log tramite una richiesta non interattiva. Utilizzalo solo dopo aver verificato il contenuto del file. Questo è il valore pratico dell’IA contestuale: fornire al modello informazioni rilevanti per l’attività da svolgere.

Quando aggiungi una funzionalità/funzione, individua un componente o una funzione simile nel repository. Indica a Claude quali convenzioni seguire, come il client API, la logica di validazione, la gestione degli errori o la struttura dei test.

“Segui come @src/widgets/Weather.tsx recupera e memorizza i dati nella cache” fornisce a Claude un riferimento concreto. Indica inoltre eventuali differenze richieste dalla nuova funzionalità/funzione, in modo che non venga copiato un comportamento ormai obsoleto. Queste convenzioni dovrebbero riflettere il flusso di lavoro di sviluppo software del tuo team.

Per le modifiche al codice, specifica il comando di test, build o lint pertinente e il comportamento che dovrebbe verificare. Per la ricerca, richiedi i riferimenti ai file o gli ID dei commit. Per il lavoro sull'interfaccia utente, fornisci un'immagine di riferimento e una modalità configurata per catturare l'implementazione nello stesso viewport.

Chiedi a Claude di fornire la reportistica relativa a ciò che ha effettivamente verificato, inclusi gli errori e i controlli saltati. Verifica se le prove soddisfano i requisiti; una build superata non garantisce che ogni comportamento richiesto funzioni correttamente.

Per attività più lunghe, Claude Code offre anche una condizione /goal e gli hook Stop. Il valutatore degli obiettivi analizza le prove emerse nella conversazione anziché ispezionare autonomamente i file o eseguire test. Un hook Stop configurato può bloccare il completamento, ma presenta dei limiti per quanto riguarda i blocchi ripetuti. Nessuno dei due sostituisce i test appropriati e la revisione umana.

Se le ripetute correzioni non risolvono un problema, fermati e individua cosa non era chiaro nella richiesta originale. Salva le informazioni utili, lo stato attuale di Git e il lavoro rimanente prima di cancellare la conversazione.

La guida alle best practice di Anthropic consiglia di ricominciare da capo dopo due correzioni infruttuose sullo stesso problema. Utilizza il comando /clear, quindi fornisci un prompt rivisto che includa ciò che hai imparato. L'azzeramento della conversazione non annulla le modifiche apportate ai file.

Premi Esc per interrompere una risposta in esecuzione. Con il prompt vuoto, premi Esc due volte per aprire il menu di riavvolgimento e scegliere cosa ripristinare. Il riavvolgimento non annulla tutti gli effetti esterni, quindi utilizza i checkpoint di Git e procedure di ripristino separate per le modifiche ai database o ai servizi remoti.

Salva le linee guida relative all’intero progetto nel file CLAUDE.md, le procedure ripetibili nelle skill e le istruzioni per file specifici nelle regole con ambito di percorso. Utilizza gli hook per azioni legate a eventi specifici, come l’esecuzione di un formattatore dopo una modifica.

Scegli in base al momento in cui l’istruzione deve essere applicata:

I requisiti relativi a una singola funzionalità vanno solitamente inseriti nel prompt dell’attività o nelle specifiche relative a essa, piuttosto che nel file CLAUDE.md. L’aggiunta di istruzioni temporanee a un file a livello di progetto rende più difficile distinguerle dalle convenzioni che dovrebbero essere applicate in tutto il repository.

Ad esempio, inserisci il comando di test del progetto nel file CLAUDE.md, inserisci le convenzioni specifiche per i componenti in una regola con ambito di percorso e salva una procedura di revisione ricorrente come skill. Rivedi questi file quando i comandi o le convenzioni cambiano, proprio come faresti con qualsiasi altra documentazione del progetto.

I prompt, il file CLAUDE.md e le competenze guidano il comportamento di Claude; tuttavia, non garantiscono che un’istruzione venga seguita. Gli hook possono eseguire controlli in occasione di eventi configurati, ma la loro affidabilità dipende dal tipo di hook e dall’implementazione.

Un hook di comando esegue uno script. Un prompt o un hook di agente si basa sul giudizio di un modello. Come spiega la guida alle best practice di Anthropic: «Un prompt o un hook di agente chiede a un altro modello di decidere, quindi non è deterministico». Per una regola che deve essere applicata, utilizza controlli di autorizzazione appropriati e testa il comando o l’hook HTTP pertinente, verificandone anche la gestione degli errori.

I subagenti personalizzati rappresentano un altro modo per organizzare le attività ricorrenti. Definisci uno specialista in claude/agents/ quando è necessario un ruolo di revisione specifico o un ambito di applicazione distinto per lo strumento, anziché aggiungere ogni istruzione relativa allo specialista alla sessione principale. Queste guide al miglior modello Claude per il lavoro e ai tipi di agenti IA forniscono ulteriori informazioni di contesto.

Se il tuo team gestisce prompt su diversi prodotti di IA, dai un'occhiata a questi strumenti di ingegneria dei prompt per gestire le librerie oltre a Claude Code.

Quando una sessione produce un risultato incompleto o inadeguato, verifica se la richiesta ha lasciato irrisolte decisioni importanti. Questi cinque errori possono rendere più difficile la diagnosi e la revisione del lavoro.

L'istruzione “Analizza il repository” fornisce a Claude poche indicazioni su quali file siano rilevanti o su quando interrompere l'analisi. Potresti ricevere un riepilogo/riassunto generico senza una risposta al problema che ha dato origine alla richiesta.

Indica il comportamento o la decisione che devi comprendere, individua una posizione di partenza e definisci l’output atteso. Ad esempio: “Traccia il modo in cui questo endpoint verifica le autorizzazioni e cita le funzioni pertinenti”. Se utilizzi dei subagenti, assegna a ciascuno di essi una domanda circoscritta, anziché delegare la stessa ricerca senza restrizioni.

Passare da una funzionalità/funzione a un bug non correlato e poi a una richiesta di documentazione fa sì che la conversazione continui a riportare un contesto che potrebbe non essere pertinente all’attività corrente. Riferimenti come «quel file» o «l’approccio precedente» diventano ambigui.

Utilizza sessioni separate per attività non correlate. Se più sessioni devono apportare modifiche al repository, utilizza alberi di lavoro Git separati in modo che non modifichino la stessa directory di lavoro. Una breve curiosità: il comando /btw di Claude Code mantiene lo scambio fuori dalla cronologia principale della conversazione.

Una build può superare i test anche se una funzionalità/funzione si comporta in modo errato. Una suite di test può superare i test semplicemente perché non ha mai verificato l’input che causa l’errore. Chiedere a Claude di «eseguire i test» non chiarisce quali requisiti tali test verifichino.

Mappa i criteri di accettazione a controlli specifici. Per la correzione di un bug, richiedi la prova che il test di riproduzione abbia dato esito negativo prima della modifica e positivo dopo. Mantieni visibili i criteri non testati, anziché considerare un singolo comando riuscito come verifica dell’intera modifica.

Un file CLAUDE.md in continua espansione può contenere comandi obsoleti, regole duplicate e istruzioni che contraddicono i requisiti specifici dell’attività. L’aggiunta di formulazioni più rigorose non risolve tali conflitti.

Confronta il file con il repository attuale. Rimuovi le indicazioni obsolete, chiarisci le regole in conflitto e sposta le istruzioni di applicazione limitata in regole o competenze con ambito di applicazione specifico. Se un requisito deve essere applicato, configura e testa i controlli appropriati invece di affidarti a ripetuti promemoria.

Una revisione può evidenziare contemporaneamente difetti effettivi, aspetti incerti e suggerimenti facoltativi di refactoring. L’applicazione di ogni suggerimento può ampliare la portata delle modifiche senza migliorare il comportamento richiesto.

Chiedi le prove e l’impatto alla base di ogni riscontro. Assegna priorità ai problemi di correttezza e ai requisiti non soddisfatti, approfondisci le affermazioni incerte ed escludi dal diff corrente i miglioramenti non pertinenti. Un revisore dovrebbe essere in grado di segnalare l’assenza di riscontri che richiedono un intervento quando le prove supportano tale conclusione.