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 /goal como uma forma de dar ao trabalhador de codificação uma tarefa com um estado de conclusão definido. O Claude Code adicionou esta semana.

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

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

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

O que /goal realmente é

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

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

1/goal Construa o aplicativo descrito no SPEC.md. Pronto significa que
2os testes passam, a build passa, o README está preciso e o git status mostra
3apenas os arquivos 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 único normal. Se você escrever codex exec 'goal: build the app', isso ainda é um prompt com um rótulo. O primitivo real vive dentro de uma sessão de trabalho interativa. Você inicia o CLI, envia o /goal e sai.

A mudança é de solicitar (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 um código que parece certo. Conformidade com a especificação, 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 entrega 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 tenha implementado /goal. É que três equipes diferentes convergiram para o mesmo primitivo, e essa convergência é o que torna possível compô-los.

GIF

Configurando as coisas

Na primeira vez que precisei do Codex e do Claude Code no Mac Mini que executa o Hermes, não os instalei manualmente. Enviei uma mensagem para o Hermes pedindo para instalar ambos e me conectar. Ele cuidou do resto.

Esse é o fluxo de trabalho agora. Você não digita comandos de instalação. A configuração é apenas outra meta.

Se você ainda não tem um orquestrador em execução, as páginas de instalação do Codex e do Claude Code são fáceis de seguir. Mas, quando tiver, 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 ao /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ê. Você precisa verificar os logs. Você precisa passar manualmente os resultados da revisão de uma ferramenta para a 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 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 a build está pronta, 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 /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 em terminais, você observa o trabalho se mover pelas colunas no seu celular.

Os três papéis

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

Orquestrador. É dono do loop 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, 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 isso:

1/goal Construa uma ferramenta CLI que encontre X menções a mim e me avise
2quando algo explodir.

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

Shubham Saboo

@Saboo_Shubham_

·

May 12

Codex /goal constrói.

Claude Code /goal revisa e refina.

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

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

58

61

852

88K

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

Cartão 2: Codex constrói. O Codex executou /goal com base no SPEC.md. Criou os arquivos do projeto, implementou a UI e o backend, adicionou testes e colocou o aplicativo em um estado funcional. Cerca de 15 minutos. Quando terminou, o npm test passou, o npm run build passou e o 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 UI, bugs e problemas de segurança. Resultado: APROVADO, sem problemas bloqueantes.

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 entregue os resultados de volta ao 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, UI e API verificados em modo simulado. 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 de verificação

O Hermes nunca confiou no auto-relato do Codex. Depois que o Codex marcou a build como concluída, o Hermes executou os comandos por conta própria:

1npm test         # 17 testes passaram
2npm run build    # vite build passou

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 a build passou quando a build nunca foi executada. Eles dirão que os testes passam quando escreveram testes que nunca executaram. O verificador fecha essa lacuna.

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

GIF

Executando múltiplas metas

Você pode executar múltiplos /goal em paralelo, mas não pode apontar múltiplos 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. Em qualquer lugar onde dois trabalhadores não possam atrapalhar um ao outro.

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

O padrão melhor é um escritor por vez em qualquer arquivo. Construtor escreve, revisor só lê, 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 de terminais.

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 por um quadro.

Você para de sentar 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 /goal se juntará a este pipeline sem que eu mude nada. Vou apenas rotear o trabalho para ela.

Isso é o 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_