Como usar o comando /goal no Claude Code hoje

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 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 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; 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 é 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, autor do Bootcamp do Dev Doido, e formações como o Crazystack Typescript, da plataforma Crazystack. 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 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