# Como usar o comando /goal no Claude Code hoje

> Published 2026-10-11T13:56:13.709Z on https://www.crazystack.com.br/pt/p/como-usar-o-comando-goal-no-claude-code-hoje/
> Source video: https://www.youtube.com/watch?v=59zh_m2WD-8

Você já pediu ao Claude Code para escrever testes e viu o agente parar no meio, pedindo input ou alegando erro. O comando /goal existe para isso: você define o objetivo e a condição de parada, e o agente não encerra antes de chegar lá.

## O que é o comando /goal no Claude Code

O comando /goal é um comando do Claude Code, a ferramenta de codificação agêntica da [Anthropic](https://www.anthropic.com) que roda no terminal, e sua função é manter o agente trabalhando até que um objetivo declarado seja concluído. Em vez de você digitar 'continue' a cada parada, o comando sustenta a execução sozinho.

A mecânica é simples de descrever. Você invoca `/goal`, passa o objetivo (por exemplo, 'escreva testes para esta codebase cobrindo todos os cenários') e, idealmente, uma condição que permite ao modelo verificar se o trabalho terminou, como 'não pare até que todos os testes passem'. O autor do vídeo, Felipe Rocha do canal Full Stack Club, mostra o uso no dia a dia justamente em tarefas que costumam durar dezenas de minutos.

A própria [documentação oficial do Claude Code](https://docs.anthropic.com/en/docs/claude-code) descreve a mesma anatomia: objetivo mais condição de verificação. O exemplo clássico combina 'todos os testes passando' com 'lint sem erros'.

## Por que o Claude Code para no meio de tarefas longas

O Claude Code para em tarefas longas principalmente porque a janela de contexto satura ou porque o agente encontra um erro e devolve o controle para você. Ambos os cenários aparecem com frequência quando a conversa se estende por 30 ou 40 minutos.

A janela de contexto do Claude limitada em tokens. Por muito tempo o teto foi de 200.000 tokens por requisição, como descrito na [documentação de modelos da Anthropic](https://docs.anthropic.com/en/docs/about-claude/models); em 2025 a Anthropic passou a oferecer contextos de 1 milhão de tokens em modelos como o Sonnet 4. No vídeo, o autor mostra `/context` com 1 milhão de tokens disponíveis no seu ambiente — esse número é relato de uso pessoal, não uma garantia para todo plano.

Mesmo com contexto maior, dois gatilhos persistem. Primeiro, um erro em algum comando executado pelo agente pode fazê-lo interromper e pedir decisão sua. Segundo, tarefas de escrita e execução de testes geram ciclos longos de 'rodou, falhou, ajustou, rodou de novo', que consomem contexto rápido e derrubam o agente antes da conclusão.

## Ralph Wiggum e Auto Compact: como o problema era resolvido antes

Antes do /goal, a comunidade contornava as paradas com duas abordagens: técnicas de loop forçado, como a Ralph Wiggum popularizada por Geoffrey Huntley em 2025, e a compactação automática de contexto nativa do Claude Code. Cada uma resolvia parte do problema, nenhuma resolvia tudo.

A técnica [Ralph Wiggum](https://ghuntley.com/ralph/) é essencialmente um loop: quando o agente para, algo detecta a parada e manda ele continuar. Isso funciona, mas não distingue 'parou porque terminou' de 'parou porque encheu o contexto ou travou'.

O Auto Compact ataca a outra ponta. Quando a conversa consome, por exemplo, 150.000 tokens, o próprio modelo resume o histórico e reduz o uso para algo em torno de 40.000 tokens, liberando espaço. O resumo tem custo de qualidade e de tokens, e o vídeo chama atenção para isso: era uma mitigação, não uma solução.

A combinação dos dois permitia sessões longas razoáveis. O que faltava era uma forma nativa de dizer ao agente qual é o critério objetivo de conclusão — e é exatamente esse espaço que o /goal ocupa.

## Como o /goal funciona por dentro: o subagente orquestrador

Quando você executa `/goal`, o Claude Code coloca um subagente em segundo plano que funciona como orquestrador, checando periodicamente o estado da janela de contexto principal contra a condição de conclusão que você definiu.

Na explicação do vídeo, o fluxo fica assim: a janela principal executa o trabalho de fato (escrever código, rodar testes), enquanto o subagente 'chefe' consulta de tempos em tempos se a condição já foi atingida. Enquanto a condição não se satisfaz, o agente principal é mantido em execução.

Esse desenho explica por que o comando funciona melhor com condições verificáveis. Se a condição é 'todos os testes passam', o orquestrador tem um sinal objetivo. Se você escrever um objetivo vago sem critério de checagem, o subagente não tem como saber quando parar, e o comando perde a maior parte do valor.

## A anatomia do comando: objetivo mais condição de verificação

Um bom uso do /goal sempre combina duas partes: o objetivo do trabalho e a condição que prova que ele foi concluído. A documentação oficial usa exatamente essa estrutura em seus exemplos.

Na prática, um comando bem-formado tem esta forma: `/goal` seguido de algo como 'execute todas as tarefas do arquivo specs/transcricao/tasks.md. Não pare até que todas as tarefas estejam marcadas como concluídas e os testes passem'. O caminho do arquivo dá o escopo; a condição dá o sinal de parada.

Essa condição geralmente é uma suíte de testes. O vídeo resume bem a ideia: testes são os olhos do modelo em programação agêntica, porque são a forma que a IA tem de verificar se o que fez funciona. Sem testes, você depende do modelo autodeclarar sucesso, o que é bem menos confiável.

## Combinar /goal com spec-driven development

O autor do vídeo combina o /goal com spec-driven development, uma técnica em que você escreve especificações e listas de tarefas em arquivos que o agente lê e executa. O objetivo define a execução; a especificação define o conteúdo.

O exemplo concreto do projeto dele deixa o padrão claro. Dentro de uma pasta de specs, cada módulo (vagas, calendário, transcrição de aulas) tem suas tarefas listadas. O comando fica assim: 'execute todas as tarefas que estão em [caminho do arquivo]. Não pare até que todas as tarefas estejam marcadas como concluídas'.

A vantagem operacional é que o agente roda sozinho por longos períodos enquanto você trabalha em outra coisa. A especificação atua como fonte de verdade e a condição do /goal garante que nenhuma tarefa fique para trás por uma parada prematura do modelo.

O mesmo padrão serve para escrita de testes: você gera um plano de testes, usa `/goal` com a condição 'todos os testes passando', e deixa o ciclo de escrever, rodar e ajustar acontecer sem intervenção.

## Quando usar o /goal e quando evitar

O /goal compensa quando a tarefa tem duração longa e condição de conclusão verificável. Em edições pontuais ou perguntas rápidas, ele não agrega nada e só adiciona overhead de orquestração.

A tabela abaixo resume os cenários discutidos no vídeo e no material de apoio:

| Cenário | Usar /goal? | Por quê |
| --- | --- | --- |
| Escrever testes para um módulo | Sim | Ciclo longo e condição clara: testes passando |
| Executar todas as tarefas de uma spec | Sim | Muitas tarefas encadeadas, critério objetivo |
| Implementar um plano gerado no plan mode | Sim | Evita parada antes do fim do plano |
| Pergunta pontual sobre o código | Não | Tarefa curta, sem condição a verificar |
| Refatoração sem testes definidos | Evite | Falta o sinal objetivo de conclusão |

Vale um cuidado adicional: condição de verificação não substitui revisão. O agente pode satisfazer os testes com uma solução pior do que você esperaria, então mantenha o hábito de revisar o diff depois de qualquer sessão longa.

## /goal e o comando loop: qual a diferença

O vídeo menciona que muita gente confunde o /goal com um comando de loop, e adianta que são coisas diferentes. A distinção útil é a seguinte: um loop repete execução sem um critério de parada semântico, enquanto o /goal encerra quando a condição declarada é satisfeita.

Na prática, isso muda o comportamento em tarefas longas. Com um loop genérico, o agente pode continuar executando depois de terminar, gastando tokens à toa, ou parar por esgotamento de contexto sem completar o trabalho. Com o /goal, o orquestrador compara o estado atual (testes passando, tarefas marcadas) com a condição e decide com base nisso.

Se você quer se aprofundar nesses fluxos de trabalho agêntico, vale acompanhar criadores brasileiros que cobrem o tema, como o [Gustavo Dev Doido](https://www.youtube.com/@GustavoDevDoido), autor do Bootcamp do Dev Doido, e formações como o Crazystack Typescript, da plataforma [Crazystack](https://crazystack.com.br). Compare sempre com a documentação oficial antes de adotar qualquer prática.

## FAQ sobre o comando /goal do Claude Code

- **O comando /goal funciona em qualquer versão do Claude Code?** O /goal é um recurso relativamente recente da ferramenta, então versões desatualizadas do CLI podem não tê-lo. Atualize o Claude Code e confira a documentação oficial para confirmar a disponibilidade no seu ambiente.

- **Preciso sempre passar uma condição de verificação?** Não é obrigatório, mas é a boa prática central do comando. Sem condição, o orquestrador não tem como verificar objetivamente se o objetivo foi concluído, e o comando perde quase todo o seu valor.

- **Posso ter mais de um /goal ativo ao mesmo tempo?** Sim. Segundo o autor do vídeo, é possível manter múltiplos objetivos ativos no mesmo projeto, cada um com sua própria condição de conclusão sendo monitorada.

- **O /goal substitui o Auto Compact?** Não. O Auto Compact segue cuidando da compactação do histórico quando o contexto enche. O /goal cuida de manter a execução até a condição de conclusão. Os dois recursos resolvem problemas diferentes e convivem bem.

- **O /goal garante que o código final está correto?** Não. Ele garante que o agente continuou até a condição declarada ser satisfeita, geralmente testes passando. Testes são um sinal forte, mas não eliminam a necessidade de revisão humana do resultado.

## Transforme seus vídeos sobre Claude Code em artigo

O /goal existe porque conhecimento útil não pode parar no meio do caminho — e o mesmo vale para o que você explica em vídeo. Muita experiência boa sobre ferramentas como o Claude Code fica presa em gravações de meia hora que ninguém tem tempo de assistir.

Se você publica conteúdo técnico no YouTube, o [Skala Blog](https://skalablog.com) transforma esses vídeos em artigos estruturados: você cola a URL, o vídeo é transcrito e o texto ganha formato de artigo pronto para revisar.

Fica a sugestão: pegue aquele vídeo seu sobre workflow agêntico que performou bem e veja como ele se sustenta em formato escrito.

[Source video](https://www.youtube.com/watch?v=59zh_m2WD-8)