Nunebot usa prompt reutilizável para abrir PRs de manutenção em vários repositórios
Aprofundamento CEVIU
Aprofundamento
O Nunebot, descrito por John Nunemaker em 29 de outubro de 2026, é só um prompt: um arquivo markdown num repositório git privado chamado brain. Um agente lê o arquivo e percorre os repositórios em ordem de prioridade. Em cada um, cuida dos PRs que abriu antes, escolhe uma mudança de "sim óbvio", constrói num worktree próprio, roda /simplify, /qa e /codex review (no máximo três rodadas), abre um PR com o label nunebot e espera o CI ficar verde. Ele nunca faz merge nem deploy. Quem aprova é o autor.
O truque técnico é manter tudo pequeno. Nunemaker conta que PRs de 3.000 linhas, fruto de ciclos de revisão atrás de zero achados, o travavam. A solução foi rodar o /codex review de novo só nas correções, não na mudança inteira. O corpo do PR segue uma ordem fixa: motivo, o que mudou, prova, performance e compatibilidade, revisão, risco e rollback. A prova inclui teste que falha na main e passa no branch, suíte e linters verdes, a mudança rodando e números de antes e depois. Segundo ele, 46 dos 250 PRs mesclados removeram mais código do que adicionaram, e há 107 regras de gosto registradas em 11 dias.
Por que isso importa
Para quem mantém vários repositórios, a leitura aqui é que o gargalo deixa de ser escrever a mudança e passa a ser revisá-la. O desenho do Nunebot ataca isso: diff pequeno, prova anexada, rollback explícito. Dá para adaptar a ideia sem copiar as ferramentas: um critério claro de "o que merece PR" e um template que force evidência valem mais do que o modelo escolhido.
Perguntas frequentes
O que é o Nunebot?
É um prompt reutilizável, guardado como arquivo markdown num repositório privado. Um agente o executa e abre um pequeno PR de manutenção em cada repositório, seguindo uma ordem de prioridade.
O Nunebot faz merge ou deploy sozinho?
Não. Ele nunca faz merge, deploy nem altera produção. O autor lê o PR e faz o merge, e na maioria dos apps dele o deploy acontece nesse momento.
Como ele evita PRs enormes?
O prompt exige uma mudança de sim óbvio, revisável em minutos e comprovável. Se nada passa nesse critério, ele pula o repositório. Além disso, a segunda rodada do /codex review olha só as correções, com no máximo três rodadas.
Que prova cada PR precisa trazer?
Conforme o caso: teste que falha na main e passa no branch, suíte e linters verdes, a mudança em execução, capturas de tela, números de antes e depois e, em remoções, as buscas que mostram que nada usa o código.
Fontes
- johnnunemaker.comfonte original
- Categoria
- CEVIU Web Dev
- Publicado
- 10 de novembro de 2026
- Editoria
- CEVIU Web Dev

