O comando do Claude Code que trabalha enquanto você dorme

Adriano aqui.

Hoje quero compartilhar meu novo vídeo sobre o /goal: o comando do Claude Code que inverte completamente a lógica do pair programming com IA.

Por muito tempo, minha sessão com Claude Code seguia o mesmo padrão: eu dava um prompt, o Claude começava, aparecia uma pergunta, eu respondia, ele executava, aparecia outra pergunta, eu aprovava. Turno por turno, até o trabalho terminar: ou até eu precisar largar o computador no meio. Minha atenção era o combustível. Sem eu estar lá, a sessão parava.

O /goal quebra essa lógica. Em vez de você avaliar se o trabalho está pronto, um modelo separado faz isso. O Claude principal trabalha. O árbitro decide se terminou.

Testei três casos: cobertura de testes, refatoração com critério subjetivo, e automação via cron job sem nenhuma interação. No final de um deles, o CHANGELOG estava pronto antes de eu abrir o computador na segunda de manhã.

Assista no YouTube.

No vídeo, cubro:

Organizei em duas partes:

1. Há um segundo modelo fazendo o trabalho que você fazia. O /goal não é só um loop automático: é uma arquitetura de dois modelos. O Claude principal executa. O Haiku avalia. A cada turno, o árbitro lê a condição que você escreveu, lê o que aconteceu na conversa, e decide: o critério foi atingido ou não. Se não, o Claude continua.

2. O árbitro externo resolve o viés de conclusão. Quando o Claude principal está no meio de uma tarefa, ele quer terminar. A tendência é julgar que chegou onde tinha que chegar: mesmo que a cobertura ainda esteja em 68% e o limite seja 70%. O Haiku não tem esse viés. Ele lê a condição e aplica: passou ou não passou.

3. Você pode fechar o laptop. Assim que você envia o /goal, o terminal mostra ◎ /goal active com o tempo decorrido. O goal continua rodando mesmo com o terminal em segundo plano. Para checar: /goal sem argumento retorna o estado atual, quantos turnos rodaram, e o motivo mais recente do avaliador. Para cancelar: /goal clear.

4. O modo não-interativo transforma isso em infraestrutura. claude -p "/goal [condição]" roda o loop inteiro a partir de um script, CI, ou cron job. Combinado com --permission-mode auto, que aprova tool calls sem intervenção humana, do disparo ao resultado: zero teclado.

5. O árbitro é cego para tudo que não aparece na conversa. Ele não roda comandos, não lê arquivos diretamente. O único canal que ele tem com o mundo real é o que você escreve na condição. Condições vagas fazem o goal encerrar antes do tempo: não porque o trabalho terminou, mas porque o árbitro não tinha como dizer que não terminou.

6. A regra de ouro: se a máquina não consegue medir, a máquina não consegue fazer. /goal refatora o módulo até ficar mais legível vai encerrar cedo porque "legível" não é mensurável. A pergunta certa não é "o que eu quero?": é "como eu saberia que terminou?" Funções menores, nomes sem abreviações, complexidade ciclomática abaixo de 5 verificada com npx ts-complexity: isso o árbitro consegue julgar.

7. Sempre inclua uma cláusula de parada. /goal [critério]: ou parar após 15 turnos. O avaliador também julga essa cláusula. Goals sem limite podem rodar por muito tempo e consumir tokens de forma inesperada: especialmente quando o critério tem uma margem de ambiguidade. Eu coloco cláusula de parada em todo goal que não tem critério 100% verificável.

Template com 3 condições prontas para copiar

https://github.com/adrianoviana/claude-code-demos/blob/main/video-04-goal-autonomo/template-condicoes-goal.md

Inclui: cobertura de testes, refatoração com métricas objetivas, geração de documentação: cada uma com os três elementos (end state mensurável + check declarado + constraint de escopo) e a cláusula de parada já configurada.

Documentação oficial

Até a próxima,

Adriano Viana
System Architect | AI-Native Content Creator

P.S.: Se você encontrar uma condição que o árbitro consistentemente julga errado, para antes do tempo ou continua depois de terminar, me manda. Estou mapeando os padrões de falha mais comuns para cobrir nas próximas edições.