Un bot GitHub autonome qui sait surtout quand ne rien faire
La recette GitHub du cookbook branche triage, revue de PR et correction de bugs sur GitHub Actions, avec OpenCode et Muse Spark. Mais sa vraie leçon, ce sont les garde-fous.
Ce que fait le bot
La recette construit un bot GitHub Actions autonome avec quatre missions : triage des issues, revue de pull requests, détection de « slop » généré par IA, et PRs de correction de bugs — le tout tournant sur OpenCode avec Muse Spark comme modèle, grâce à la compatibilité directe du Model API avec les CLI d’agents existants. Tout s’exécute dans les Actions de ton propre dépôt, pas sur l’infrastructure de quelqu’un d’autre.
La retenue comme exigence de conception
Ce qui distingue cette recette d’un bricolage naïf du genre « je branche un LLM sur des webhooks », c’est la part consacrée à ne pas agir. L’agent de revue embarque une liste explicite de critères « PAS du slop » — des motifs qu’il a interdiction de signaler, pour ne pas crier au loup sur du code parfaitement légitime. Le triage ne ferme jamais une issue : ça reste une décision humaine. L’agent de correction n’ouvre aucune PR s’il n’arrive pas d’abord à reproduire le bug. Meta est catégorique sur ce point : le sur-déclenchement est traité comme un mode de défaillance, pas comme un détail cosmétique.
Il y a aussi une discipline de citation : la fonction Q&A ne peut répondre qu’à partir des fichiers du dépôt, doit accompagner chaque affirmation d’une citation fichier + section, et refuser d’inventer quand la réponse n’est pas dans le dépôt. Pour un bot qui parle au nom de ton projet dans des fils publics, « sourcé ou silencieux » est la seule politique défendable.
AGENTS.md : un fichier pour les gouverner tous
Chaque agent de la recette charge automatiquement un AGENTS.md partagé qui porte le contexte du dépôt — pour que les agents ne devinent pas les conventions — ainsi que les règles de sécurité dont ils héritent tous. Meta le présente comme le fichier le plus important à adapter à ton propre projet : la version livrée est un exemple travaillé pour une stack Python/pytest/uv, à réécrire pour la tienne en gardant la section SECURITY mot pour mot.
Déployer par phases, mériter les droits d’écriture
Le guide de déploiement est une échelle de confiance en quatre phases. Phase un : revue de PR et triage, en lecture seule — tu valides la qualité sur du trafic réel avec un rayon d’impact nul. Phase deux : des commandes /oc explicites, pour que les mainteneurs déclenchent le travail de l’agent volontairement. Phase trois : correction automatique de bugs, verrouillée derrière un label. Phase quatre : durcissement — protection de branches, CODEOWNERS, gates de CI. Les droits d’écriture se méritent par un historique de résultats, jamais accordés au jour un. C’est exactement la même philosophie que le récit d’auditabilité de Muse Code : l’autonomie ne grandit qu’au rythme de la vérification.
Comment Meta l’a validé
Un détail à copier sans hésiter : la recette a été validée en pilotant les vrais agents en mode headless contre des scénarios d’issues et de PRs scriptés — le prompt de l’Action reconstruit avec un faux gh sur le PATH, pour que rien ne touche un dépôt réel — puis en lisant ce qu’ils produisaient. Teste ton bot comme tu testerais n’importe quelle automatisation non fiable : dans un bocal, avant qu’il ne rencontre la production. La recette exécutable est dans le cookbook, rubrique cas d’usage.