Pitch: cansei de perder review request no GitHub, então coloquei o GitHub na minha DM

Me chamo Gabriel, e essa é a história de como um "projeto de fim de semana" virou o OctoBot: um bot de Discord open source que me cutuca na DM quando algo no GitHub realmente precisa de mim. Digo "de fim de semana" entre aspas porque, cada vez que eu resolvia um problema, aparecia outro logo atrás — e é essa sequência de paredes na cara que eu quero contar aqui.

Vou começar pela parte chata: eu era péssimo em responder review request.

Não por má vontade. É que eu vivo com PR aberto em um monte de repositório ao mesmo tempo — uns meus, uns da empresa, uns de open source que eu contribuo de vez em quando. E o sininho do GitHub, sinceramente, virou ruído. Ele apita igual pra alguém que deu estrela num repo, pra um comentário numa issue que não me interessa, e pra um "ei, pode revisar meu PR?". Tudo no mesmo balaio. Então eu simplesmente parei de olhar. Abria o GitHub umas duas vezes por dia, no susto, e invariavelmente tinha um review request parado há seis horas me encarando. Alguém do outro lado esperando por mim sem saber que eu nem tinha visto.

O detalhe é que tem uma janela que eu nunca fecho: o Discord. A empresa onde trabalho roda em cima dele — é onde a conversa acontece o dia inteiro. E aí a ideia apareceu meio óbvia: se o Discord é o lugar onde eu de fato estou, por que o GitHub não me cutuca por lá? Só quando é sério. "Te pediram review", "te marcaram", "seu CI quebrou", "seu PR foi aprovado, pode fazer o merge". O resto o "sininho" que fique com ele.

Parecia um projeto de fim de semana. Cada decisão de "beleza, mas como faço isso direito?" me provou o contrário.

Primeira parede: webhook não servia

Meu primeiro instinto foi webhook, claro. É o caminho de manual. Só que webhook do GitHub é configurado por repositório e pede acesso de admin no repo. Aí a coisa desmorona na hora: eu queria ser avisado sobre tudo que a minha conta enxerga — os meus repos, os privados da empresa, os open source alheios — e na esmagadora maioria deles eu não sou admin, nem quero pedir pra ninguém sair instalando bot nos repositórios pra me fazer um favor.

Então virei a chave: em vez de o GitHub me avisar, eu vou perguntar pra ele. Existe a API de notificações do próprio usuário — um clique pra conectar a conta e pronto, ela cobre tudo que aquela conta acessa, público e privado, sem setup nenhum por repo. Resolveu o problema todo de uma vez.

E criou o próximo.

Segunda parede: perguntar toda hora é caro (ou devia ser)

Se eu vou ficar perguntando pro GitHub "tem coisa nova?" mais ou menos de minuto em minuto, pra cada pessoa conectada, isso soa como a receita perfeita pra estourar rate limit e torrar recurso à toa. Fiquei um tempo travado nisso, achando que ia precisar de uma fila mirabolante.

A saída foi mais elegante do que eu merecia: conditional requests. O GitHub devolve um ETag a cada resposta; na próxima vez eu mando esse ETag de volta e, se nada mudou, ele responde 304 Not Modified — sem corpo, e sem contar no rate limit. Ou seja, no caso comum (que é justamente "não tem nada novo"), a checada é quase de graça. Só quando algo de fato mudou é que o trabalho pesado roda: filtrar contra o que você escolheu ouvir, olhar o veredito do review (aprovaram? pediram mudança?), remover o que é a mesma notificação repetida na thread, e só então te chamar na DM. O poller passa 95% do tempo tomando 304 na cara e agradecendo.

A parede mais desconfortável: por que você confiaria em mim?

Aqui eu parei pra pensar de verdade, porque não tem como fugir: pra isso funcionar eu preciso do acesso à sua conta do GitHub. Isso é pedir muito. Se um bot aleatório me pedisse isso, eu fecharia a aba. Então a régua que eu me impus foi: cada decisão sobre esse acesso tem que ser explícita e defensável.

O bot é estritamente read-only — ele lê as suas notificações pra te contar sobre elas e mais nada. Nunca marca como lida, nunca escreve num repo, nunca abre ou fecha coisa nenhuma. Ele observa e avisa, ponto. O seu token fica criptografado com AES-256-GCM, com a chave morando só na variável de ambiente e nunca indo parar num log. O OAuth carrega um state de uso único que morre em dez minutos, então aquele link de autorização não vira arma de CSRF. E de log eu guardo o mínimo do mínimo: ID, status, erro — nunca token, segredo, nem o conteúdo de mensagem.

Mas nada disso vale de verdade se você só tem a minha palavra. Por isso o argumento que fecha tudo é que é open source, MIT. Se você desconfiar de qualquer frase acima, o código inteiro tá lá pra você abrir e me desmentir.

Onde isso tudo mora

Pra quem gosta do detalhe: o bot é TypeScript com discord.js v14, o fluxo de OAuth roda em Fastify, a persistência é better-sqlite3, e a landing é Next.js 16 / React 19 / Tailwind v4. Tudo num monorepo com pnpm workspaces + Turborepo, hospedado na Fly.io.

Usar é rápido: você entra no Discord da comunidade (é isso que te dá um servidor em comum com o bot, pré-requisito pra ele conseguir te mandar DM), roda /link, clica no link e conecta o GitHub. A partir daí ele começa a te cutucar. Dá pra afinar exatamente o que você recebe com /listen-to, ligar um /digest diário de PRs, e se você cansar, /unlink apaga na hora tudo que ele guarda sobre você.

Onde a coisa tá de verdade

Vou ser honesto sobre o estágio: o OctoBot é novo, é projeto pessoal, é gratuito e não tem plano de virar produto pago agora. Funciona e tá em uso, mas ainda é cedo — e é exatamente por isso que eu trouxe ele pra cá antes de qualquer outro lugar. Esse é o público que vive de code review e de notificação de GitHub, então é de vocês que eu mais quero ouvir: o que falta, o que incomoda, e principalmente onde eu decidi errado em alguma das paredes que contei aí em cima.

Crítica ao modelo de segurança, ideia, ou PR — tudo é muito bem-vindo.

• Site: https://octobot.dev?utm_source=tabnews.com.br&utm_medium=pitch
• Código (MIT): https://github.com/gabrielccarvalho/octobot

Valeu por ler até aqui. 🐙