Un bot GitHub autonomo che sa quando stare fermo
La ricetta del cookbook per l'agente GitHub porta triage, review delle PR e bug-fix automatici dentro GitHub Actions, con OpenCode e Muse Spark. Ma la lezione più preziosa sono i guardrail.
Cosa fa il bot
La ricetta costruisce un bot autonomo su GitHub Actions con quattro compiti: triage delle issue, review delle pull request, rilevamento di “AI slop” e apertura di PR di bug-fix. Gira su OpenCode con Muse Spark come modello, sfruttando la compatibilità drop-in del Model API con le CLI agentiche già esistenti. E tutto vive dentro le Actions del tuo repository, non sull’infrastruttura di qualcun altro.
La moderazione come requisito di progetto
Ciò che distingue questa ricetta dal classico progetto ingenuo “collego un LLM ai webhook” è quanta parte del design riguarda il non agire. L’agente di review ha una lista esplicita di “NOT slop”: criteri per le modifiche che non deve segnalare, così da non gridare al lupo davanti a pattern legittimi. Il triage non chiude mai le issue: quella resta una decisione umana. L’agente di bug-fix non apre nessuna PR se prima non riesce a riprodurre il bug. Meta è brutale su questo punto: l’over-triggering è trattato come un vero e proprio failure mode, non come un dettaglio di cortesia.
C’è anche una disciplina delle citazioni: la funzione di Q&A può rispondere solo attingendo ai file del repository, deve allegare a ogni affermazione una citazione con file e sezione, e deve rifiutarsi di inventare quando la risposta nel repo non c’è. Per un bot che parla a nome del tuo progetto in thread pubblici, “fondato sulle fonti o in silenzio” è l’unica politica difendibile.
AGENTS.md: un file per governarli tutti
Ogni agente della ricetta carica automaticamente un AGENTS.md condiviso con il contesto del repository — così nessun agente tira a indovinare sulle convenzioni — e con le regole di sicurezza che tutti ereditano. Meta lo definisce il singolo file più importante da adattare al tuo progetto: la versione fornita è un esempio svolto per uno stack Python/pytest/uv, pensato per essere riscritto sul tuo, mantenendo però la sezione SECURITY parola per parola.
Rollout a fasi: la scrittura si guadagna
La guida al deployment è una scala di fiducia in quattro fasi. Fase uno: review delle PR e triage, in sola lettura — validi la qualità su traffico reale con raggio di danno pari a zero. Fase due: comandi espliciti /oc, così i maintainer invocano il lavoro dell’agente in modo deliberato. Fase tre: bug-fix automatico, ma solo dietro label. Fase quattro: hardening — branch protection, CODEOWNERS, gate di CI. L’accesso in scrittura si guadagna con un track record, non si concede il primo giorno. È la stessa filosofia della storia di auditability di Muse Code: l’autonomia cresce solo alla velocità con cui cresce la verifica.
Come Meta l’ha validato
Un dettaglio che vale la pena copiare: la ricetta è stata validata pilotando i veri agenti in modalità headless contro scenari di issue e PR sceneggiati — ricostruendo il prompt della Action con un finto gh nel PATH, così che nulla toccasse un repository vivo — per poi leggere cosa producevano. Testa il tuo bot come testeresti qualsiasi automazione non fidata: in un barattolo, prima che incontri la produzione. La ricetta eseguibile è nel cookbook, tra gli use case.