Introdução

Pare de escrever prompts para agentes. Comece a projetar loops.

Essa diferença é o produto inteiro. Um prompt te dá uma resposta, uma vez, e só se alguém lembrar de digitá-la. Um loop é um gatilho mais uma instrução: dispara sozinho, faz o trabalho num sandbox isolado na nuvem, abre um merge request que você revisa, anota o que aprendeu e fica pronto para o próximo turno.

Você não abre um aplicativo nem cola código num chat. Você conecta as ferramentas que seu time já usa, e o trabalho passa a acontecer dentro delas.

Um loop é um gatilho e uma instrução

• O gatilho é um evento — um pull request foi aberto, uma issue foi atribuída ao goblin — ou um agendamento, como todo dia útil às 07:00.
• A instrução é linguagem natural, não um DSL. "Revise este merge request quanto a correção e segurança; aponte problemas reais, não detalhes de estilo." Ou: "Procure atualizações seguras de dependências em acme/web e abra um merge request."

Tudo o que o TaskGoblin faz é um destes. O code review automático é um loop de evento em pull request aberto. Atribuir uma issue e receber um merge request é um loop de evento em issue atribuída. A saúde noturna da suíte de testes é um loop agendado às 06:00. Não existe um "recurso de automação" pregado ao lado: loops são a primitiva, e os comportamentos que parecem embutidos são loops que pertencem a você e podem ser reescritos.

Se você for ler só mais uma página, leia Loops.

Você começa com loops já rodando

Entre com GitLab ou GitHub e o TaskGoblin provisiona sua organização, conecta seus repositórios e instala os loops padrão daquele provedor: revisar merge requests, pegar issues atribuídas. Abra um pull request e ele será revisado antes de você ter configurado qualquer coisa.

Esses padrões são loops comuns na sua página de Loops. Leia a instrução, reescreva com suas palavras, pause, apague. O comportamento ser seu é justamente o ponto.

Como um loop realmente se parece

Loops são escritos em linguagem natural. Aqui está um real, da galeria de templates — um guardião noturno da sua suíte de testes:

Gatilho — todo dia às 06:00

Instrução — Clone acme/web e rode a suíte completa na branch padrão. Se algo falhar e a correção for pequena e segura, abra um MR; caso contrário, resuma as falhas. Se tudo passar, não faça nada.

Três frases, e repare no que cabe nelas: onde trabalhar, o que fazer, quando corrigir versus quando escalar e — a linha mais importante de qualquer instrução desassistida — permissão para não fazer nada. É essa última cláusula que faz você receber um merge request nas manhãs em que algo quebrou, e silêncio nas manhãs em que não.

A galeria traz nove para começar: atualizações de dependências, docs desatualizados, entradas de changelog, limpeza de dívida técnica, resumos de atividade, lembretes de MRs parados, cutucões de triagem. Todos editáveis e seus assim que você escolhe um. Veja Loops agendados para o conjunto completo, destrinchado.

Por que os loops rodam na nuvem

Como um goblin roda num sandbox isolado na nuvem e não no notebook de alguém, o trabalho é:

• Assíncrono — entregue a tarefa e feche a máquina.
• Isolado — uma fronteira por organização, e suas credenciais são injetadas em volta do agente, nunca entregues para ele ler.
• Paralelo — cada execução ganha sua própria branch e seu próprio sandbox, então dez loops disparando de uma vez são dez goblins trabalhando, não uma fila.
• Sempre ligado — a manutenção das 03:00 e o review do pull request aberto à meia-noite acontecem sem ninguém acordado.

O que chega no fim de um turno

Uma branch e um merge request, revisados exatamente como os de um colega — ou comentários de review inline, ou uma resposta na thread do Slack onde você perguntou. Nunca um muro de texto que você mesmo tenha que executar, e nunca um commit na sua branch padrão.

Por baixo há um agente de código de verdade (Claude Code, Codex ou Gemini) com uma cópia do seu repositório: lê arquivos, roda comandos e testes, e trabalha o problema como um colaborador faria. Como ele tem identidade própria em cada ferramenta — @taskgoblin no GitLab, Slack e Teams, taskgoblin[bot] no GitHub — o time inteiro pode delegar a ele e o time inteiro enxerga o que ele fez.

Para onde ir agora

Comece aqui

• Início rápido — do login ao seu primeiro pull request revisado e ao seu primeiro loop agendado.
• Loops — a primitiva, e por que ela ganha de um prompt.

Construa seus loops

• Loops de evento — reviews, atribuições e labels; os loops que você já tem e como mudá-los.
• Loops agendados — trabalho recorrente e templates para começar.
• Conecte suas integrações — GitLab, GitHub, Linear, Jira, Slack e Microsoft Teams.
• Execuções pontuais — pedir direto, quando o trabalho é mesmo único.

Entenda a mecânica

• Como uma execução funciona — dentro de um único turno de um loop.
• O sandbox na nuvem — onde seu código roda e como ele fica isolado.
• O cérebro — como uma correção passa a valer para todos os goblins seguintes.

Cobrança

• Preços e créditos — você paga por tempo, não por tokens.
• Traga sua conta de LLM — e pague uma taxa menor.
• Traga seu servidor de sandbox — goblins na sua própria infraestrutura.
• Recarga automática — para loops desassistidos não travarem.