Come creare loop con Claude Code

Ecco la traduzione in italiano del testo fornito, seguendo tutte le linee guida specificate.

La maggior parte dei flussi di lavoro con Claude sono ancora "one-shot".

Scrivi un prompt. Claude risponde. La sessione termina. Domani ricominci da zero.

Va bene per attività una tantum.

Ma per lavori ripetitivi — revisioni quotidiane, triage CI, monitoraggio progetti, follow-up di riunioni — ricostruisci lo stesso contesto ogni singolo giorno.

Questo non è un flusso di lavoro. È lavoro manuale con un pizzico di AI.

L'astrazione migliore è un loop.

Salva questo. Ti sarà utile.

Cosa è realmente un loop di Claude

Un loop non significa "chiedere di nuovo a Claude".

Un loop è una struttura di flusso di lavoro ripetibile attorno al modello.

Definisce:

→ Cosa attiva l'esecuzione

→ Quale contesto Claude legge prima di agire

→ Cosa a Claude è permesso fare → Come viene verificato l'output

→ Dove viene memorizzato lo stato

→ Quando fermarsi, ripetere o chiedere una revisione umana

Il modello fa ancora il ragionamento.

Il loop fornisce la struttura operativa.

Il cambiamento è importante perché le sessioni di Claude sono temporanee.

Senza un loop, ogni esecuzione parte da zero. Con un loop, Claude legge cosa è successo prima e continua da lì.

6 parti di cui ogni loop di Claude ha bisogno

Un loop senza struttura è solo un prompt che viene eseguito due volte.

Ecco le 6 parti che fanno funzionare realmente un loop:

→ 1. Trigger

Cosa avvia l'esecuzione.

Comando manuale. Timer programmato. Modifica di un file. Fallimento CI. Evento Git.

→ 2. Contesto

Cosa legge Claude prima di agire.

Definizione dell'attività. Progressi precedenti. File di progetto. Istruzioni.

→ 3. Azione

Cosa fa Claude.

Scrivere un report. Abbozzare una correzione. Classificare i fallimenti. Aggiornare un documento.

→ 4. Verifica

Come controlli il risultato.

Checklist. Suite di test. Sezioni richieste. Controllo dei limiti di sicurezza.

→ 5. Aggiornamento dello stato

Cosa viene ricordato per la prossima volta.

PROGRESS.md aggiornato. Bloccanti registrati. Prossima esecuzione guidata.

→ 6. Decisione

Fermati. Ripeti. O passa all'umano.

Questo è il loop completo.

E ogni passaggio è importante.

Salta la verifica → il loop si fida ciecamente di sé stesso.

Salta lo stato → ogni esecuzione parte da zero.

Salta la decisione → il loop non sa mai quando fermarsi.

Il sistema a 4 file che fa funzionare i loop

Non hai bisogno di infrastruttura.

Hai bisogno di 4 file e una cartella.

1my-loop/
2├── TASK.md
3├── LOOP_INSTRUCTIONS.md
4├── PROGRESS.md
5└── outputs/
6    └── daily-review.md

TASK.md — L'obiettivo. Cosa questo loop sta cercando di realizzare.

LOOP_INSTRUCTIONS.md — La procedura operativa. Come Claude dovrebbe eseguire, cosa gli è permesso fare, come verificare.

PROGRESS.md — La memoria. Cosa è successo l'ultima volta, cosa è bloccato, su cosa dovrebbe concentrarsi la prossima esecuzione.

outputs/ — Dove Claude scrive i risultati. Prevedibile. Ispezionabile. Sicuro.

Tutto qui.

Claude legge questi file all'inizio di ogni esecuzione. Li aggiorna alla fine. La prossima esecuzione continua da dove l'ultima si è fermata.

Questo è ciò che rende i loop diversi dai prompt ripetuti.

Lo stato vive al di fuori della chat.

TASK.md — Definisci l'obiettivo chiaramente

Questo file dice a Claude a cosa serve il loop.

Mantienilo ad alto livello. Non inserire dettagli operativi qui. Quelli vanno in LOOP_INSTRUCTIONS.md.

Copia questo template:

1# Loop di Revisione Progetto Giornaliero
2
3## Obiettivo
4Revisionare questa cartella di progetto, riassumere cosa è cambiato,
5identificare i bloccanti e produrre un breve report di revisione giornaliero.
6
7## Output Atteso
8Ogni esecuzione dovrebbe produrre o aggiornare:
9- `outputs/daily-review.md`
10- `PROGRESS.md`
11
12## Ambito
13A Claude è permesso ispezionare i file in questo spazio di lavoro e scrivere
14report nella cartella `outputs/`.
15
16Claude NON dovrebbe:
17- Modificare i file sorgente
18- Cancellare o rinominare file
19- Inviare messaggi o aprire ticket

Nota l'ultima sezione.

La prima versione di qualsiasi loop dovrebbe avere regole esplicite di "non fare".

Non è che Claude non sia affidabile.

È che tu sei un bravo ingegnere.

PROGRESS.md — La memoria del loop

Questo è il file più importante del sistema.

Senza di esso, ogni esecuzione parte da zero. Con esso, Claude sa cosa è successo e continua da lì.

La struttura che funziona realmente:

1# Progresso del Loop
2
3## Stato Corrente
4- Stato: Attivo
5- Obiettivo principale: Revisione progetto giornaliera
6- Focus attuale: [cosa conta in questo momento]
7- Ultimo aggiornamento: [data]
8
9## Ultima Esecuzione
10- Data:
11- Riepilogo:
12- File revisionati:
13- Output prodotto:
14
15## Elementi Aperti
16-
17
18## Bloccanti
19-
20
21## Necessita Revisione Umana
22-
23
24## La Prossima Esecuzione Dovrebbe
25-
26
27## Decisioni Prese
28-
29
30## Non Ripetere
31-

La sezione "Non Ripetere" è fondamentale.

Impedisce a Claude di riprovare cose che sono già fallite.

La sezione "Necessita Revisione Umana" è fondamentale.

Impedisce al loop di continuare silenziosamente quando non dovrebbe.

Due regole per mantenere PROGRESS.md utile:

→ Se Claude ne ha bisogno per decidere l'azione successiva → tienilo in PROGRESS.md → Se vuoi solo una registrazione → spostalo in outputs/history/

I file di stato che crescono all'infinito diventano inutili.

Mantieni PROGRESS.md come un pannello di controllo, non un archivio.

LOOP_INSTRUCTIONS.md — La procedura operativa

Questo file è il livello di controllo attorno a Claude.

Dice a Claude esattamente cosa leggere, cosa scrivere, cosa non toccare e come verificare il risultato prima di fermarsi.

Il template che funziona:

1# Istruzioni del Loop
2
3Stai eseguendo un loop di revisione progetto giornaliero.
4
5## Prima di Iniziare
61. Leggi `TASK.md`
72. Leggi `PROGRESS.md`
83. Ispeziona la cartella del progetto
94. Identifica cosa è cambiato, cosa è incompleto, cosa necessita revisione umana
10
11## Cosa Dovresti Fare
12Scrivi una breve revisione giornaliera in `outputs/daily-review.md` includendo:
13- Riepilogo dello stato corrente
14- File revisionati
15- Cambiamenti significativi
16- Bloccanti o domande irrisolte
17- Azioni successive raccomandate
18
19Dopo aver scritto, aggiorna `PROGRESS.md` con:
20- Data di questa esecuzione
21- Riepilogo di cosa è successo
22- File controllati
23- Cosa dovrebbe fare la prossima esecuzione
24- Se è necessaria una revisione umana
25
26## Regole di Sicurezza
27- Non cancellare file
28- Non rinominare o spostare file
29- Non modificare file sorgente
30- Scrivi solo in `outputs/daily-review.md` e `PROGRESS.md`
31- Se non sei sicuro se un'azione è consentita → fermati e chiedi
32
33## Checklist di Verifica
34Prima di terminare l'esecuzione, conferma:
35- `outputs/daily-review.md` esiste con tutte le sezioni richieste
36- `PROGRESS.md` è stato aggiornato
37- Nessun file al di fuori dei percorsi consentiti è stato modificato
38
39## Politica di Fallimento
40Se la verifica fallisce:
411. Sezione mancante nel report → correggi una volta
422. PROGRESS.md non aggiornato → aggiorna una volta
433. File vietato modificato → fermati immediatamente
444. Stesso controllo fallisce due volte → segna come bisognoso di revisione umana

Nota la politica di fallimento in fondo.

La maggior parte dei loop non ha una politica di fallimento.

Quindi, quando qualcosa va storto, Claude improvvisa.

È lì che i loop creano problemi.

Definisci il percorso di fallimento esplicitamente. Sempre.

Eseguire il tuo primo loop manualmente

Non programmare ancora.

Esegui prima manualmente.

Apri la cartella in Claude Code o Claude Desktop/Cowork. Usa questo prompt:

1Esegui il loop di revisione progetto giornaliero per questo spazio di lavoro.
2
3Segui esattamente `LOOP_INSTRUCTIONS.md`.
4
5Prima di agire, leggi:
6- `TASK.md`
7- `PROGRESS.md`
8- `LOOP_INSTRUCTIONS.md`
9
10Poi ispeziona lo spazio di lavoro, scrivi la revisione giornaliera in
11`outputs/daily-review.md`, aggiorna `PROGRESS.md`,
12esegui la checklist di verifica e riporta cosa è cambiato.
13
14Non modificare alcun file tranne
15`outputs/daily-review.md` e `PROGRESS.md`.

Dopo l'esecuzione, controlla due cose:

→ outputs/daily-review.md — report strutturato con tutte le sezioni

→ PROGRESS.md — stato aggiornato, guida per la prossima esecuzione, flag di revisione umana

Se entrambi sono a posto → il loop funziona.

Ora eseguilo altre 3-5 volte con piccole modifiche.

Aggiungi un file di note. Aggiungi un bloccante a PROGRESS.md. Cambia qualcosa nello spazio di lavoro.

Ogni esecuzione dovrebbe raccogliere le modifiche senza partire da zero.

Quella continuità è il punto centrale.

Verifica: la parte che la maggior parte delle persone salta

Ecco la modalità di fallimento di cui nessuno parla.

Claude esegue il loop. Dice di aver finito. Aggiorna lo stato. Si ferma.

Tutto sembra a posto.

Ma al report mancano sezioni richieste. O PROGRESS.md non è stato effettivamente aggiornato. O Claude ha silenziosamente modificato un file che non avrebbe dovuto.

Lo scopri solo quando qualcosa si rompe.

Ecco perché esiste la verifica.

Il loop non dovrebbe fermarsi perché Claude dice di aver finito.

Si ferma perché una condizione concreta è stata verificata.

Una buona verifica è così:

Esegui un passaggio di verifica per l'ultima esecuzione del loop.

Controlla l'output rispetto alla Checklist di Verifica

in LOOP_INSTRUCTIONS.md.

Riporta:

1. Quali controlli sono passati
2. Quali controlli sono falliti
3. Quali file sono stati modificati
4. Se l'esecuzione è sicura da accettare
5. Se è richiesta una revisione umana

Non modificare alcun file durante questo passaggio di verifica.

Esegui il worker. Poi esegui il verificatore. Separatamente.

Col tempo puoi unirli. Ma durante i test iniziali, tienili separati.

Il verificatore ha bisogno di uno standard pass/fail.

"Revisiona questo e dimmi se sembra a posto" NON è un verificatore.

"Controlla queste 7 condizioni e segna l'esecuzione come accettata solo se tutte e 7 passano" È un verificatore.

Pianificazione con /loop

Il loop funziona in modo affidabile manualmente.

Ora programmalo.

In Claude Code, usa /loop:

1/loop 24h Esegui il loop di revisione progetto giornaliero per questo spazio di lavoro.
2
3Segui esattamente `LOOP_INSTRUCTIONS.md`.
4Leggi prima `TASK.md` e `PROGRESS.md`.
5Scrivi il report in `outputs/daily-review.md`.
6Aggiorna `PROGRESS.md` prima di fermarti.
7Esegui la checklist di verifica.
8Se non ci sono cambiamenti significativi → mantieni il report breve.
9Se è necessaria una revisione umana → segnalalo chiaramente in `PROGRESS.md`.
10Non modificare alcun file tranne `outputs/daily-review.md`
11e `PROGRESS.md`.

Le opzioni di intervallo:

→ /loop 15m — Cadenza di test (usa mentre guardi)

→ /loop 1h — Monitoraggio orario

→ /loop 24h — Revisione giornaliera

→ /loop 7d — Pulizia o riepilogo settimanale

Importante: /loop non è magia.

Ripete solo il prompt.

La qualità del loop deriva dalla struttura attorno al prompt — i file, le istruzioni, la verifica, lo stato.

/loop fornisce solo il trigger.

Conosci anche /goal:

/loop = esegui di nuovo perché è passato del tempo.

/goal = continua a eseguire finché una condizione non viene soddisfatta.

1/goal outputs/daily-review.md esiste, PROGRESS.md è aggiornato,
2la checklist di verifica passa, nessun file vietato è stato modificato.

Usa /loop per lavori basati sul tempo (revisioni giornaliere, monitoraggio).

Usa /goal per lavori basati sul completamento (correggi finché i test non passano, scrivi finché tutte le sezioni non sono complete).

La scala delle autorizzazioni

È qui che la maggior parte dei loop va storta.

Le persone costruiscono un loop che funziona. Poi gli danno immediatamente troppo potere.

Il loop pubblica direttamente su Slack. Invia codice senza revisione. Chiude i ticket automaticamente.

Poi qualcosa va storto ed è un pasticcio.

Usa invece la scala delle autorizzazioni:

1Livello 1 — Solo lettura
2Claude legge file, ticket, log, problemi.
3
4Livello 2 — Bozze di output
5Claude scrive solo in outputs/.
6Report, piani, raccomandazioni.
7Niente di esterno.
8
9Livello 3 — Modifiche in sandbox
10Claude modifica file all'interno di una sandbox controllata.
11Branch o worktree isolato.
12
13Livello 4 — Bozze di azioni esterne
14Claude prepara PR, messaggio Slack, aggiornamento ticket.
15NON invia o unisce.
16
17Livello 5 — Azioni approvate dall'umano
18Claude applica modifiche solo dopo approvazione esplicita.
19
20Livello 6 — Azioni automatizzate a basso rischio
21Claude completa attività strettamente delimitate automaticamente.
22Con log, limiti e rollback.

Il tuo primo loop dovrebbe stare al Livello 1 o Livello 2.

Non è debolezza. È ingegneria.

I loop di Livello 1 e 2 possono comunque essere enormemente preziosi.

Claude può ispezionare i tuoi problemi GitHub, leggere i fallimenti CI, revisionare i PRD e riassumere tutto — tutto senza toccare nulla di importante.

Prova che il loop funziona al Livello 2 prima.

Poi decidi se merita il Livello 3.

Quando i loop vanno storti (e come prevenirlo)

Primo loop sbagliato:

Ogni giorno, migliora la strategia di prodotto finché non sembra più solida.

→ Nessuna condizione di arresto → Nessuna verifica → Nessuno stato → "Sembra più solida" non è un elemento della checklist

Questo loop o non farà nulla di utile o cambierà cose che non dovrebbe.

Primo loop giusto:

Ogni venerdì, revisiona il documento di strategia di prodotto.

Identifica le sezioni modificate questa settimana.

Elenca le assunzioni non risolte.

Scrivi una nota di revisione strutturata in outputs/strategy-review.md.

Non modificare direttamente il documento di strategia.

→ Pianificazione chiara → Ambito limitato → File di output prevedibile → Limite di autorizzazione sicuro

La differenza non è l'intelligenza. È il design.

Le 5 cose che affondano i loop:

→ Pianificazione prima del test manuale

→ Nessun file di stato — ogni esecuzione riparte da zero

→ Nessuna verifica — il loop si fida di sé stesso

→ Nessuna politica di fallimento — i risultati negativi improvvisano

→ Troppi strumenti troppo presto — il raggio d'esplosione si espande

Risolvi tutte e cinque prima del primo comando /loop.

Aggiungere strumenti e connettori

Una volta che il loop locale è stabile, puoi estenderlo.

GitHub. Slack. Linear. Jira. Log CI.

Ma ogni nuovo strumento espande il raggio d'esplosione.

Segui lo stesso principio: prima leggi, poi abbozza, scrivi solo dopo esecuzioni ripetute e riuscite.

Le regole specifiche per gli strumenti vanno in LOOP_INSTRUCTIONS.md:

1## Politica delle Autorizzazioni per gli Strumenti
2
3### GitHub
4Consentito:
5- Leggere problemi aperti
6- Leggere lo stato delle pull request
7- Leggere lo stato CI
8- Abbozzare un riepilogo in `outputs/github-review.md`
9NON consentito:
10- Inviare commit
11- Unire pull request
12- Chiudere problemi
13- Commentare pubblicamente senza approvazione
14
15### Slack
16Consentito:
17- Abbozzare un messaggio in `outputs/slack-update.md`
18NON consentito:
19- Inviare messaggi
20- Menzionare utenti
21- Pubblicare in canali
22
23### Linear/Jira
24Consentito:
25- Leggere ticket assegnati
26- Abbozzare aggiornamenti suggeriti
27NON consentito:
28- Cambiare stato
29- Chiudere ticket
30- Creare ticket senza approvazione

Se lo strumento non è elencato → fermati e chiedi una revisione umana.

Questo ti protegge dal loop che fa cose a cui non avevi pensato.

Come appare il tuo primo loop completo

Ecco la configurazione completa da zero.

1## Politica delle Autorizzazioni per gli Strumenti
2
3### GitHub
4Consentito:
5- Leggere problemi aperti
6- Leggere lo stato delle pull request
7- Leggere lo stato CI
8- Abbozzare un riepilogo in `outputs/github-review.md`
9NON consentito:
10- Inviare commit
11- Unire pull request
12- Chiudere problemi
13- Commentare pubblicamente senza approvazione
14
15### Slack
16Consentito:
17- Abbozzare un messaggio in `outputs/slack-update.md`
18NON consentito:
19- Inviare messaggi
20- Menzionare utenti
21- Pubblicare in canali
22
23### Linear/Jira
24Consentito:
25- Leggere ticket assegnati
26- Abbozzare aggiornamenti suggeriti
27NON consentito:
28- Cambiare stato
29- Chiudere ticket
30- Creare ticket senza approvazione

Poi riempi ogni file (usa i template qui sopra).

Poi esegui manualmente:

1Esegui il loop di revisione progetto giornaliero per questo spazio di lavoro.
2
3Segui esattamente `LOOP_INSTRUCTIONS.md`.
4Prima di agire, leggi TASK.md, PROGRESS.md,
5e LOOP_INSTRUCTIONS.md.
6Scrivi la revisione giornaliera in `outputs/daily-review.md`.
7Aggiorna `PROGRESS.md` prima di fermarti.
8Esegui la checklist di verifica.
9Non modificare alcun file tranne
10`outputs/daily-review.md` e `PROGRESS.md`.

Poi verifica:

1Esegui un passaggio di verifica.
2Controlla rispetto alla Checklist di Verifica in
3`LOOP_INSTRUCTIONS.md`.
4Riporta quali controlli sono passati, quali sono falliti,
5quali file sono stati modificati, se è richiesta una revisione umana.
6Non modificare alcun file.

Esegui 3-5 volte manualmente con piccole modifiche allo spazio di lavoro.

Poi pianifica:

1/loop 24h Esegui il loop di revisione progetto giornaliero...
2[stesso prompt di quello manuale, preceduto da /loop 24h]

Revisiona la prima settimana di output pianificati prima di fidarti.

Questo è il sistema completo.

Il cambiamento che cambia tutto

Prima dei loop:

→ Scrivevi un prompt

→ Claude rispondeva

→ Domani scrivevi lo stesso prompt di nuovo

→ Claude non aveva memoria di ieri

→ Tenevi traccia manualmente di cosa era cambiato

→ Tutto si resettava con ogni sessione

Dopo i loop:

→ TASK.md definisce l'obiettivo una volta

→ PROGRESS.md porta la memoria tra le esecuzioni

→ LOOP_INSTRUCTIONS.md controlla il comportamento

→ Claude legge, agisce, verifica, aggiorna, si ferma

→ Domani continua da dove si era interrotto

→ Tu revisioni gli output, non i prompt

Il collo di bottiglia si sposta dalla generazione del lavoro alla revisione del lavoro.

Questa è la vera leva.

Non stai facendo a Claude domande migliori.

Stai progettando un sistema che continua a funzionare senza di te.

10 loop che puoi costruire questa settimana

→ Revisione progetto giornaliera — legge lo spazio di lavoro, scrive un riepilogo

→ Estrattore di follow-up da riunioni — trasforma gli appunti in elementi d'azione

→ Pianificatore di pulizia cartelle — organizza, propone, non tocca

→ Triage fallimenti CI — legge i log, classifica i fallimenti, abbozza un'indagine

→ Riassuntore problemi GitHub — legge i problemi aperti, li raggruppa per tema

→ Assistente revisione PR — legge il diff, segnala potenziali problemi

→ Loop di ricerca per newsletter — raccoglie fonti, abbozza riepiloghi

→ Trovatore di lacune nella documentazione — legge i documenti, segnala sezioni mancanti

→ Bozza di standup giornaliero — legge PROGRESS.md, scrive lo standup

→ Loop di retrospettiva settimanale — revisiona la settimana, identifica modelli

Ognuno di questi inizia con lo stesso sistema a 4 file.

L'unica cosa che cambia sono TASK.md e LOOP_INSTRUCTIONS.md.

Se questo è stato utile:

→ Ripubblica per condividerlo con ogni sviluppatore che usa Claude

→ Segui @sairahul1 per altri sistemi che funzionano senza di te

→ Aggiungi questo ai segnalibri — i template sono pronti per essere copiati e incollati

Iscriviti a theaibuilders.co per altri articoli interessanti come questo

Scrivo di AI, costruzione di prodotti e sistemi di automazione.