Cosa cambia davvero con i task attivati da eventi
OpenAI ha documentato il 25 agosto 2026 i task event-triggered: su piani idonei, ChatGPT Work può avviare un task quando si verifica un evento supportato in Gmail, Slack o GitHub. Per GitHub il perimetro riguarda l’attività di una pull request nel repository autorizzato.
Il trigger decide quando partire; il prompt salvato decide che cosa fare a ogni esecuzione. È una distinzione importante: ricevere un evento non autorizza automaticamente a modificare codice, rispondere a un reviewer o fare merge. Queste azioni dipendono dal prompt, dagli strumenti collegati, dai permessi dell’app e dalle regole del workspace.
La prima applicazione utile è quindi un triage di sola lettura: quando arriva nuovo feedback, raccogliere i punti da verificare, collegarli ai file interessati e preparare un piano. La modifica resta un task separato, avviato dopo una decisione umana.
Webhook e calendario non risolvono lo stesso problema
Un task a orario fisso controlla una fonte secondo una cadenza: ogni mattina, ogni ora o a fine giornata. Un task attivato da evento parte invece quando il sistema collegato segnala un cambiamento compatibile con il filtro. Su una pull request evita controlli vuoti e può reagire più vicino al momento in cui arriva una review.
La documentazione indica che uno stesso task può avere più trigger evento, ma non può combinare trigger evento e pianificazione temporale. Inoltre, eventi compatibili arrivati a breve distanza possono essere raggruppati in una sola esecuzione. Non progettare quindi il workflow assumendo una corrispondenza perfetta “un commento, una run”.
Se ti serve un riepilogo periodico indipendente dagli eventi, conserva un task pianificato separato. Se ti serve rispondere al nuovo feedback, usa il trigger della pull request e rendi il prompt idempotente: deve poter leggere lo stato corrente senza duplicare decisioni o azioni.
- Task pianificato
- Parte a una data o secondo una cadenza. È adatto a riepiloghi periodici e controlli che devono avvenire anche senza un nuovo evento.
- Task event-triggered
- Parte quando arriva un evento supportato dall’app collegata. È adatto a triage e follow-up vicini al cambiamento reale.
Quali eventi GitHub puoi restringere
Per le pull request, la documentazione OpenAI elenca filtri per pull request, autore, titolo o label. Puoi scegliere se considerare review, commenti, aggiornamenti dei commit oppure soltanto i merge. Questo rende possibile partire da una regola piccola, per esempio solo il feedback di review sulle PR con una label dedicata.
Il filtro è parte del controllo, non un dettaglio di comodità. “Ogni attività su ogni pull request” produce rumore, consuma esecuzioni e aumenta la probabilità che il task analizzi lavoro che non gli appartiene. Parti da un repository e da un tipo di evento, poi amplia soltanto dopo aver osservato alcune run.
Il collegamento GitHub deve già avere accesso al repository. La disponibilità dipende dal piano e dalle impostazioni del workspace; negli ambienti gestiti un amministratore può controllare il permesso Allow event-triggered scheduled tasks.
- Repository: uno solo nella prima prova.
- Evento: nuovo feedback di review, non ogni attività.
- Filtro: autore, titolo o label quando riduce davvero il rumore.
- Output: riepilogo e piano, senza commenti o modifiche automatiche.
- Stop: nessuna run se repository o permesso non sono disponibili.
Prompt copiabile per un triage read-only
Crea e prova prima il prompt in una normale chat Work con la stessa connessione GitHub. Solo quando il risultato è leggibile e circoscritto trasformalo in task. La documentazione raccomanda di verificare manualmente il prompt e rivedere le prime esecuzioni prima di affidarsi al workflow.
Nel testo separa fatti osservati, interpretazioni e azioni proposte. Chiedi link e riferimenti alla pull request, ma non permettere al task di dichiarare risolto un finding soltanto perché è comparso un nuovo commit.
Quando una pull request del repository <OWNER/REPOSITORY>
con label <LABEL> riceve nuovo feedback di review:
1. Leggi la pull request, il diff corrente e il nuovo feedback.
2. Separa richieste bloccanti, domande e suggerimenti facoltativi.
3. Per ogni punto indica:
- autore e link al commento o alla review;
- file o area coinvolta, se verificabile;
- comportamento richiesto;
- informazione mancante o dubbio da chiarire.
4. Prepara un piano di revisione ordinato per rischio e dipendenze.
5. Segnala feedback duplicato, superato o in conflitto, senza risolverlo
per inferenza.
Non modificare file.
Non pubblicare commenti.
Non approvare o chiudere la pull request.
Non fare merge.
Se non puoi accedere alla PR o al nuovo evento, fermati e spiega
quale fonte o permesso manca.Una prova controllata in sei passaggi
Non iniziare da una pull request urgente o da un repository con dati sensibili. Usa una PR di prova o una modifica a basso rischio, annota lo stato iniziale e prepara un singolo commento di review che sai riconoscere nell’output.
Apri Scheduled per controllare eventi in attesa, esecuzioni e risultato. Se più eventi sono stati raggruppati, il riepilogo deve comunque distinguere i punti nuovi da quelli già presenti. Un buon test verifica provenienza e limiti, non soltanto se il testo “sembra giusto”.
- Collega GitHub e autorizza soltanto il repository necessario alla prova.
- Prova manualmente il prompt read-only su una pull request conosciuta.
- Crea il trigger su un solo tipo di feedback e aggiungi una label dedicata.
- Genera un evento controllato con un commento di review non ambiguo.
- Controlla in Scheduled quale evento ha avviato la run e quali fonti compaiono nel riepilogo.
- Conferma che il task non abbia modificato file, commenti, stato o merge della pull request.
Repository: <OWNER/REPOSITORY>
Pull request: <URL>
Trigger atteso: nuovo feedback di review
Filtro: label <LABEL>
Evento creato: <LINK AL COMMENTO>
Run osservata: <DATA E ORA>
Fonte citata: <LINK>
Punti nuovi riconosciuti: <ELENCO>
Azioni di scrittura: nessuna / <SPIEGA>
Esito: accetta il prompt / correggi / disattiva il taskPermessi minimi e dati non fidati
Commenti, descrizioni e diff della pull request sono dati esterni al prompt salvato. Anche quando provengono dal repository corretto possono contenere istruzioni, testo generato o riferimenti malevoli. Trattali come materiale da analizzare, non come comandi che possono cambiare scope, strumenti o destinazione dell’output.
Limita l’accesso GitHub ai repository necessari e controlla le autorizzazioni mostrate prima di collegare l’app. In un workspace gestito, verifica anche policy e permessi amministrativi. Il task deve fermarsi quando manca una fonte, non cercare lo stesso contenuto in un canale alternativo non dichiarato.
Evita segreti, dati clienti e informazioni personali nel prompt del task. Se il riepilogo deve essere condiviso, minimizza nomi e contenuti non necessari e conserva i link alla fonte per la review autorizzata.
- Il testo della PR è input, non istruzione privilegiata.
- Il repository autorizzato non rende affidabile ogni commento.
- Il task non deve ampliare il proprio scope seguendo link o richieste nel contenuto.
- Nessuna credenziale va inserita nel prompt, nei commenti o nel riepilogo.
- Un accesso mancante deve produrre uno stop esplicito.
Non confonderlo con la code review automatica di Codex
Un task attivato da eventi è un contenitore generale: osserva un evento supportato e applica il prompt salvato. La code review di Codex è invece una funzione specifica per revisionare il diff di una pull request e pubblicare una review GitHub, manualmente con @codex review o automaticamente quando configurata.
Puoi usare entrambe, ma con responsabilità diverse. La code review cerca problemi nel cambiamento; il task event-triggered può raccogliere il feedback di più reviewer, evidenziare conflitti e preparare il prossimo passo. Duplicare la stessa review in due strumenti aumenta rumore senza aggiungere controllo.
Per iniziare, usa il task come segretario della review: riordina il feedback e indica ciò che richiede una decisione. Affida l’eventuale correzione a un task separato con scope, diff e test espliciti.
Checklist prima di usarlo su lavoro reale
- Piano, workspace e repository espongono davvero la funzione.
- Il prompt è stato provato manualmente sulla stessa fonte.
- Trigger e filtri escludono eventi non pertinenti.
- Il risultato distingue fatti, inferenze e decisioni mancanti.
- Commenti e diff non possono ampliare scope o autorizzazioni.
- Le prime run sono state revisionate una per una.
- Esiste un proprietario umano per correggere, mettere in pausa o eliminare il task.
- Le azioni di modifica, commento, approvazione e merge restano fuori dal primo workflow.
Fonti primarie e stato della verifica
La disponibilità dei task attivati da eventi e l’esempio sul feedback alle pull request sono documentati nel digest ufficiale OpenAI del 25 agosto 2026. Tipi di trigger, filtri, raggruppamento degli eventi, superfici disponibili e controlli del workspace provengono dalla guida Scheduled tasks. La distinzione con la review automatica deriva dalla documentazione GitHub di Codex.
La fotografia è aggiornata al 26 agosto 2026. Piani idonei, rollout, permessi del workspace, eventi supportati e interfacce possono cambiare: controlla sempre la documentazione corrente e ciò che il tuo account mostra prima di configurare il workflow.