Como criar loops com o Claude Code

A maioria dos fluxos de trabalho do Claude ainda são de uso único.

Você escreve um prompt. O Claude responde. A sessão termina. Amanhã você começa do zero.

Isso funciona bem para tarefas pontuais.

Mas para trabalhos repetitivos — revisões diárias, triagem de CI, monitoramento de projetos, acompanhamento de reuniões — você está reconstruindo o mesmo contexto todos os dias.

Isso não é um fluxo de trabalho. Isso é trabalho manual com pitadas de IA.

A abstração melhor é um loop.

Guarde isto. Você vai usar.

O que realmente é um loop do Claude

Um loop não é "apenas pergunte ao Claude de novo."

Um loop é uma estrutura de fluxo de trabalho repetível em torno do modelo.

Ele define:

→ O que aciona a execução

→ Qual contexto o Claude lê antes de agir

→ O que o Claude pode fazer → Como a saída é verificada

→ Onde o estado é armazenado

→ Quando parar, repetir ou pedir revisão humana

O modelo ainda faz o raciocínio.

O loop fornece a estrutura operacional.

A mudança é importante porque as sessões do Claude são temporárias.

Sem um loop, cada execução começa do zero. Com um loop, o Claude lê o que aconteceu antes e continua a partir daí.

6 partes que todo loop do Claude precisa

Um loop sem estrutura é apenas um prompt que é executado duas vezes.

Aqui estão as 6 partes que fazem um loop realmente funcionar:

→ 1. Acionador

O que inicia a execução.

Comando manual. Temporizador agendado. Alteração de arquivo. Falha de CI. Evento do Git.

→ 2. Contexto

O que o Claude lê antes de agir.

Definição da tarefa. Progresso anterior. Arquivos do projeto. Instruções.

→ 3. Ação

O que o Claude faz.

Escrever um relatório. Elaborar uma correção. Classificar falhas. Atualizar um documento.

→ 4. Verificação

Como você verifica o resultado.

Checklist. Suíte de testes. Seções obrigatórias. Verificação de limite de segurança.

→ 5. Atualização de estado

O que é lembrado para a próxima vez.

PROGRESS.md atualizado. Bloqueios registrados. Próxima execução orientada.

→ 6. Decisão

Parar. Repetir. Ou escalar para humano.

Esse é o loop completo.

E cada etapa é importante.

Pular a verificação → o loop confia cegamente em si mesmo.

Pular o estado → toda execução começa do zero.

Pular a decisão → o loop nunca sabe quando parar.

O sistema de 4 arquivos que faz os loops funcionarem

Você não precisa de infraestrutura.

Você precisa de 4 arquivos e uma pasta.

1my-loop/
2├── TASK.md
3├── LOOP_INSTRUCTIONS.md
4├── PROGRESS.md
5└── outputs/
6    └── daily-review.md

TASK.md — O objetivo. O que este loop está tentando realizar.

LOOP_INSTRUCTIONS.md — O procedimento operacional. Como o Claude deve executar, o que ele pode fazer, como verificar.

PROGRESS.md — A memória. O que aconteceu da última vez, o que está bloqueado, em que a próxima execução deve focar.

outputs/ — Onde o Claude escreve os resultados. Previsível. Inspecionável. Seguro.

É isso.

O Claude lê esses arquivos no início de cada execução. Atualiza-os no final. A próxima execução continua de onde a última parou.

Isso é o que torna os loops diferentes de prompts repetidos.

O estado vive fora do chat.

TASK.md — Defina o objetivo claramente

Este arquivo diz ao Claude para que serve o loop.

Mantenha-o em alto nível. Não coloque detalhes operacionais aqui. Eles vão para LOOP_INSTRUCTIONS.md.

Copie este modelo:

1# Loop de Revisão Diária do Projeto
2
3## Objetivo
4Revisar esta pasta do projeto, resumir o que mudou,
5identificar bloqueios e produzir um breve relatório de revisão diária.
6
7## Saída Esperada
8Cada execução deve produzir ou atualizar:
9- `outputs/daily-review.md`
10- `PROGRESS.md`
11
12## Escopo
13O Claude pode inspecionar arquivos neste espaço de trabalho e escrever
14relatórios na pasta `outputs/`.
15
16O Claude NÃO deve:
17- Modificar arquivos fonte
18- Excluir ou renomear arquivos
19- Enviar mensagens ou abrir tickets

Observe a última seção.

A primeira versão de qualquer loop deve ter regras explícitas de "não fazer".

Isso não é desconfiança do Claude.

Isso é você sendo um bom engenheiro.

PROGRESS.md — A memória do loop

Este é o arquivo mais importante do sistema.

Sem ele, toda execução começa do zero. Com ele, o Claude sabe o que aconteceu e continua a partir daí.

A estrutura que realmente funciona:

1# Progresso do Loop
2
3## Estado Atual
4- Status: Ativo
5- Objetivo principal: Revisão diária do projeto
6- Foco atual: [o que importa agora]
7- Última atualização: [data]
8
9## Última Execução
10- Data:
11- Resumo:
12- Arquivos revisados:
13- Saída produzida:
14
15## Itens em Aberto
16-
17
18## Bloqueios
19-
20
21## Precisa de Revisão Humana
22-
23
24## Próxima Execução Deve
25-
26
27## Decisões Tomadas
28-
29
30## Não Repetir
31-

A seção "Não Repetir" é crítica.

Ela impede que o Claude tente novamente coisas que já falharam.

A seção "Precisa de Revisão Humana" é crítica.

Ela impede que o loop continue silenciosamente quando não deveria.

Duas regras para manter o PROGRESS.md útil:

→ Se o Claude precisar disso para decidir a próxima ação → mantenha em PROGRESS.md → Se você só quiser um registro → mova para outputs/history/

Arquivos de estado que crescem para sempre se tornam inúteis.

Mantenha PROGRESS.md como um painel de controle, não um arquivo morto.

LOOP_INSTRUCTIONS.md — O procedimento operacional

Este arquivo é a camada de controle em torno do Claude.

Ele diz exatamente ao Claude o que ler, o que escrever, o que não tocar e como verificar o resultado antes de parar.

O modelo que funciona:

1# Instruções do Loop
2
3Você está executando um loop de revisão diária do projeto.
4
5## Antes de Começar
61. Leia `TASK.md`
72. Leia `PROGRESS.md`
83. Inspecione a pasta do projeto
94. Identifique o que mudou, o que está incompleto, o que precisa de revisão humana
10
11## O Que Você Deve Fazer
12Escreva uma breve revisão diária em `outputs/daily-review.md` incluindo:
13- Resumo do estado atual
14- Arquivos revisados
15- Mudanças significativas
16- Bloqueios ou perguntas não resolvidas
17- Próximas ações recomendadas
18
19Após escrever, atualize `PROGRESS.md` com:
20- Data desta execução
21- Resumo do que aconteceu
22- Arquivos verificados
23- O que a próxima execução deve fazer
24- Se a revisão humana é necessária
25
26## Regras de Segurança
27- Não exclua arquivos
28- Não renomeie ou mova arquivos
29- Não modifique arquivos fonte
30- Escreva apenas em `outputs/daily-review.md` e `PROGRESS.md`
31- Se não tiver certeza se uma ação é permitida → pare e pergunte
32
33## Checklist de Verificação
34Antes de encerrar a execução, confirme:
35- `outputs/daily-review.md` existe com todas as seções necessárias
36- `PROGRESS.md` foi atualizado
37- Nenhum arquivo fora dos caminhos permitidos foi modificado
38
39## Política de Falha
40Se a verificação falhar:
411. Seção faltando no relatório → corrija uma vez
422. PROGRESS.md não atualizado → atualize uma vez
433. Arquivo proibido modificado → pare imediatamente
444. Mesma verificação falha duas vezes → marque como precisando de revisão humana

Observe a política de falha no final.

A maioria dos loops não tem política de falha.

Então, quando algo dá errado, o Claude improvisa.

É aí que os loops criam problemas.

Defina o caminho de falha explicitamente. Sempre.

Executando seu primeiro loop manualmente

Não agende ainda.

Execute manualmente primeiro.

Abra a pasta no Claude Code ou Claude Desktop/Cowork. Use este prompt:

1Execute o loop de revisão diária do projeto para este espaço de trabalho.
2
3Siga `LOOP_INSTRUCTIONS.md` exatamente.
4
5Antes de agir, leia:
6- `TASK.md`
7- `PROGRESS.md`
8- `LOOP_INSTRUCTIONS.md`
9
10Em seguida, inspecione o espaço de trabalho, escreva a revisão diária em
11`outputs/daily-review.md`, atualize `PROGRESS.md`,
12execute o checklist de verificação e relate o que mudou.
13
14Não modifique nenhum arquivo, exceto
15`outputs/daily-review.md` e `PROGRESS.md`.

Após a execução, verifique duas coisas:

→ outputs/daily-review.md — relatório estruturado com todas as seções

→ PROGRESS.md — estado atualizado, orientação para a próxima execução, sinalizadores de revisão humana

Se ambos estiverem corretos → o loop está funcionando.

Agora execute-o mais 3-5 vezes com pequenas alterações.

Adicione um arquivo de notas. Adicione um bloqueio ao PROGRESS.md. Algo mude no espaço de trabalho.

Cada execução deve captar as mudanças sem começar do zero.

Essa continuidade é o objetivo principal.

Verificação: a parte que a maioria pula

Aqui está o modo de falha sobre o qual ninguém fala.

O Claude executa o loop. Diz que terminou. Atualiza o estado. Para.

Tudo parece bem.

Mas o relatório está faltando seções obrigatórias. Ou PROGRESS.md não foi realmente atualizado. Ou o Claude editou silenciosamente um arquivo que não deveria.

Você só descobre quando algo quebra.

É por isso que a verificação existe.

O loop não deve parar porque o Claude diz que terminou.

Ele para porque uma condição concreta foi verificada.

Uma boa verificação é assim:

Execute uma passagem de verificação para a execução mais recente do loop.

Verifique a saída contra o Checklist de Verificação

em LOOP_INSTRUCTIONS.md.

Relate:

1. Quais verificações passaram
2. Quais verificações falharam
3. Quais arquivos foram modificados
4. Se a execução é segura para aceitar
5. Se a revisão humana é necessária

Não modifique nenhum arquivo durante esta passagem de verificação.

Execute o worker. Depois execute o verificador. Separadamente.

Com o tempo, você pode mesclá-los. Mas durante os primeiros testes, mantenha-os separados.

O verificador precisa de um padrão de aprovação/reprovação.

"Revise isso e me diga se parece bom" NÃO é um verificador.

"Verifique estas 7 condições e marque a execução como aceita somente se todas as 7 passarem" É um verificador.

Agendamento com /loop

O loop está funcionando de forma confiável manualmente.

Agora agende-o.

No Claude Code, use /loop:

1/loop 24h Execute o loop de revisão diária do projeto para este espaço de trabalho.
2
3Siga `LOOP_INSTRUCTIONS.md` exatamente.
4Leia `TASK.md` e `PROGRESS.md` primeiro.
5Escreva o relatório em `outputs/daily-review.md`.
6Atualize `PROGRESS.md` antes de parar.
7Execute o checklist de verificação.
8Se não houver mudanças significativas → mantenha o relatório curto.
9Se a revisão humana for necessária → marque claramente em `PROGRESS.md`.
10Não modifique nenhum arquivo, exceto `outputs/daily-review.md`
11e `PROGRESS.md`.

As opções de intervalo:

→ /loop 15m — Cadência de teste (use enquanto observa)

→ /loop 1h — Monitoramento por hora

→ /loop 24h — Revisão diária

→ /loop 7d — Limpeza ou resumo semanal

Importante: /loop não é mágica.

Ele apenas repete o prompt.

A qualidade do loop vem da estrutura em torno do prompt — os arquivos, as instruções, a verificação, o estado.

/loop fornece apenas o acionador.

Saiba também sobre /goal:

/loop = execute novamente porque o tempo passou.

/goal = continue executando até que uma condição seja atendida.

1/goal outputs/daily-review.md existe, PROGRESS.md está atualizado,
2checklist de verificação passa, nenhum arquivo proibido foi modificado.

Use /loop para trabalhos baseados em tempo (revisões diárias, monitoramento).

Use /goal para trabalhos baseados em conclusão (corrigir até os testes passarem, escrever até que todas as seções estejam prontas).

A escada de permissões

É aqui que a maioria dos loops dá errado.

As pessoas constroem um loop que funciona. Então, imediatamente, dão a ele muito poder.

O loop posta no Slack diretamente. Envia código sem revisão. Fecha tickets automaticamente.

Então algo dá errado e é uma bagunça.

Use a escada de permissões:

1Nível 1 — Somente leitura
2Claude lê arquivos, tickets, logs, issues.
3
4Nível 2 — Rascunho de saídas
5Claude escreve apenas em outputs/.
6Relatórios, planos, recomendações.
7Nada externo.
8
9Nível 3 — Edições em sandbox
10Claude modifica arquivos dentro de um sandbox controlado.
11Branch ou worktree isolado.
12
13Nível 4 — Rascunho de ações externas
14Claude prepara PR, mensagem do Slack, atualização de ticket.
15NÃO envia ou mescla.
16
17Nível 5 — Ações aprovadas por humanos
18Claude aplica alterações somente após aprovação explícita.
19
20Nível 6 — Ações automatizadas de baixo risco
21Claude conclui tarefas de escopo restrito automaticamente.
22Com logs, limites e reversão.

Seu primeiro loop deve viver no Nível 1 ou Nível 2.

Isso não é fraqueza. Isso é engenharia.

Loops de Nível 1 e 2 ainda podem ser extremamente valiosos.

O Claude pode inspecionar seus issues do GitHub, ler falhas de CI, revisar PRDs e resumir tudo — tudo sem tocar em nada importante.

Prove que o loop funciona no Nível 2 primeiro.

Depois decida se ele merece o Nível 3.

Quando os loops dão errado (e como prevenir)

Primeiro loop ruim:

Todos os dias, melhore a estratégia do produto até que pareça mais forte.

→ Sem condição de parada → Sem verificação → Sem estado → "Parecer mais forte" não é um item de checklist

Este loop ou não fará nada útil ou mudará coisas que não deveria.

Primeiro loop bom:

Toda sexta-feira, revise o documento de estratégia do produto.

Identifique seções que mudaram esta semana.

Liste suposições não resolvidas.

Escreva uma nota de revisão estruturada em outputs/strategy-review.md.

Não edite o documento de estratégia diretamente.

→ Cronograma claro → Escopo limitado → Arquivo de saída previsível → Limite de permissão seguro

A diferença não é inteligência. É design.

As 5 coisas que afundam loops:

→ Agendamento antes do teste manual

→ Nenhum arquivo de estado — toda execução recomeça do zero

→ Sem verificação — o loop confia em si mesmo

→ Sem política de falha — resultados ruins improvisam

→ Muitas ferramentas muito cedo — o raio de explosão se expande

Corrija todos os cinco antes do primeiro comando /loop.

Adicionando ferramentas e conectores

Assim que o loop local estiver estável, você pode estendê-lo.

GitHub. Slack. Linear. Jira. Logs de CI.

Mas cada nova ferramenta expande o raio de explosão.

Siga o mesmo princípio: leia primeiro, rascunhe depois, escreva somente após execuções repetidas bem-sucedidas.

Regras específicas de ferramentas vão em LOOP_INSTRUCTIONS.md:

1## Política de Permissões de Ferramentas
2
3### GitHub
4Permitido:
5- Ler issues abertos
6- Ler status de pull requests
7- Ler status de CI
8- Rascunhar resumo em `outputs/github-review.md`
9NÃO permitido:
10- Enviar commits
11- Mesclar pull requests
12- Fechar issues
13- Comentar publicamente sem aprovação
14
15### Slack
16Permitido:
17- Rascunhar mensagem em `outputs/slack-update.md`
18NÃO permitido:
19- Enviar mensagens
20- Mencionar usuários
21- Postar em canais
22
23### Linear/Jira
24Permitido:
25- Ler tickets atribuídos
26- Rascunhar atualizações sugeridas
27NÃO permitido:
28- Alterar status
29- Fechar tickets
30- Criar tickets sem aprovação

Se a ferramenta não estiver listada → pare e peça revisão humana.

Isso protege você do loop fazer coisas que você não previu.

Como é seu primeiro loop completo

Aqui está a configuração completa do zero.

1## Política de Permissões de Ferramentas
2
3### GitHub
4Permitido:
5- Ler issues abertos
6- Ler status de pull requests
7- Ler status de CI
8- Rascunhar resumo em `outputs/github-review.md`
9NÃO permitido:
10- Enviar commits
11- Mesclar pull requests
12- Fechar issues
13- Comentar publicamente sem aprovação
14
15### Slack
16Permitido:
17- Rascunhar mensagem em `outputs/slack-update.md`
18NÃO permitido:
19- Enviar mensagens
20- Mencionar usuários
21- Postar em canais
22
23### Linear/Jira
24Permitido:
25- Ler tickets atribuídos
26- Rascunhar atualizações sugeridas
27NÃO permitido:
28- Alterar status
29- Fechar tickets
30- Criar tickets sem aprovação

Em seguida, preencha cada arquivo (use os modelos acima).

Depois execute manualmente:

1Execute o loop de revisão diária do projeto para este espaço de trabalho.
2
3Siga `LOOP_INSTRUCTIONS.md` exatamente.
4Antes de agir, leia TASK.md, PROGRESS.md,
5e LOOP_INSTRUCTIONS.md.
6Escreva a revisão diária em `outputs/daily-review.md`.
7Atualize `PROGRESS.md` antes de parar.
8Execute o checklist de verificação.
9Não modifique nenhum arquivo, exceto
10`outputs/daily-review.md` e `PROGRESS.md`.

Depois verifique:

1Execute uma passagem de verificação.
2Verifique contra o Checklist de Verificação em
3`LOOP_INSTRUCTIONS.md`.
4Relate quais verificações passaram, quais falharam,
5quais arquivos foram modificados, se a revisão humana é necessária.
6Não modifique nenhum arquivo.

Execute 3-5 vezes manualmente com pequenas alterações no espaço de trabalho.

Depois agende:

1/loop 24h Execute o loop de revisão diária do projeto...
2[mesmo prompt do manual, prefixado com /loop 24h]

Revise a primeira semana de saídas agendadas antes de confiar nele.

Esse é o sistema completo.

A mudança que transforma tudo

Antes dos loops:

→ Você escrevia um prompt

→ O Claude respondia

→ Amanhã você escrevia o mesmo prompt novamente

→ O Claude não tinha memória do dia anterior

→ Você rastreava manualmente o que mudou

→ Tudo reiniciava a cada sessão

Depois dos loops:

→ TASK.md define o objetivo uma vez

→ PROGRESS.md carrega a memória entre execuções

→ LOOP_INSTRUCTIONS.md controla o comportamento

→ O Claude lê, age, verifica, atualiza, para

→ Amanhã ele continua de onde parou

→ Você revisa saídas, não prompts

O gargalo muda de gerar trabalho para revisar trabalho.

Essa é a verdadeira alavancagem.

Você não está fazendo perguntas melhores ao Claude.

Você está projetando um sistema que continua funcionando sem você.

10 loops que você pode construir esta semana

→ Revisão diária do projeto — lê o espaço de trabalho, escreve resumo

→ Extrator de acompanhamento de reunião — transforma anotações em itens de ação

→ Planejador de limpeza de pasta — organiza, propõe, não toca

→ Triagem de falha de CI — lê logs, classifica falhas, rascunha investigação

→ Resumidor de issues do GitHub — lê issues abertos, agrupa por tema

→ Assistente de revisão de PR — lê diff, sinaliza problemas potenciais

→ Loop de pesquisa de newsletter — coleta fontes, rascunha resumos

→ Localizador de lacunas de documentação — lê docs, sinaliza seções faltando

→ Rascunhador de daily standup — lê PROGRESS.md, escreve standup

→ Loop de retrospectiva semanal — revisa a semana, identifica padrões

Cada um deles começa com o mesmo sistema de 4 arquivos.

A única coisa que muda é TASK.md e LOOP_INSTRUCTIONS.md.

Se isso foi útil:

→ Reposte para compartilhar com todo desenvolvedor que usa Claude

→ Siga @sairahul1 para mais sistemas que funcionam sem você

→ Marque isto — os modelos estão prontos para copiar e colar

Inscreva-se em theaibuilders.co para mais artigos interessantes como este

Eu escrevo sobre IA, construção de produtos e sistemas de automação.