O Guia Definitivo para o /goal

/goal não é um recurso. É um primitivo.

HTTP é um primitivo. JSON é um primitivo. /goal está se tornando um para agentes de codificação.

Há algumas semanas, o Codex CLI da OpenAI adicionou o /goal como uma forma de dar ao trabalhador de codificação uma tarefa com um estado de conclusão definido. O Claude Code adicionou isso esta semana.

O Hermes Agent, o orquestrador que executo em um Mac Mini para coordenar o trabalho entre os trabalhadores de codificação, já tem o /goal integrado há um tempo.

Então agora tenho um construtor, um revisor e um orquestrador que todos aceitam o mesmo formato de instrução, mesmo que não compartilhem mais nada.

Se você só viu o /goal sendo usado como um prompt mais sofisticado, você perdeu o que ele realmente muda.

O que /goal realmente é

Um prompt comum pede ao agente a próxima resposta. Você lê o que vem de volta, decide se está certo e empurra o agente para o próximo passo. Você está controlando cada etapa.

O /goal inverte isso. Você escreve como é o "pronto", submete uma vez, e o agente trabalha em direção a isso até chegar lá. Aqui está um exemplo real:

1/goal Construa o aplicativo descrito no SPEC.md. "Pronto" significa que os testes passam,
2o build passa, o README está preciso e o git status mostra apenas
3arquivos relevantes do projeto.

A meta permanece ativa até ser alcançada, pausada, bloqueada, limpa ou até que o orçamento acabe.

Isso é diferente de colocar a palavra "goal" dentro de um comando normal de uso único. Se você escrever codex exec 'goal: construa o aplicativo', isso ainda é um prompt com um rótulo. O verdadeiro primitivo vive dentro de uma sessão de trabalhador interativa. Você inicia o CLI, submete /goal e vai embora.

A mudança é de dar comandos (você dirigindo) para atribuir (o agente dirigindo em direção a um alvo que você definiu).

GIF

As três ferramentas que atualmente falam /goal

As três ferramentas que aceitam /goal não são todas do mesmo tipo, então vale a pena ser específico.

Codex é o CLI de codificação da OpenAI. Forte na implementação, especialmente quando recebe uma especificação clara. /goal é como você dá essa especificação.

Claude Code é o CLI de codificação da Anthropic. Forte no inverso: encontrar o que está errado em código que parece certo. Conformidade com especificações, problemas de segurança, estados de erro, falhas de segurança. /goal é como você aponta para o código e pede uma revisão.

Hermes Agent é um tipo diferente de ferramenta. Não é um trabalhador de codificação, mas um orquestrador que coordena o trabalho entre trabalhadores de codificação como os dois acima. /goal é como o Hermes repassa tarefas para a ferramenta certa para o trabalho, e também como eu digo ao Hermes o que quero, em primeiro lugar.

O que importa não é que qualquer um deles individualmente tenha lançado o /goal. É que três equipes diferentes convergiram para o mesmo primitivo, e essa convergência é o que torna possível compô-los.

GIF

Preparando tudo

Na primeira vez que precisei do Codex e do Claude Code no Mac Mini que roda o Hermes, não os instalei manualmente. Enviei uma mensagem para o Hermes pedindo que ele instalasse ambos e fizesse o login. Ele cuidou do resto.

Esse é o fluxo de trabalho agora. Você não digita comandos de instalação. A configuração é apenas mais uma meta (goal).

Se você ainda não tem um orquestrador rodando, as páginas de instalação do Codex e do Claude Code são fáceis de seguir. Mas quando tiver um, você não deve configurar outra ferramenta manualmente. O objetivo de ter um orquestrador é que o trabalho mecânico deixa de ser seu.

O que o Hermes adiciona além do /goal

Um /goal bruto é útil por si só. Mas deixa você com um problema de coordenação.

Se o Codex está rodando em um terminal e o Claude Code em outro, você precisa lembrar qual processo está fazendo o quê. Precisa verificar logs. Precisa passar manualmente os resultados da revisão de uma ferramenta para outra.

O Hermes transforma essas execuções soltas em um fluxo de trabalho:

1. Você envia uma mensagem para o Hermes (no meu caso, pelo Telegram do meu celular)
2. O Hermes cria cartões de meta (goal cards) em um quadro Kanban
3. O Hermes escolhe o trabalhador certo para cada cartão
4. O trabalhador executa a meta em segundo plano
5. O cartão armazena o ID do processo, PID, repositório e critérios de conclusão
6. Quando o build está pronto, o Hermes entrega o repositório ao revisor
7. Se a revisão bloquear, o Hermes envia os resultados de volta como uma meta de correção
8. O Hermes verifica a saída final inspecionando o sistema de arquivos, testes, build e estado do git

O quadro é o que o /goal se torna quando há um orquestrador sobre ele. Cada meta tem um cartão, cada cartão tem um status, cada entrega deixa um rastro. Em vez de caçar terminais, você vê o trabalho se mover pelas colunas no seu celular.

Os três papéis

As ferramentas mudam. Os papéis não.

Orquestrador. Possui o laço de controle. Decomposição de tarefas, seleção de trabalhadores, cartões Kanban, processos em segundo plano, dependências, verificação final, resumo para o usuário. Na minha configuração, o Hermes.

Construtor. Pega uma especificação e produz código funcional. A implementação é o gargalo que este papel resolve. O Codex tende a ser forte aqui.

Revisor. Lê o que o construtor produziu e encontra o que está errado. A correção é o gargalo. O Claude Code tende a ser forte aqui.

Uma execução real, do início ao fim

Eu dei ao agente Hermes uma meta para fazer isto:

1/goal Construa uma ferramenta CLI que encontra menções minhas no X e me avisa quando
2algo explodir.

O Hermes dividiu a solicitação em seis cartões.

Shubham Saboo

@Saboo_Shubham_

·

12 de maio

Codex /goal constrói.

Claude Code /goal revisa e refina.

Hermes /goal gerencia a orquestração e a entrega.

Tudo rastreado em um único quadro Kanban e os agentes continuam rodando no ciclo.

58

61

852

88K

Cartão 1: Especificação. O Hermes escreveu o SPEC.md, capturando a stack, caminho do repositório, restrições de somente leitura, requisitos de modo mock, testes e comandos de verificação. De propriedade do papel de PM.

Cartão 2: Codex constrói. O Codex executou /goal contra o SPEC.md. Criou os arquivos do projeto, implementou a interface do usuário e o backend, adicionou testes e deixou o aplicativo em estado funcional. Cerca de 15 minutos. Quando terminou, npm test passou, npm run build passou, e git status mostrou apenas novos arquivos relevantes.

Cartão 3: Claude Code revisa. O Claude Code executou /goal para revisar o que o Codex construiu. Verificou conformidade com a especificação, segurança de somente leitura, manipulação de chaves de API, estados de erro, testes, utilidade da interface do usuário, bugs e problemas de segurança. Resultado: APROVADO, sem problemas bloqueadores.

Cartão 4: Loop de correção do Codex. Pulado, porque a revisão passou. O cartão ainda importa quando é pulado. Mostra que o Hermes pode modelar trabalho condicional. Se o Claude Code tivesse bloqueado, o Hermes teria passado os resultados de volta para o Codex como um novo /goal.

Cartão 5: Verificação final do Claude Code. Pulado pelo mesmo motivo.

Cartão 6: Resumo final do Hermes. Aplicativo funcional no caminho local, interface do usuário e API verificados em modo mock. O Codex construiu com /goal. O Claude Code revisou com /goal e retornou APROVADO.

Tudo isso veio de uma única mensagem. Três ferramentas diferentes fizeram o trabalho real, mas eu só conversei com o Hermes.

A regra da verificação

O Hermes nunca confiou no auto-relato do Codex. Depois que o Codex marcou o build como concluído, o Hermes executou os comandos ele mesmo:

1npm test         # 17 tests passed
2npm run build    # vite build passed

O verificador é o que torna um /goal um contrato em vez de uma promessa. Não confie no auto-relato do trabalhador como final. Confie no verificador.

Agentes de codificação são confiantes. Eles dirão que o build passou quando o build nunca foi executado. Eles dirão que os testes passaram quando escreveram testes que nunca executaram. O verificador fecha essa lacuna.

Sem verificação, /goal é apenas um prompt mais sofisticado. Com verificação, ele se torna um contrato.

GIF

Executando múltiplas metas

Você pode executar vários /goals em paralelo, mas não pode apontar vários trabalhadores de codificação para os mesmos arquivos sem pensar nisso primeiro.

Meu padrão é um construtor principal por repositório. Se quero paralelismo, adiciono-o em limites claros. Repositórios diferentes, branches diferentes, git worktrees, pacotes separados, documentação vs código, testes vs implementação. Qualquer lugar onde dois trabalhadores não possam interferir um no outro.

O padrão ruim é três trabalhadores editando o mesmo arquivo no mesmo repositório. Você obtém conflitos, sobrescritas parciais e um trabalhador desfazendo silenciosamente o trabalho de outro.

O padrão melhor é um escritor por vez em qualquer arquivo. O construtor escreve, o revisor apenas lê, as metas de correção permanecem no escopo da correção. Ou execute três construtores em três worktrees em três abordagens concorrentes e deixe o orquestrador escolher a melhor.

O quadro é o que torna isso prático. Sem ele, trabalhadores paralelos em segundo plano se tornam caos no terminal.

O que muda para mim

O enquadramento útil aqui não é "posso executar agentes em segundo plano".

É que uma mensagem se transforma em um pipeline através de três ferramentas de codificação diferentes, e eu vejo tudo se mover em um único quadro.

Você para de ficar sentado em um terminal esperando um agente terminar e começa a gerenciar uma fila de trabalho com estado visível.

Se o Codex e o Claude Code tivessem inventado cada um seu próprio formato de entrega de tarefas, nenhum orquestrador poderia rotear entre eles. O quadro é impressionante, mas o primitivo torna o quadro ainda mais útil.

Os trabalhadores podem mudar, mas o primitivo permanece o mesmo. A próxima ferramenta de codificação que adotar o /goal se juntará a este pipeline sem que eu mude nada. Eu apenas rotearei o trabalho para ela.

É isso que bons primitivos fazem.

Para mais dicas legais e ideias interessantes sobre Hermes, OpenClaw, Claude Code, Codex e outras equipes de agentes 24/7.

Siga → @Saboo_Shubham_