Routine di Claude Code: esegui il tuo agente di coding a orario nel cloud

Le tre parti svolgono ciascuna un compito specifico:

• Prompt. La parte più importante perché la routine gira senza la tua approvazione a ogni passaggio. Il prompt deve includere l’intera attività e la sua definizione di completamento.
• Repository. Claude li clona all’inizio di ogni esecuzione e lavora al loro interno.
• Connettori. Le integrazioni di claude.ai sul tuo account, come Slack o Linear, da cui la routine può leggere e su cui può scrivere durante l’esecuzione. Una routine che smista il supporto potrebbe leggere un canale Slack e creare issue in Linear.

I connettori per le routine si aggiungono sulla piattaforma claude.ai, e lo stesso vale per i server MCP. Le configurazioni locali non vengono trasferite.

Una routine può essere avviata in tre modi: secondo una pianificazione, tramite una chiamata API o tramite un evento GitHub. Una singola routine può combinarli tutti e tre.

Routine vs /loop

C’è una differenza tra /loop e /schedule perché risolvono problemi diversi.

Un’attività /loop vive nella tua sessione corrente. Si attiva solo mentre Claude Code è in esecuzione e inattivo sulla tua macchina, e chiudere il terminale la interrompe. Questo la rende utile per fare polling di una build che stai monitorando in questo momento.

Per maggiori informazioni su /loop e altri comandi importanti, ti consiglio di leggere il nostro tutorial Claude Code Terminal.

Una routine gira nel cloud e sopravvive indipendentemente da qualsiasi session:

C’è anche una terza opzione locale. Le attività pianificate desktop girano sul tuo computer, per lavori che hanno bisogno dei tuoi file e strumenti locali. Girano solo mentre la macchina è attiva, ma non richiedono che l’app Claude sia aperta.

La routine che costruiremo

Il modello mentale è chiaro. Ora ti serve qualcosa su cui far lavorare una routine. Per questo tutorial, abbiamo creato pr-review-demo, un piccolo progetto Python con una pull request aperta.

Contiene un pacchetto cartlib che gestisce un carrello: memorizza i prezzi in centesimi come interi, applica sconti per membri e quantità e aggiunge l’imposta sulle vendite statale per arrivare al totale finale. Il pacchetto sul branch principale è corretto.

La pull request aperta aggiunge un buono di spedizione gratuita e contiene un bug reale inserito apposta. È una mancata corrispondenza di unità tra file diversi, invisibile in un singolo file e visibile solo tracciando il valore tra due file. Questo dà alla routine qualcosa di concreto da fare per il resto del tutorial.

Forka il repository per seguire con una tua copia. È usa e getta, e i pattern si trasferiscono a qualsiasi repository a cui punti una routine.

Prerequisiti per seguire

Ti serve un account claude.ai con un piano Pro, Max, Team o Enterprise e Claude Code sul web abilitato. Le routine si trovano su claude.ai/code/routines.

Il comando /schedule si autentica con il login del tuo abbonamento claude.ai, non con una chiave API Anthropic o l’autenticazione Bedrock, Vertex o Foundry. Richiede anche una CLI recente, quindi esegui claude update se la tua è vecchia.

Ci sono anche due prerequisiti separati per GitHub. Primo, /web-setup concede l’accesso al clone, necessario alla routine pianificata. Secondo, l’app GitHub di Claude, installata separatamente, abilita il trigger GitHub trattato più avanti.

Creare routine di Claude Code con /schedule

Con un repository a cui puntare, crea la routine dalla CLI. Esegui /schedule in qualsiasi sessione. Puoi passare direttamente una descrizione:

/schedule daily PR review at 9 am

Claude ti guida attraverso gli stessi campi raccolti dal modulo web: nome, prompt, repository, ambiente, connettori e pianificazione. Conferma la pianificazione nel tuo fuso orario locale e la converte per te, così le 9 diventino l’espressione cron corretta senza che tu debba scriverla.

Se il tuo account non ha ancora una connessione a GitHub, Claude ti chiede di eseguire /web-setup. Eseguilo, poi esegui di nuovo /schedule per riprendere da dove avevi lasciato.

Scrivere un prompt che gira senza di te

Il prompt è ciò che determina se questa routine ha successo o fallisce.

Una sessione normale è una conversazione, quindi puoi correggere Claude man mano. Una routine non ha nessuno che la corregga. Parte a freddo, arriva alla fine e non può fare domande di chiarimento. Il prompt deve indicare l’attività, il repository e cosa significa un’esecuzione completata.

Confronta questi due. Il primo lascia troppo non detto:

Review the open PR.

Non indica un repository o i criteri di revisione, non ha un posto dove lasciare commenti e non definisce il completamento. Un’esecuzione a freddo non può colmare queste lacune. Il secondo prompt risponde a tutto:

Review the open pull request in pr-review-demo. The cartlib package works entirely in integer cents. Read the checkout flow and the values it pulls from config.py, and check that every amount stays in cents end to end. If any value is mixed in using the wrong unit, leave an inline comment on that line explaining the error and its effect on the customer's total. Then, post a summary comment stating whether the PR is safe to merge.

Quel prompt indica il repository e stabilisce l’invariante che il codice deve rispettare: ogni importo in centesimi. Indica i due file rilevanti e definisce il completamento come un commento inline più un giudizio di merge. Questo dà all’esecuzione un obiettivo raggiungibile in autonomia. Incollalo quando /schedule chiede cosa deve fare l’agente.

Tutti i tuoi connettori sono inclusi per impostazione predefinita, quindi una routine nuova può già raggiungere tutto ciò a cui è collegato il tuo account. Va bene per ora, e una sezione successiva li ridurrà.

Quando concludi il flusso, Claude salva la routine e conferma che è attiva, con il suo repository, la pianificazione, il modello e l’ora della prossima esecuzione.

La routine appare anche nell’elenco su claude.ai/code/routines. Apri la sua pagina di dettaglio per vedere tutto in un unico posto. Include stato, repository, pianificazione, connettori, il prompt completo e un pulsante Esegui ora.

Clicca su Esegui ora per avviarla subito, invece di aspettare le 9.

Leggere l’esecuzione

L’esecuzione parte da un clone pulito del tuo repository, prelevato dal branch predefinito. Qualsiasi cosa tu abbia fatto commit è presente. Qualsiasi cosa tu abbia configurato solo sulla tua macchina non lo è, quindi la routine vede il repo come lo vedrebbero i tuoi colleghi.

Una volta conclusa, l’elenco delle esecuzioni mostra uno stato verde. Quel verde significa che la sessione è stata eseguita ed è uscita senza errori di infrastruttura. Ma non significa che l’attività nel tuo prompt sia riuscita. Tre tipi di fallimento si nascondono dietro una spunta verde e compaiono solo nel transcript:

• Una richiesta di rete bloccata dall’ambiente.
• Un tool di un connettore che la routine si aspettava, ma a cui non ha potuto accedere.
• Un fallimento a livello di attività, in cui l’esecuzione è terminata correttamente ma ha fatto la cosa sbagliata.

Quindi apri l’esecuzione per confermarla. Clicca su qualsiasi esecuzione per leggerla come una sessione completa, dove puoi vedere cosa ha fatto Claude, rivedere il diff, aprire una pull request o continuare la conversazione.

Sul repo demo, il transcript mostra la scoperta. Claude legge checkout.py e trova che al coupon è assegnato 5 invece di 500. Spiega che questo applica 5 $ come 5 centesimi, facendo pagare al cliente 4,95 $ in più per ordine, e indica la correzione in una riga. Poi pubblica la review sulla PR tramite il connettore GitHub.

Gestire le routine di Claude Code dalla CLI

Una volta che una routine esiste, la gestisci con lo stesso comando. Esegui /schedule list per vederle tutte, /schedule update per modificarne una e /schedule run per avviarne una subito.

I preset di pianificazione sono oraria, giornaliera, giorni feriali e settimanale. Per un intervallo personalizzato, ad esempio ogni 2 ore o il primo di ogni mese, scegli prima il preset più vicino. Poi esegui /schedule update per impostare direttamente un’espressione cron. L’intervallo minimo è 1 ora, e qualsiasi valore più rapido viene rifiutato.

Le routine contano anche sul limite giornaliero di esecuzioni del tuo account, e durante l’anteprima di ricerca, gli eventi GitHub hanno limiti orari. Gli eventi oltre il limite vengono scartati, non accodati. I numeri attuali variano in base al piano e compaiono su claude.ai/code/routines.

La CLI crea solo routine pianificate. Per aggiungere un trigger GitHub o API, modifica la routine nell’app web.

Avviare le routine di Claude Code da GitHub e HTTP

La pianificazione avvia la tua routine a orario. Altri due trigger consentono a GitHub o ai tuoi sistemi di avviare la stessa routine. Una routine di revisione PR può girare di notte, reagire a ogni nuova PR e partire da uno script di deploy, tutto insieme.

Aggiungi entrambi modificando la routine su claude.ai/code/routines.

Reagire alle pull request con un trigger GitHub

Il trigger GitHub richiede l’App GitHub di Claude installata sul repository a cui vuoi iscriverti. Se l’App manca, la configurazione del trigger ti invita a installarla. Nota che /web-setup visto prima concede solo l’accesso al clone. Non installa l’App né consegna webhook, quindi eseguirlo non copre questo passaggio.

Una volta installata l’App, aggiungi il trigger e scegli un evento. Gli eventi rientrano in due categorie, pull request e release, e selezioni un’azione specifica all’interno di una. L’interfaccia mostra le più comuni come preset, ad esempio PR aperta, PR unita e Release pubblicata, oltre a un’opzione Personalizzata per le altre.

Poi restringi con filtri. Per le pull request, puoi filtrare per autore, titolo, testo, branch di base, branch di origine, etichette, bozza e unita. Tutte le condizioni devono corrispondere perché la routine si avvii.

L’operatore matches regex testa l’intero campo, non una sottostringa. Per far corrispondere qualsiasi titolo che contenga hotfix, scrivi .*hotfix.*. Un semplice hotfix corrisponde solo a un titolo che è esattamente quello, e nient’altro.

Il trigger GitHub impostato per attivarsi su una nuova pull request, filtrato sul branch main e un autore specifico.

Per il repo demo, imposta l’evento su apertura di una pull request e lascia i filtri aperti. Ora ogni nuova PR avvia la revisione che hai scritto prima, senza nessuno al terminale. Traccia l’unità del coupon tra i file, lascia un commento inline sul bug e pubblica un verdetto di merge. 

Ogni evento corrispondente avvia la propria sessione, quindi due PR di seguito producono due esecuzioni indipendenti.

Attivare una routine via HTTP

Il trigger API consente ai tuoi strumenti di avviare una routine. Scegli API sotto il selettore di trigger e clicca su Genera token. Il token viene mostrato una volta e non può essere recuperato in seguito, quindi salvalo subito nell’archivio segreti del tuo strumento di alerting.

Poi esegui POST sull’endpoint di attivazione della routine con il token e un body text:

curl -X POST https://api.anthropic.com/v1/claude_code/routines/$ROUTINE_ID/fire \
  -H "Authorization: Bearer $ROUTINE_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

Il valore text viene passato come stringa letterale e non viene analizzato, quindi scrivi prosa semplice invece di JSON. L’input strutturato arriva come testo grezzo e la routine lo legge alla lettera. 

L’header anthropic-beta è obbligatorio e l’API è sperimentale, quindi controlla la reference API prima di integrarla nella CI. Da lì, uno strumento di monitoraggio può chiamare questo endpoint su un alert e far aprire alla routine una PR di fix in bozza in autonomia.

Definire l’ambito a cui le routine di Claude Code possono accedere

Una routine gira da sola, quindi prima di puntarne una a un repo reale, limita ciò a cui può accedere. La documentazione inquadra questo come quattro controlli:

• Chi impersona la routine, tramite la tua identità GitHub e i connettori.
• A quali branch può effettuare push.
• Quali connettori può usare.
• Quali host l’ambiente le consente di raggiungere in rete.

Limita ciascuno a ciò di cui la routine ha effettivamente bisogno.

Identità della routine

L’identità viene prima perché è ciò che un collega nota su un repo condiviso. Tutto ciò che una routine fa tramite la tua identità GitHub o i tuoi connettori appare come fatto da te. 

I commit e le pull request riportano il tuo utente GitHub, e i messaggi Slack e i ticket Linear usano i tuoi account collegati.  I colleghi vedono il tuo nome su quei commit e PR, quindi dai ai branch e ai titoli nomi che segnalino che sono stati creati da una routine.

Branch su cui la routine può effettuare push

I branch vengono dopo. Un’esecuzione è una sessione cloud completa senza prompt di autorizzazione, quindi non si ferma a chiedere prima di modificare un file o aprire una pull request. 

La protezione è il branch su cui può scrivere. Per impostazione predefinita, Claude fa push solo su branch con prefisso claude/, il che lo tiene lontano da branch protetti o di lunga durata come main. 

Un’impostazione per repository, Consenti push senza restrizioni ai branch, rimuove tale restrizione. Attivala consapevolmente, solo per un repository che ne ha bisogno.

Connettori che la routine può usare

I connettori sono i più rischiosi dei quattro. Tutti i tuoi connettori claude.ai sono inclusi per impostazione predefinita, e Claude può usare ogni tool di un connettore incluso, incluse le scritture, senza chiedere durante l’esecuzione. 

Quindi riduci l’elenco a ciò che serve alla routine. Una routine di revisione PR ha bisogno di GitHub e poco altro. Un connettore di posta o calendario fuori posto è un accesso di cui la routine non ha utilità, e un prompt injection nascosto in una PR potrebbe rivolgere quell’accesso contro di te.

Accesso di rete

L’accesso di rete è l’ultimo controllo. L’ambiente Predefinito usa un accesso di rete fidato, che raggiunge una allowlist integrata di registry di pacchetti, API dei provider cloud, registry di container e domini comuni di sviluppo, e blocca il resto. 

Una richiesta bloccata fallisce con un 403 e un x-deny-reason: host_not_allowed. Allarga solo quando la routine deve raggiungere i tuoi servizi. Altrimenti, il fallimento è silenzioso e compare nel transcript più che come errore evidente.

Idee per le prossime routine di Claude Code da costruire

Sai creare, avviare e definire l’ambito di una routine. Questi esempi dalla documentazione ufficiale abbinano ogni lavoro al trigger più adatto:

• Code review su misura. Trigger GitHub all’apertura di una PR. Applica la checklist di revisione del tuo team, lascia commenti inline per sicurezza, performance e stile, e aggiunge un riepilogo. È la demo, generalizzata ai tuoi standard reali.
• Manutenzione backlog. Trigger pianificato, ogni sera nei giorni feriali. Legge le issue aperte dall’ultima esecuzione, applica etichette, assegna i proprietari in base all’area di codice a cui ogni issue fa riferimento e pubblica un riepilogo su Slack.
• Verifica del deploy. Trigger API dalla tua pipeline CD dopo ogni deploy in produzione. Esegue smoke check contro la nuova build, analizza i log di errore per regressioni e pubblica un go/no-go sul canale di rilascio.
• Deriva della documentazione. Trigger pianificato, settimanale. Scansiona le PR unite dall’ultima esecuzione, segnala la documentazione che fa riferimento ad API cambiate e apre PR di aggiornamento sul repository della doc.

Le routine sono adatte a lavori non presidiati, ripetibili e legati a un risultato chiaro. Se puoi scrivere i criteri di successo nel prompt, come hai fatto per la review della PR, l’attività è una candidata. I lavori che richiedono giudizio umano in tempo reale non lo sono.

Conclusione

Le routine cambiano come impieghi il tempo sul lavoro ricorrente. Invece di eseguire ogni attività al terminale, la scrivi una volta e rivedi ciò che è già stato eseguito. La review PR che hai costruito si avvia mentre il tuo laptop è chiuso, e tu leggi il verdetto quando sei pronto.

Per approfondire Claude Code, i seguenti tutorial si abbinano bene a questo:

• Best practice di Claude Code per ottenere di più da ogni sessione.
• Scrivere un file CLAUDE.md per dare alle tue routine e sessioni un contesto condiviso.
• Sviluppo guidato dalle specifiche per attività che vale la pena specificare prima di automatizzarle.
• Auto mode e canali per eseguire Claude Code con meno supervisione.