Um loop de evento dispara quando algo acontece numa ferramenta que você conectou. Sem cadência, sem ritual de atribuição, sem ninguém digitando um prompt: um pull request é aberto e o review já está em andamento antes de alguém trocar de aba.
A instrução dele é orientação permanente sobreposta ao que o evento já carrega. O goblin recebe o merge request ou a issue como contexto automaticamente; sua instrução diz o que você quer feito a respeito.
Os eventos em que você pode criar um loop
| Evento | Origem | Dispara quando |
|---|---|---|
| Merge request aberto | GitLab | Um MR é aberto, reaberto ou atualizado com novos commits |
| Issue atribuída | GitLab | Uma issue é atribuída ao bot @taskgoblin |
| Pull request aberto | GitHub | Um PR é aberto, reaberto ou atualizado com novos commits |
| Issue com label | GitHub | A label taskgoblin é adicionada a uma issue |
| Issue atribuída | Linear | Uma issue é atribuída ao agente TaskGoblin |
| Issue atribuída | Jira | Uma issue é atribuída à conta do TaskGoblin |
Como os eventos de "abertura" também cobrem atualizações, um loop de review reconcilia em vez de repetir: numa segunda passada ele lê os apontamentos que deixou antes, resolve os que você já corrigiu e só publica o que é realmente novo.
Os loops que você já tem
Você não começa com uma página em branco. No momento em que um provedor passa a existir para sua organização, o TaskGoblin instala os loops padrão dele:
- GitLab — Revisar merge requests e Trabalhar em issues atribuídas.
- GitHub — Revisar pull requests e Trabalhar em issues com label.
- Linear — Trabalhar em issues atribuídas.
- Jira — Trabalhar em issues atribuídas.
Eles reproduzem o que as pessoas esperam de um agente de código recém-instalado. A diferença é que são seus: loops de verdade na sua página de Loops, com instruções que você pode ler e mudar.
A instalação acontece uma única vez, para sempre. Apague um loop padrão e ele fica apagado — reconectar o provedor não o traz de volta silenciosamente.
Reescrever a instrução é justamente o ponto
A instrução de review padrão pede correção, segurança e manutenibilidade, e manda o goblin ficar calado quando a mudança está sólida. É uma posição inicial razoável, não uma política da qual você não pode sair. Os times costumam estreitá-la ou ampliá-la:
- "Aponte só problemas de segurança e riscos de perda de dados. Mais nada."
- "Seja rigoroso com cobertura de testes — toda mudança de comportamento precisa de um teste; diga se falta."
- "Verifique também se todo endpoint novo passa pelo nosso middleware de rate limiting."
A instrução é texto livre, então ela consegue codificar o que um linter não consegue: as convenções de vocês, os incidentes passados, o erro que este time insiste em repetir.
O padrão, e uma versão endurecida dele
Isto é o que vem de fábrica:
Revise este merge request. Foque em correção, segurança e manutenibilidade — aponte problemas reais, não detalhes de estilo que um linter pegaria. Deixe comentários inline só onde eles agregam valor, mantenha-os específicos e acionáveis, e fique em silêncio quando a mudança estiver sólida.
É deliberadamente contido, porque um revisor que comenta tudo acaba silenciado. E aqui está o mesmo loop depois de um time conviver com ele por um mês e passar por um incidente:
Revise este merge request quanto a correção, segurança e manutenibilidade. Aponte problemas reais, não detalhes de estilo.
Além disso, verifique sempre: toda mudança de comportamento tem teste; nenhum endpoint novo sobe sem o nosso middleware de rate limiting; nenhuma migration edita uma migration existente; nada loga o corpo inteiro de uma requisição. Levante esses casos como críticos mesmo que o resto da mudança esteja bom.
Se o MR passar de 400 linhas, diga isso no resumo e revise primeiro os arquivos de maior risco em vez de passar os olhos por tudo. Fique em silêncio quando a mudança estiver sólida.
Nada da segunda versão é exótico — é conhecimento institucional que antes morava numa wiki que ninguém abria, agora colado ao momento em que importa. É essa a diferença entre um loop que você herdou e um loop que é seu.
O interruptor
Esta parte vale ler duas vezes, porque explica um comportamento que de outra forma pareceria bug.
Um evento sujeito a loop sem nenhum loop ativo correspondente não inicia execução nenhuma. Pause seu loop de review e os merge requests param de ser revisados. Apague e o mesmo. O TaskGoblin continua aceitando o webhook — ele simplesmente não tem instrução permanente sobre a qual agir, então nenhum goblin acorda e nada é cobrado.
Esse é o preço de o comportamento ser seu em vez de imposto a você. Se o review automático parou, o primeiro lugar para olhar é se o loop dele ainda está ativo.
O que nunca é filtrado por loop
Pedidos humanos explícitos sempre rodam, exista ou não um loop:
@taskgoblinmencionado num merge request, pull request ou comentário de issue- Uma mensagem ou menção no Slack ou Microsoft Teams
- Um comentário de acompanhamento numa issue do Linear que o goblin já está tocando
- Uma menção num comentário de issue do Jira
- Responder
@taskgoblin fixa um dos próprios comentários de review dele
Se uma pessoa pediu diretamente, um goblin responde. Loops governam o trabalho não solicitado, e só ele.
Quando vários loops combinam
Nada impede você de rodar mais de um loop no mesmo evento — um loop de review geral mais um mais rígido para segurança, digamos. Quando um evento combina com vários, o goblin recebe todas as instruções candidatas e julga qual se aplica, registrando a escolha na execução para o histórico continuar honesto. O trabalho ainda acontece como uma única execução: loops não se multiplicam em reviews duplicados num mesmo merge request.
Para onde ir agora
- Loops agendados — o outro tipo de gatilho, para o trabalho que nenhum evento anuncia.
- Conecte suas integrações — em quais provedores você pode criar loops e o que cada um libera.
- Execuções pontuais — os pedidos diretos que passam por cima dos loops.