Automazioni di Cursor: guida pratica agli agent sempre attivi per il coding

Il vero collo di bottiglia nello sviluppo software non è più scrivere codice: ormai quasi ogni sviluppatore in un team di qualsiasi dimensione ha almeno un agente che lo aiuta a spedire. Gli agent di coding sono integrati nei flussi di lavoro quotidiani e l’implementazione non è più la parte più lenta del sistema.

Cursor Automations nasce per colmare questo gap. Invece di sollecitare ripetutamente un agente, definisci quando deve agire. Scatta un trigger, le istruzioni guidano cosa deve fare e l’agente esegue in autonomia. Si apre una pull request e viene revisionata. Un bug report arriva su Slack e viene gestito. Parte una schedulazione e si genera un report.

In questo tutorial ti mostrerò come configurare le automazioni di Cursor end-to-end. Creerai due automazioni: una per la revisione dei PR e una per il monitoraggio pianificato della copertura dei test. Lungo il percorso ti spiegherò come strutturare le istruzioni e collegare strumenti e MCP in modo che le automazioni si comportino come ci aspettiamo.

Una nota prima di iniziare. Automations è ancora in sviluppo e la dashboard su cursor.com/automations sta evolvendo. Se un’etichetta di menu o un pulsante è cambiato nel frattempo, la logica sottostante rimane la stessa.

Cosa sono le Cursor Automations?

Le automazioni di Cursor sono un sistema per eseguire automaticamente gli agent cloud di Cursor, attivati da eventi nei tuoi strumenti di sviluppo o da una pianificazione che definisci.

Nella modalità Agent di Cursor, come spiegato nel nostro corso Software Development with Cursor, inizi ogni sessione aprendo una chat e digitando un prompt, e l’agente gira sulla tua macchina locale finché lo accompagni.

Nelle automazioni, il segnale di partenza arriva da un altro punto del tuo stack e l’agente svolge il suo compito in una sandbox cloud senza che tu debba monitorarlo.

Le automazioni includono eventi trigger che ho riassunto nella tabella qui sotto, ma puoi anche impostare trigger personalizzati tramite webhook. Un’automazione può avere più di un trigger ed esegue ogni volta che uno di essi scatta.

Ciascuno di questi tipi di trigger sostituisce un momento della tua giornata in cui altrimenti avresti dovuto accorgerti di qualcosa, passare di contesto alla modalità Agent di Cursor e chiedere aiuto. 

Il trigger della pull request è probabilmente il primo che creerai. Ecco come appare il ciclo di vita di un singolo PR prima e dopo aver aggiunto un’automazione che sorvegli il tuo repository.

Quello che cambia in quella seconda colonna non è la velocità del singolo passo, ma il fatto che la tua attenzione non è più il fattore limitante dell’intero processo.

Come funzionano sotto il cofano le Cursor Automations

Ogni automazione segue la stessa pipeline sotto il cofano. Quando scatta il trigger che hai definito, Cursor avvia una nuova sandbox cloud, clona il tuo repository al suo interno e lancia un agente che segue le tue istruzioni usando gli strumenti configurati, le connessioni MCP e il modello. Quel repository non deve per forza stare su GitHub: anche i repository ospitati su Cursor Origin, il forge Git di Cursor, funzionano con agent cloud e automazioni.

L’agente verifica il proprio output prima di terminare, poi pubblica il risultato dove lo hai configurato, che si tratti di un commento su un PR, un messaggio Slack, un ticket su Linear o l’apertura di una nuova pull request.

Due proprietà definiscono ogni automazione che costruisci:

• La sandbox gira interamente nel cloud di Cursor, non sul tuo laptop. Continua a funzionare anche quando il tuo computer è spento.
• Ogni esecuzione avviene in isolamento. Più automazioni possono girare in parallelo senza interferire tra loro. Cursor ha anche dichiarato che internamente esegue centinaia di automazioni all’ora.

Esiste anche uno strumento di memoria, come mostrato nell’anteprima qui sotto, che consente alla tua automazione di mantenere stato tra le esecuzioni, aspetto che diventa importante più avanti quando costruiremo il monitor della copertura pianificato.

Ci tornerò quando costruirai il monitor di copertura pianificato.

Cursor Automations vs modalità Agent

Se già usi Cursor regolarmente, la domanda chiave è quando usare le automazioni invece della modalità Agent. Io non userei le Automations per task una tantum. Sono pensate per lavoro ripetitivo o che dipende da eventi esterni.

Trovo utile un confronto di come differiscono quando la scelta non è ovvia:

La vedo così: se un task inizia con “ogni volta che” o “sempre quando”, allora appartiene alle Automations.

Per esempio: “Ogni volta che si apre un PR, o quando un bug report arriva in #support, crea un ticket su Linear.” Il trigger è ricorrente e prevedibile.

Se inizia con “adesso devo fare il refactor di questo modulo”, allora appartiene alla modalità Agent. Decidi tu quando è “adesso”.

Se vuoi esplorare Cursor prima di tuffarti nelle automazioni, la nostra guida completa a Cursor 2.0 ti accompagna attraverso l’interfaccia degli Agent, il Composer e il workflow multi-agent con un progetto Python completo.

Accesso alla dashboard delle Automations

La dashboard delle automazioni di Cursor è su cursor.com/automations. Accedi con il tuo account Cursor e atterrerai sulla dashboard principale come mostrato qui sotto:

Vediamo nel dettaglio cosa c’è nella dashboard.

Riquadri riepilogativi o indicatori di stato in alto

I riquadri forniscono un’istantanea della salute di tutto ciò che hai eseguito. Includono:

• Automazioni totali (quante ne hai configurate) 
• Successful (esecuzioni completate, con tasso di successo)
• Failed (esecuzioni con errore)
• Run history (se cliccato, mostra un grafico del volume di esecuzioni nel tempo)

La casella di input per il prompt

Il campo di input è il modo più rapido per creare una nuova automazione senza aprire il modulo completo. Descriviamo il task e Cursor genera la struttura dell’automazione.

Se sei agli inizi, ti consiglio di partire da qui. Definisci cosa vuoi automatizzare, poi scrivi un set strutturato di istruzioni che l’agente seguirà ogni volta che il trigger scatta. 

Dopo aver premuto la freccia, Cursor usa quelle istruzioni per generare l’automazione, precompilando nome, trigger e strumenti richiesti.

Non tratterei queste istruzioni come un prompt normale, ma come una specifica che l’agente esegue ogni volta. Ci tornerò quando ti mostrerò come costruire la tua prima automazione più avanti.

Il toggle mine / team e il pulsante + new automation

Il toggle filtra tra le tue automazioni e quelle del team. 

Il + New apre una pagina di configurazione per impostare una nuova automazione:

Il pulsante + New Automation è l’alternativa più lunga alla casella di prompt inline, se vuoi configurare manualmente da zero trigger, istruzioni e connessioni agli strumenti.

L’elenco delle tue automazioni esistenti

La tabella mostra tutte le automazioni che abbiamo creato, inclusi gli strumenti utilizzati e la cronologia delle esecuzioni.

Cliccando su una qualsiasi si apre la sua pagina delle impostazioni e la cronologia delle esecuzioni:

Sezione con template suggeriti

Sotto l’elenco delle automazioni precedenti trovi una griglia di card template. I template offrono automazioni predefinite che puoi modificare invece di partire da zero.

I template di automazione di Cursor sono il modo più rapido per avviare un’automazione il primo giorno. Se stai costruendo la tua prima automazione, ti suggerisco di verificare se c’è un template che corrisponde a ciò che vuoi automatizzare e partire da lì.

I template possono darti indicazioni su come dovrebbero essere buone istruzioni e quali connessioni a strumenti o MCP ti servono.

Account e considerazioni sui costi

Le automazioni di Cursor girano sull’infrastruttura cloud di Cursor, che richiede l’accesso agli agent cloud, incluso nei piani a pagamento. Ogni esecuzione consuma crediti in base all’uso del modello e al tempo di esecuzione.

Le automazioni supportano tre livelli di visibilità secondo il loro modello di permissions:

• Private: solo tu puoi vederla e i costi sono a tuo carico.
• Team Visible: gli altri possono vedere le tue automazioni e la cronologia, ma i costi restano a tuo carico.
• Team Owned. L’automazione viene addebitata al pool condiviso del team ed è gestita dagli admin del team.

Scegliere il livello giusto è importante perché determina di chi sono i crediti usati dall’automazione a ogni esecuzione. Tieni private le sperimentazioni finché non ti fidi dell’output. Quando un’automazione diventa parte del flusso di lavoro del team, puoi spostarla a livello Team Owned.

L’errore principale è lasciare che un’automazione giri troppo in largo, troppo presto. Se si attiva a ogni push in un repository trafficato, può accumulare rapidamente uso senza che tu te ne accorga. Parti in modo ristretto, lasciala girare per qualche giorno, rivedi quanto spesso scatta, poi decidi se espandere o scalarla.

Costruisci la tua prima automazione con Cursor: revisione automatizzata del codice nei PR

La revisione del codice sui PR è la prima automazione giusta perché il ciclo di feedback è breve e le conseguenze di un’esecuzione sbagliata sono basse. Se l’agente pubblica un commento utile, lo vediamo subito sul PR. Se pubblica qualcosa fuori fuoco, lo ignoriamo e non viene spedito nulla.

Ti guiderò nella creazione della tua prima automazione in cinque passaggi:

1. Collegare il tuo repository GitHub
2. Impostare i trigger GitHub
3. Scrivere le istruzioni per l’agente (con una struttura chiara e cosa evitare)
4. Aggiungere lo strumento di commento su GitHub Pull Request
5. Deploy dell’automazione

Passo 1: Collegare il tuo repository GitHub

Prima che l’agente possa revisionare una pull request, deve avere accesso a un repository. Cursor accede al tuo repository tramite un’integrazione nativa come GitHub App. Senza questa connessione, l’agente dell’automazione non può vedere il tuo codice, leggere i diff dei PR o rispondere con feedback, quindi non funziona nulla.

Se non lo hai ancora fatto:

1. Installa la GitHub App di Cursor sul tuo account o organizzazione GitHub e concedile l’accesso ai repository che vuoi far monitorare alle automazioni.
2. Collega il tuo account GitHub nella dashboard nella scheda Integrations. 

Una volta attiva la connessione, i tuoi repository saranno disponibili quando configuri il trigger dell’automazione.

Passo 2: Impostare i trigger

Dalla dashboard delle automazioni:

1. Clicca + New Automation per iniziare a creare un’automazione.
2. Dai un nome all’automazione. Puoi chiamarla PR Code Review – Open & Push – Comment Only
3. Nella sezione dei trigger, clicca Add trigger e seleziona GitHub. Scegli sia PR opened che PR pushed come eventi trigger.
4. Seleziona il repository di destinazione.

Se hai saltato il passo 1 o è la prima volta che colleghi GitHub alle automazioni di Cursor, ti verrà chiesto di autenticarti. 

Nell’anteprima qui sotto, mostro come configurarlo e selezionare il repository di destinazione una volta completata l’autorizzazione:

Nota: possiamo raggruppare più eventi trigger in un’unica automazione quando le istruzioni non cambiano a seconda dell’evento che è scattato. Ma se la profondità o lo scopo della review cambiano in base all’evento, conviene creare automazioni separate.

Ora l’automazione sa quando eseguire. Il passo successivo è dirle cosa fare.

Passo 3: Scrivere istruzioni efficaci per l’automazione

Le istruzioni sono la leva più importante per ottenere un output utile dalla nostra automazione. L’agente le usa per capire cosa significa “buono”. Istruzioni vaghe portano a risultati incoerenti.

Prima di scrivere le istruzioni, dobbiamo capire cosa stiamo definendo. Non stiamo dando un prompt una tantum. Stiamo impostando un comportamento che l’agente seguirà ogni volta che il trigger scatta. La qualità dell’automazione dipende da quanto chiaramente abbiamo specificato quel comportamento.

Ecco la struttura che consiglierei:

• Definisci il ruolo: imposta prospettiva e tono. Per esempio: “Sei un revisore della sicurezza per le pull request.”
• Definisci l’obiettivo: chiarisci cosa significa successo. Per esempio: “Individua e spiega chiaramente vere vulnerabilità.”
• Definisci l’ambito: rendi chiaro su cosa concentrare l’agente. Per esempio: “Revisiona solo codice aggiunto o modificato.”
• Delinea il workflow: fornisci un approccio chiaro al compito. Per esempio: “Ispeziona le modifiche, traccia gli input e verifica le protezioni.”
• Imposta le esclusioni: indica esplicitamente cosa ignorare per ridurre il rumore.
• Definisci comportamento e output. Come deve agire e come deve apparire il risultato.
• Imposta limiti: cosa non deve mai fare.

Scrivi le istruzioni dell’automazione come scriveresti un runbook: specifiche, ordinate, con criteri di accettazione chiari e limiti espliciti.

Esempio di una buona istruzione

Ecco l’istruzione che ho usato per questa automazione di code review del PR. Puoi copiarla nella tua casella delle istruzioni, ma modificala in base al tuo caso d’uso:

You are a code reviewer for pull requests triggered on PR open and push. Focus on identifying real issues that could introduce bugs, security vulnerabilities, or maintainability problems if merged. Review only added or modified code, and use surrounding context only when required to validate impact.

Check for:
- Logic errors such as incorrect conditions, edge cases, null handling, or wrong return values
- Security issues including injection, XSS, auth flaws, unsafe deserialization, or hardcoded secrets
- Contract changes such as modified APIs, response shapes, or schemas without corresponding updates
- Missing error handling or tests introduced by the change

Ignore style, formatting, naming preferences, and any pre-existing issues not introduced by this PR. Report only concrete findings with evidence from the diff, and post inline comments directly on changed lines. If no issues are found, respond: “Automated review complete: no issues found in this diff.” Do not approve, merge, push, or open PRs.

Ecco l’istruzione nella casella delle istruzioni:

Questo prompt è semplificato, ma segue comunque una struttura chiara e specifica. 

Esempio di una cattiva istruzione

Evita istruzioni vaghe come:

Review this PR and give feedback on any issues you notice.

Senza struttura, vincoli e priorità, l’agente sarà costretto a indovinare cosa significhi “problemi”, producendo feedback generici e superficiali invece che risultati affidabili.

Passo 4: Aggiungere gli strumenti

Apri il pannello degli strumenti nell’editor dell’automazione. Per questa automazione, andremo nella sezione GitHub e selezioneremo lo strumento Comment on Pull Request. Assicuriamoci che l’approvazione dei PR sia disabilitata, come nell’anteprima qui sotto, così l’automazione può solo commentare, non approvare le modifiche.

Lo strumento Comment on Pull Request consente all’agente di pubblicare i risultati sul PR. Non richiede una connessione separata perché è alimentato dalla stessa GitHub App di Cursor autorizzata nel Passo 1.

Se volessimo inviare l’output ad altri servizi (come pubblicare su Slack), selezioneremmo lo strumento corrispondente o aggiungeremmo una connessione MCP. Per questa automazione, lo strumento di commento è sufficiente.

Passo 5: Deploy e monitoraggio della prima esecuzione

Una volta impostati trigger, istruzioni e strumenti, clicchiamo Create per salvare l’automazione, che apre la pagina delle impostazioni dell’automazione, come puoi vedere sotto:

Dato che abbiamo distribuito l’automazione, dobbiamo attivare un’esecuzione e osservare cosa produce l’agente.

Apri una pull request in bozza nel repository collegato. Questo attiva il trigger PR opened e una nuova voce dovrebbe apparire nella Run history entro pochi secondi, come puoi vedere sotto:

Apri quella run e verifica tre cose:

• Tempo di esecuzione: quanto dura l’esecuzione. Varia in base a dimensioni del diff, modelli e complessità delle istruzioni.
• Chiamate agli strumenti: quali file e strumenti sono stati usati? Se l’agente legge file non correlati, rivedi le istruzioni.
• Output: cosa è stato pubblicato su GitHub. Confrontalo con le tue istruzioni.

Di seguito una panoramica dell’esecuzione della mia automazione. Puoi vedere che è durata sei minuti, ha effettuato alcune azioni e ha pubblicato la review del PR usando lo strumento PostReviewCommentOnPr:

Qui sotto, un commento di esempio che l’agente ha pubblicato sul mio PR:

A volte l’output può essere fuori bersaglio e, quando succede, di solito il problema sta nelle istruzioni. Regoliamo l’istruzione che controlla il comportamento da modificare, facciamo push di un nuovo commit per attivare un’altra esecuzione e rivediamo il risultato.

Per queste prime esecuzioni, è meglio iniziare in modo semplice per tenerle a basso rischio. In questo caso, limitiamo l’automazione ai soli commenti, così possiamo confermare in sicurezza il suo comportamento. Una volta che l’output è coerente, lo portiamo in uso reale e poi connettiamo altri strumenti oltre a GitHub per ampliarne le capacità.

Collegare altri strumenti con MCP

L’automazione di review del PR che abbiamo appena costruito gira su GitHub. Legge il diff e pubblica commenti sulla pull request usando lo strumento GitHub Comment on Pull Request. Ma se vogliamo che l’agente faccia più della revisione del codice, dobbiamo collegare altri strumenti. È qui che entra in gioco il Model Context Protocol (MCP).

MCP è un’interfaccia standard che consente agli agent di usare strumenti esterni senza integrazioni personalizzate. Senza MCP, ogni strumento richiederebbe una propria configurazione e manutenzione. 

Con MCP, una volta collegato uno strumento supportato nel pannello degli strumenti dell’automazione, l’agente può usarlo tramite la stessa interfaccia.

MCP consente alla stessa automazione di fare di più e agire su altri strumenti. La tua automazione di review dei PR già commenta su GitHub. Aggiungi Slack e può pubblicare aggiornamenti su un canale. Aggiungi Linear e può creare ticket. Aggiungi Datadog e può recuperare log. Ogni connessione estende ciò che l’automazione può fare senza cambiarne la logica di base.

Le automazioni di Cursor includono un set integrato di integrazioni MCP come Slack, Linear, ClickUp, Datadog, Notion e altro. Poiché MCP è uno standard aperto, possiamo connettere qualsiasi strumento compatibile allo stesso modo.

Troverai MCP in Tools -> MCP server nella pagina delle impostazioni dell’automazione. Clicca il pulsante + New Connection per sfogliare, quindi installa e collega lo strumento di cui hai bisogno.

Ecco un’anteprima che mostra come aggiungerli:

Nella prossima sezione, ti guiderò su come aggiungere una connessione MCP di Slack all’automazione di review del codice del PR.

Aggiungere una connessione MCP di Slack

GitHub fa leggere e commentare il codice all’automazione. Slack la fa parlare con il team.

Dal pannello Tools, clicca Add Tool o MCP, seleziona MCP Server, poi scegli +New Connection. Nel pannello che si apre, cerca Slack e seleziona il server MCP di Slack. 

Slack è già installato, ma se non lo è, installalo e segui il flusso OAuth per autorizzare il tuo workspace. Una volta connesso, compare nel tuo pannello strumenti, come mostro nella panoramica qui sotto:

Non scegliamo un canale di destinazione durante la configurazione della connessione. MCP fornisce all’agente dell’automazione accesso a livello di workspace a tutti i canali pubblici. Controlliamo esattamente dove pubblica indicando il canale nelle istruzioni, ad esempio: "Invia un messaggio Slack su #pr-alerts se trovi un problema critico."

Nota: Slack MCP funziona solo con canali pubblici e il canale di destinazione deve avere il bot di Cursor invitato prima che l’automazione possa pubblicare. Dopo il flusso OAuth, dovrebbe comparire un bot di Cursor nel tuo workspace Slack. Vai nel canale ed esegui /invite @Cursor per aggiungerlo.

Se non vedi il b@Cursor ot, è possibile che l’autorizzazione non sia andata a buon fine. Vai a dashboard ->  integrations, clicca Manage accanto a Slack e riesegui l’OAuth.

Se vuoi approfondire MCP, il nostro tutorial su FastMCP 2.0 illustra come costruire da zero un server MCP personalizzato e integrarlo in Cursor.

Combinare trigger e strumenti

Con la connessione MCP di Slack attiva, possiamo estendere l’automazione di review del PR. Terremo gli stessi trigger PR di GitHub e lo strumento di commento su PR di GitHub. Ma ora l’agente può anche pubblicare i risultati critici su #pr-alerts tramite il MCP di Slack.

Aggiungi questo blocco alla fine delle istruzioni che abbiamo scritto nel passo 3 quando abbiamo creato la prima automazione:

Additionally:  
If you find any issue at severity high or critical, send a Slack message to #pr-alerts containing: the PR title, the author, a one-sentence description of the most severe finding, the severity label, and a link to the PR. If no high or critical issues are found, do not post to Slack at all.

Quella riga finale conta più di quanto sembri. Senza di essa, #pr-alerts può riempirsi rapidamente di notifiche “tutto ok” e perdere valore. Per me, dire all’agente quando non agire è importante quanto dirgli quando agire.

Qui sotto ci sono gli output di una run di test su un mio repository.

Una vista di un commento che l’agente dell’automazione ha pubblicato all’apertura del PR su GitHub (tramite lo strumento di commento PR di GitHub):

Una vista della notifica Slack che l’agente dell’automazione ha inviato nel mio canale #pr-alerts per la stessa esecuzione tramite la connessione MCP di Slack:

A questo punto, hai un’automazione funzionante che revisiona ogni PR, pubblica commenti su GitHub ed esegue l’escalation dei problemi critici su Slack. Questo è il pattern di base. 

Nella prossima sezione, costruiremo una seconda automazione seguendo lo stesso flusso: un trigger, istruzioni e gli strumenti di cui l’agente ha bisogno per produrre l’output.

Costruire una seconda automazione: monitor pianificato della copertura dei test

L’automazione di review dei PR che abbiamo costruito reagisce agli eventi di GitHub. Le automazioni pianificate funzionano diversamente. Definiamo quando l’agente deve girare ed esso esegue a quell’ora indipendentemente da cosa è accaduto nel repo.

L’automazione che stiamo costruendo qui gira ogni giorno alle 9:00, analizza il codice unito nel branch main nelle ultime 24 ore, identifica le aree con copertura dei test insufficiente e pubblica un riepilogo su #repo-coverage su Slack.

Impostare un trigger cron e lo strumento

Dalla dashboard delle automazioni:

• Clicca + New per creare una nuova automazione.
• Chiamala Daily Coverage Check – Main Branch.

Configura il trigger

• Sotto Triggers, seleziona Scheduled.
• Scegli Every... > Day e imposta l’ora 9:00 AM.
• Se ti serve un formato diverso, ad esempio solo giorni feriali, usa Custom (cron)
• Poiché i trigger programmati non deducono un repository, seleziona il repository di destinazione e il branch (main).

Aggiungi lo strumento Send to Slack

Qui ti presento lo strumento Send to Slack disponibile nelle impostazioni delle automazioni. È diverso dal MCP di Slack usato prima. Lo utilizziamo per inviare messaggi a un canale specifico, mentre il MCP di Slack fornisce accesso a livello di workspace e consente all’agente di pubblicare su qualsiasi canale definito nelle istruzioni.

Per aggiungere lo strumento Send to Slack, selezionalo dalla sezione strumenti e specifica il canale di destinazione per l’output dell’automazione. Ecco come dovrebbe apparire:

Scrivere le istruzioni per un task pianificato

Nell’automazione di review dei PR, l’agente reagisce a una pull request e pubblica feedback. Con le automazioni pianificate, non c’è input in arrivo. L’agente avvia il task da solo, quindi dobbiamo essere chiari su dove iniziare, cosa controllare e cosa pubblicare.

Qui è importante lo strumento di memoria. Il confronto della copertura funziona solo se l’agente conosce i numeri di ieri. Dobbiamo dirgli quale chiave leggere, cosa confrontare e cosa salvare alla fine. Se lo lasciamo poco chiaro, i risultati possono variare tra esecuzioni.

Ecco il set di istruzioni che ho usato:

You are a daily test coverage monitor for this repository. Run every day at 9 AM on the main branch.
Identify PRs merged to main in the last 24 hours.For modified files, check if changed code paths have test coverage.Run tests with coverage:  pytest --cov=src --cov-report=json.Parse the report and record the overall coverage and per-file coverage for modified files.Read yesterday's coverage from memory (daily_coverage_latest: If none exists, post a green status and skip comparison.Compare coverage: If it drops by >1%, post a warning to #repo-coverage Slack Channel with today's value, yesterday's value, delta, and affected files. Otherwise, post a green status with today’s value and delta.Save today’s coverage to memory (daily_coverage_latest).

Qui sotto ti mostro gli output della mia automazione pianificata alle 9:00.

Ecco la panoramica dell’automazione. Nel mio caso, la copertura è rimasta sopra la soglia, quindi ha pubblicato solo uno stato verde nel canale Slack:

E qui il messaggio Slack. Questo è il primo run di copertura, quindi non mi aspettavo molto. Puoi anche vedere che l’esecuzione è stata salvata in memoria come baseline per il prossimo confronto:

Guardando l’esecuzione sopra, spiccano due parti delle istruzioni. 

Primo, definisce sia il percorso di warning sia quello verde. Il percorso verde è necessario. Se definiamo solo cosa succede quando qualcosa non va, l’automazione resta silente quando è tutto a posto. In un canale di monitoraggio, quel silenzio sembra un fallimento. Lo stato verde conferma che l’esecuzione è terminata.

Secondo, la lettura e il salvataggio in memoria sono espliciti. L’agente ha uno strumento di memoria, ma non lo userà in modo affidabile per i confronti se non istruito. Se lo lasciamo implicito, i risultati possono variare tra le esecuzioni. Dobbiamo specificare esattamente quale chiave leggere, cosa confrontare e cosa salvare.

Nell’immagine qui sotto, puoi vedere che l’agente ha salvato la mia automazione:

Nella prossima sezione, tratterò gli errori comuni e le best practice per aiutarti a ottenere di più dalle tue automazioni.

Cursor Automations: errori comuni e best practice

La maggior parte dei problemi con le automazioni deriva da un piccolo insieme di errori prevedibili. Sono facili da evitare una volta che li conosci, ma costosi da debug quando non li conosci.

Errori comuni da evitare

• Istruzioni vaghe: è un errore frequente. Qualsiasi cosa come “rivedi il codice”, “controlla problemi” o “riassumi le modifiche” costringe l’agente a indovinare cosa intendi, portando a output incoerenti. Se una frase ha un verbo senza un oggetto o una condizione chiara, riscrivila prima del deploy.
• Ambito troppo ampio:. Non combinare controlli di sicurezza, stile, performance e copertura dei test in un’unica automazione. Rende più difficile il debug dei fallimenti. Automazioni ristrette sono più facili da comprendere. 
• Saltare la fase di calibrazione: non attivare presto impostazioni come auto-approve o auto-merge. Nelle prime esecuzioni resta almeno in modalità comment-only. Queste run fanno emergere edge case nel tuo codebase. Considera questa fase come validazione prima della produzione.
• Configurazione dei canali Slack: i trigger Slack funzionano solo su canali pubblici; quindi, se un’automazione Slack sembra non fare nulla, controlla la visibilità del canale e assicurati che il bot @Cursor sia invitato in quel canale.

Best practice per automazioni affidabili

• Un solo lavoro per automazione: ogni automazione dovrebbe fare una cosa chiaramente definita. Questo rende più facile isolare i fallimenti e applicare le correzioni.
• Parti da uno stato pulito: fai commit del tuo working tree prima di lasciare che un agente apporti modifiche, così avrai sempre un diff chiaro da confrontare.
• Tratta le prime esecuzioni come calibrazione: aspettati un po’ di rumore all’inizio, rivedi gli output, regola le istruzioni e riesegui finché il comportamento non si stabilizza.
• Usa nomi chiari e descrittivi: nomi come PR Code Review – Open & Push – Comment Only sono più utili di etichette generiche quando ci torni più tardi.
• Rivedi spesso la cronologia delle esecuzioni: nelle prime settimane, questo costruisce intuizione su cosa sia un comportamento normale, rendendo più facile individuare problemi in seguito.

Considerazioni finali

Cursor Automations sposta il coding agentico da un flusso di lavoro interattivo a un sistema guidato da eventi. In modalità Agent di Cursor, apriamo una chat e chiediamo all’agente di revisionare codice, rifattorizzare funzioni o indagare problemi. Nelle automazioni, non avviamo il lavoro direttamente. Trigger come una pull request, un messaggio Slack o una schedulazione avviano automaticamente l’agente, che completa il task in autonomia. Il vero cambiamento è che il lavoro di routine passa da una coda manuale a un sistema che gira in background.

In questo articolo ti ho guidato nella creazione di due automazioni: una review del codice nei PR e un monitor della copertura pianificato. Sono volutamente semplici, ma offrono il punto di partenza giusto perché mostrano come si comporta il sistema senza complessità aggiuntiva. Quando ti sentirai a tuo agio, potrai implementare workflow avanzati.

L’idea centrale è iniziare con un’automazione ristretta, scrivere istruzioni come un runbook, eseguirla in modalità a basso rischio ed espandere solo quando si comporta in modo affidabile. Il valore dipende meno da quante automazioni costruisci e più da quanto è coerente ciascuna.

Per continuare a costruire su quanto visto qui, ecco i prossimi passi consigliati:

• Approfondisci la modalità Agent e il workflow più ampio di Cursor con il nostro corso Software Development with Cursor.
• Scopri le novità di Cursor 3.0.