Um bot autônomo para GitHub que sabe a hora de não agir
A receita de agente para GitHub do cookbook liga triagem, revisão de PR e correção de bugs ao GitHub Actions, rodando OpenCode com Muse Spark. As lições mais valiosas estão nos guardrails.
O que o bot faz
A receita monta um bot autônomo no GitHub Actions com quatro funções: triagem de issues, revisão de pull requests, detecção de “AI slop” e abertura de PRs corrigindo bugs — tudo rodando no OpenCode com o Muse Spark como modelo, graças à compatibilidade drop-in da Model API com CLIs de agente já existentes. E tudo executa dentro do Actions do seu próprio repositório, não na infraestrutura de terceiros.
Contenção como requisito de design
O que separa essa receita de um projeto ingênuo de “plugar um LLM em webhooks” é o quanto dela trata de não agir. O agente de revisão carrega uma lista explícita de “NOT slop” — critérios de mudanças que ele não deve sinalizar, para não gritar “lobo!” diante de padrões legítimos. A triagem nunca fecha issues; isso continua sendo decisão humana. O agente de correção de bugs não abre PR nenhum se não conseguir reproduzir o bug antes. O enquadramento da Meta é direto: disparar demais é tratado como modo de falha, não como detalhe.
Há também uma disciplina de citação: a função de perguntas e respostas só pode responder a partir dos arquivos do repositório, precisa anexar citação de arquivo e seção a cada afirmação, e deve se recusar a inventar quando a resposta não está no repo. Para um bot que fala em nome do seu projeto em threads públicas, “fundamentado ou calado” é a única política defensável.
AGENTS.md: um arquivo para governar a frota
Todo agente da receita carrega automaticamente um AGENTS.md compartilhado com o contexto do repositório — assim os agentes não precisam adivinhar convenções — e as regras de segurança que todos herdam. A Meta o chama de arquivo mais importante para adaptar ao seu próprio projeto: a versão que vem pronta é um exemplo trabalhado para uma stack Python/pytest/uv, feita para ser reescrita para a sua, mantendo a seção SECURITY intocada.
Lance em fases, conquiste o direito de escrever
O guia de implantação é uma escada de confiança em quatro fases. Fase um: revisão de PR e triagem, somente leitura — valide a qualidade com tráfego real e raio de dano zero. Fase dois: comandos explícitos /oc, para que os mantenedores invoquem o trabalho do agente de forma deliberada. Fase três: correção automática de bugs, controlada por label. Fase quatro: endurecimento — proteção de branch, CODEOWNERS, gates de CI. Acesso de escrita se conquista com histórico, nunca se concede no primeiro dia. É a mesma filosofia da história de auditabilidade do próprio Muse Code: a autonomia só cresce na velocidade em que a verificação cresce junto.
Como a Meta validou tudo isso
Um detalhe que vale copiar: a receita foi validada rodando os agentes reais em modo headless contra cenários roteirizados de issues e PRs — reconstruindo o prompt da Action com um gh falso no PATH, para que nada tocasse um repositório de verdade — e depois lendo o que eles produziram. Teste seu bot como você testaria qualquer automação não confiável: dentro de um vidro, antes de encostar em produção. A receita executável está no cookbook, na seção de casos de uso.