Como usar o /goal com eficiência: um agente autônomo é um contrato operacional, não um botão mágico (2026)
O /goal não deixa o agente mais inteligente - só o deixa mais persistente. Persistente na direção certa é ótimo; persistente na direção errada dói. Bem usado, o /goal é um contrato operacional: resultado + escopo + restrições + verificação + regras de parada - não um botão mágico de "aperte uma vez e o app se constrói sozinho". Aqui estão três lições do mundo real (com correções) e o fluxo planejar-de-dia/executar-de-noite que finalmente funcionou para mim.
- O /goal é um recurso do Codex, atualmente atrás de feature flag e mudando rápido; a sintaxe e o comportamento aqui foram conferidos com a documentação oficial na hora em que escrevi - confirme a documentação ao vivo antes de depender dela.
O que o /goal é (e o que não é)
O /goal é o goal mode do Codex (OpenAI Codex CLI) para um objetivo longo e mecânico com uma condição de parada verificável. Você o ativa via /experimental ou adicionando goals = true em [features] no config.toml, e então roda /goal <objective>. Enquanto ele roda, digite /goal para ver o status; controle com /goal pause, /goal resume, /goal clear.
E aqui está a parte mais importante: o /goal não é um limite de segurança, não substitui decisões de produto e não é lugar para rodar um backlog sem limites. É um loop persistente, nada mais. (Observação: o /goal é um recurso do Codex, não um comando nativo do Claude Code - não confunda os dois.) Para a sintaxe, veja o guia oficial do goal mode.
A verdade dura: o /goal só deixa o agente mais persistente, não mais inteligente
As pessoas exaltam o /goal como se fosse o botão de "aperte uma vez, o app se constrói sozinho". Eu abusei dele por uma semana e apanhei feio todas as vezes. A conclusão é simples: o /goal não deixa o agente mais inteligente, deixa o agente mais persistente. Persistente na direção certa é ótimo; persistente na direção errada dói - ele simplesmente dispara pelo caminho errado sem parar para se questionar.
Os três "tapas" abaixo são os modos de falha mais comuns, e a lição de cada um.
Tapa nº 1 - desvio de limite depois do auto-compact (um deploy em produção)
Eu escrevi a meta com toda a clareza: fazer deploy só em staging. Mas depois de alguns auto-compacts, o agente saiu do contexto, esqueceu o limite e fez deploy direto em produção - mesmo havendo um hook que lembrava a tarefa a cada compact.
Lição dolorida: nunca dê a um agente acesso privilegiado à produção. Não confie no "ele vai lembrar". Não - ele não lembra com a confiabilidade que você imagina. É exatamente por isso que o goal mode não é um limite de segurança: a linha de segurança tem que morar nas suas permissões, não numa anotação dentro de um prompt. Veja como apertar o acesso em permissões do Claude Code e boas práticas de segurança para codar com IA.
Tapa nº 2 - metas vagas são licença para vaguear
"Deixa mais bonito." "Melhora a UX." Soa humano. Mas, para um agente, isso é licença para vaguear. Ele mudou uma coisa, quebrou outra, alucinou um pouco e às vezes parou cedo sem que nada tivesse claramente melhorado.
Lição: uma meta precisa definir o que "melhor" significa. Mais bonito como?
- Espaçamento mais justo?
- Contraste mais legível?
- Melhor responsividade no mobile?
- Menos etapas no checkout?
- Taxa de conclusão mais alta?
Se você não sabe o que quer, não jogue isso para um agente e rode o /goal. Primeiro faça brainstorm, planeje, escreva critérios de aceite. Quando os requisitos ainda estão confusos, uma rodada rápida de pedir a um advisor para esclarecer (advisor/kongming) vale mais do que ligar a autonomia. Para escrever um plano com checagens concretas, veja planejamento de projeto para Claude Code.
Tapa nº 3 - verificação ausente (um "pronto" confiante e falso)
Defini uma meta para uma nova página de frontend, mas esqueci de dizer ao agente para usar o agent-browser na verificação visual. O resultado? Ele pulou a verificação de verdade e relatou, cheio de confiança, "concluído com sucesso". Aí eu abri e lembrei que a vida não é conto de fadas.
Lição: não confie em ninguém. Forneça as ferramentas certas e exija explicitamente que o agente as use antes de terminar. Testes verdes não bastam:
- O frontend precisa ser olhado (screenshot/agent-browser).
- O fluxo precisa ser clicado do começo ao fim.
- O deploy precisa checar o ambiente.
- O PR precisa revisar o diff.
O contrato operacional - a fórmula de um bom /goal
Em resumo: um bom /goal não é um prompt esperto. É um contrato operacional com cinco partes:
| Parte | Responde à pergunta |
|---|---|
| Resultado | O que "pronto" significa? (um resultado concreto e mensurável) |
| Escopo | No que ele pode mexer e no que não deve? |
| Restrições | Quais limites não podem ser quebrados (sem produção, sem mudar API pública…)? |
| Verificação | Como o "pronto" é provado (testes, build, screenshot, clicar do começo ao fim)? |
| Regras de parada | Quando parar, quando perguntar a um humano? |
Isso combina com o "teste de uso" do goal mode: só use quando a tarefa (1) for mais longa que um turno e majoritariamente mecânica, (2) tiver uma condição de parada verificável e (3) estiver com escopo claro o suficiente para avançar sem uma decisão de produto a cada checkpoint. Não use o /goal para trabalho exploratório, pedidos de melhoria vagos, mudanças de credenciais de produção, infraestrutura compartilhada destrutiva ou um backlog misturado.
Como eu uso o /goal: separar o planejamento do dia da execução da noite
Meu jeito favorito agora é separar o pensar do dia da execução da noite.
De dia (pensar)
- Criar issues no GitHub para cada bug / recurso / melhoria.
- Usar as skills de brainstorm e plano para esclarecer cada issue.
- Responder na issue com um resumo da implementação + um link para o
plan.md. - Adicionar a label
ready to implement. - Repetir até cada issue estar preparada.
De noite (execução)
Antes de descansar e passar um tempo com a família, deixo o /goal rodar: "Implemente todas as issues marcadas como ready-to-implement com base nos planos predefinidos." O loop por issue:
- Ordenar as issues por prioridade.
- Implementar uma issue por vez.
- Criar um worktree e branch separados por issue.
ak:cook --auto(execução contínua contra o plano).ak:code-review.ak:ship beta.ak:review-pr --fix.- Adicionar a label
ready to shipe passar para a próxima issue.
Isso funciona muito melhor. O agente não fica mais adivinhando "o que você quer?" - ele executa contra um plano esclarecido, com o próprio branch, revisão, deploy beta, PR e label. Acordo, faço café, abro a máquina e há uma pilha de PRs esperando. Meu trabalho não é mais digitar "continue" feito uma palhaça microgerenciadora - é revisar com olhos humanos, testar de novo e então fazer o merge. Para rodar worktrees/PRs em paralelo, veja orquestrar subagents; coloque esse loop dentro do fluxo brainstorm → plano → cook → ship.
Quer o loop de gates pronto? (AgentKit)
O loop da noite é forte por causa dos seus gates de qualidade: ak:cook, ak:code-review, ak:ship, ak:review-pr. O AgentKit entrega esses gates e roda tanto no Claude Code quanto no Codex - então encaixa no /goal do Codex. Para ser franca: o /goal é do Codex e é grátis; o kit só acrescenta o processo pronto + revisão para você não montar tudo sozinha. Para detalhes, leia a análise do AgentKit ou a análise do Engineer Kit.
O valor real do /goal
Esse é o valor real do /goal: não deixar o agente pensar por você, mas deixá-lo cuidar da execução repetitiva depois que você já fez o pensar. Você faz o pensar - spec, plano, critérios de aceite - e então deixa ele ralar. Seu trabalho é revisar com olhos humanos, testar de novo e então fazer o merge.
Perguntas frequentes (FAQ)
O que é o /goal, e de qual ferramenta ele é?
O /goal é o goal mode do Codex (OpenAI Codex CLI), atualmente atrás de feature flag: ative via /experimental ou goals = true em [features] no config.toml. Ele NÃO é um comando nativo do Claude Code - não confunda os dois.
Quando você NÃO deve usar o /goal?
Para trabalho exploratório, requisitos vagos, mudanças de credenciais de produção, operações destrutivas em infraestrutura compartilhada ou um backlog misturado com escopo pouco claro. O /goal encaixa em tarefas mecânicas e de longa duração com uma condição de parada verificável.
Como se escreve uma boa meta?
Trate-a como um contrato operacional de cinco partes: Resultado (o que "pronto" significa), Escopo (no que pode/não pode mexer), Restrições (limites que não se quebra), Verificação (como o "pronto" é provado) e Regras de parada (quando parar ou perguntar a um humano).
O /goal pode fazer deploy em produção com segurança?
Não deveria. Não dê acesso de produção ao agente; o goal mode não é um limite de segurança. A linha de segurança pertence às suas permissões (menor privilégio), não a uma anotação no prompt - depois de alguns auto-compacts o agente pode esquecer o limite.
Testes verdes bastam para o agente relatar "pronto"?
Não. O frontend precisa ser olhado (screenshot/agent-browser), o fluxo clicado do começo ao fim, o ambiente de deploy checado e o diff do PR revisado. Forneça as ferramentas certas e exija que o agente as use antes de terminar.
Você precisa do AgentKit para usar o /goal?
Não. O /goal é do Codex e é grátis. O AgentKit só acrescenta os gates ak:cook / ak:code-review / ak:ship / ak:review-pr para rodar dentro do loop - útil se você quiser um processo pronto em vez de montar um.
Conclusão
Não mitifique o /goal. É um loop teimoso - útil depois que você já fez o pensar e só precisa de execução repetitiva. Escreva a meta como um contrato operacional, tranque o acesso à produção, exija verificação e separe o planejamento do dia da execução da noite. Precisa esclarecer os requisitos antes de rodar? Veja advisor vs kongming. Precisa de um plano com critérios de aceite? Veja planejamento de projeto para Claude Code.
Quer gates de qualidade prontos para o seu loop de /goal? O AgentKit Engineer Kit entrega ak:cook, ak:code-review, ak:ship e ak:review-pr para Claude Code e Codex - sem montar o processo você mesma. Custa $99, sem taxa recorrente informada.