Voltar
Não faça um humano fazer o que a IA faz muito bem

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

Avalie este artigo:
Categoria
CEVIU Web Dev
Publicado
10 de novembro de 2026
Editoria
CEVIU Web Dev

Quer receber mais sobre CEVIU Web Dev?

Conteúdo curado diariamente, direto no seu e-mail.

Conteúdo curado diariamenteDiversas categoriasCancele quando quiser