Goal — deixe o Claude rodar sozinho até a condição ser atingida
Defina uma condição verificável de conclusão e o Claude itera até bater a meta, sem você empurrar a cada rodada
⏱ Estim. ~6 min
01 · Ler
Numa tarefa grande, você costuma ter que ficar repetindo "continua", "corrige o próximo", "roda os testes", "tenta de novo" — porque o Claude faz uma coisa por rodada e para esperando você.
/goal deixa você definir uma condição verificável de conclusão, e o Claude itera sozinho até bater a meta. Por exemplo: "todos os testes em test/auth passam e o lint está limpo". Você configura, aperta Enter e vai tomar um café. Quando voltar, ou a condição foi atingida e ele encerrou, ou o Claude empacou esperando sua decisão.
💡 Imagine assimÉ como dar para uma pessoa engenheira um ticket com critério de aceite: "esse PR só fecha quando estiver verde". Ela itera, edita, roda testes, edita de novo, roda de novo, sem confirmar cada passinho com você. Você só aparece quando ela travou de vez ou terminou.
Pontos-chave
- /goal <condição> define a condição de conclusão e começa a primeira rodada na hora
- O Claude roda uma rodada → avalia se bateu → se não, roda mais uma
- Bateu, encerra sozinho; se não, também dá para parar manualmente com /goal clear
- Perfeito para tarefas com critério de aceite claro (testes passam, arquivo existe, queue vazia)
02 · Ler
Como funciona por dentro: ao fim de cada rodada, um modelinho separado (em geral Haiku) lê a transcript da conversa e decide se a condição foi atingida. Ele não pode rodar comandos nem ler arquivos — só olha o que o Claude mostrou na conversa.
Isso significa que sua condição precisa ser algo que o Claude consiga "mostrar" na conversa: - sim "npm test exit code 0" (o Claude roda os testes, a saída aparece) - sim "git status limpo" (o Claude roda git status, a saída aparece) - não "código de boa qualidade" (não dá para verificar, o avaliador não entende) - não "sem bugs" (não tem como provar na conversa)
Outro ponto-chave é que o "modelo executor" e o "modelo avaliador" são separados — o Claude que está trabalhando não declara conclusão para te enrolar; o Haiku decide de forma independente.
Pontos-chave
- O avaliador (Haiku) decide separado do modelo que está trabalhando
- O avaliador não pode rodar comandos nem ler arquivos — só vê o conteúdo da conversa
- A condição precisa de evidência que o Claude consiga "mostrar" na conversa
- Limite de 4000 caracteres; dá para incluir um "ou para após N rodadas" como seguro
03 · Exemplo de código
Três comandos principais: configurar, checar progresso, limpar.
Dentro de uma session do Claude Code
# 設定 goal — 立刻開始第一輪
/goal all tests in test/auth pass and lint is clean
# 看當前進度 (條件、跑了幾輪、花了多少 token、評估器最新理由)
/goal
# 手動清除 (條件達成會自動清，不需要這步)
/goal clear
# 別名： stop, off, reset, none, cancel
# /clear 開新對話也會清掉
Headless / rodada única
# 非互動模式，跑到完成才回 shell
claude -p "/goal CHANGELOG.md 有這週每個 PR 的條目"
# Ctrl+C 中斷
Com a goal ativa, ao lado do prompt aparece ◎ /goal active mais o tempo decorrido. O modo headless (-p) é ótimo para CI ou agendamento, por exemplo rodar "gerar entrada de changelog" todo dia até concluir.
04 · Exemplo de código
Condição bem escrita vs mal escrita faz muita diferença — veja exemplos reais:
Condição ruim (avaliador não consegue verificar)
/goal 把 auth.js 拆得更好
/goal 修 login bug
/goal 確保程式碼品質夠
/goal 完成所有 TODO
Condição boa (critério claro + limite de segurança)
/goal 把 auth.js 拆成多個 module、每個 <300 行、所有測試通過、或 20 輪後停
/goal 修登入特殊字元 bug，跑 `npm test test/auth` 全綠、或 15 輪後停
/goal 把所有 import 從 old-api 換成 new-api、lint 乾淨、grep 找不到 old-api
Boas condições têm três pontos em comum: um estado final mensurável (exit code, número de arquivos, queue vazia), deixar claro "como provar" (qual comando rodar) e um limite de segurança ("ou para após N rodadas" para não queimar tokens infinito). Condição ruim costuma usar palavras subjetivas como "qualidade boa" ou "melhor estruturado" — o avaliador não consegue ler.
05 · Ler
O Claude Code tem várias ferramentas de "continuar automático", não confunda: - /goal — define uma condição e o Claude itera até bater. O foco é "rodar até terminar", não importa quantas rodadas. - /loop — define um agendamento (por exemplo, "a cada 5 minutos faz X") e dispara no horário. O foco é "checagem periódica", não terminar. - Stop hook — script no arquivo de settings que roda sua lógica de decisão ao fim de cada rodada. O foco é "regra customizada que vale entre sessions". - Auto mode — tira o prompt de "sim, autorizo" antes de cada chamada de ferramenta. O foco é "sem aprovação", não fazer o Claude decidir quando parar.
A combinação ideal: Auto mode (sem aprovação) + /goal (rodar até terminar) = deixar o Claude correr sozinho de verdade.
Pontos-chave
- /goal = rodar até a condição ser atingida (vale para a session)
- /loop = agendamento por tempo (periódico)
- Stop hook = lógica customizada entre sessions (escrita nas settings)
- Auto mode = sem apertar sim
- Auto mode + /goal usados juntos deixam o Claude rodar em background de verdade
06 · Quiz
Você precisa que o Claude reescreva class components antigos do React em hooks, são 30 arquivos. Qual /goal tem mais chance de chegar ao fim?
- /goal reescrever todos os class components em hooks
- /goal reescrever todos os class components em hooks, cada arquivo passa nos testes originais, grep não encontra extends React.Component, ou para após 40 rodadas
- /goal deixar o código mais moderno e mais fácil de manter
- /goal reescrever components até eu estar satisfeito
07 · Combinar
Combine cada cenário com a ferramenta mais adequada.
(Esta seção é interativa — ative o JavaScript para usar.)
Outras lições deste capítulo
⚠ A experiência interativa completa precisa de JavaScript. Ative-o e recarregue a página.
※ Este é um projeto educacional independente — não é um produto oficial da Anthropic. Claude™ é uma marca registrada da Anthropic, PBC.