La guida definitiva a /goal

/goal non è una funzionalità. È un primitivo.

HTTP è un primitivo. JSON è un primitivo. /goal sta diventando un primitivo per gli agenti di coding.

Qualche settimana fa, Codex CLI di OpenAI ha aggiunto /goal come modo per assegnare un compito al worker di coding con uno stato di completamento definito. Claude Code lo ha aggiunto questa settimana.

Hermes Agent, l'orchestratore che gestisco su un Mac Mini per coordinare il lavoro tra i worker di coding, ha /goal integrato da un po'.

Quindi ora ho un builder, un reviewer e un orchestrator che accettano tutti lo stesso formato di istruzione, anche se non condividono nient'altro.

Se hai visto /goal usato solo come un prompt più elaborato, ti è sfuggito ciò che cambia veramente.

Cosa è realmente /goal

Un prompt normale chiede a un agente la risposta successiva. Leggi cosa torna, decidi se è giusto e spingi l'agente al passo successivo. Stai guidando ogni singola mossa.

/goal capovolge tutto. Scrivi come appare il "completato", lo invii una volta e l'agente ci lavora fino ad arrivarci. Ecco un esempio reale:

1/goal Crea l'app descritta in SPEC.md. Completato significa che i test passano,
2il build passa, il README è accurato e git status mostra solo
3file di progetto pertinenti.

L'obiettivo rimane attivo finché non viene raggiunto, messo in pausa, bloccato, cancellato o finché non esaurisce il budget.

Questo è diverso dal mettere la parola "goal" in un normale comando one-shot. Se scrivi codex exec 'goal: build the app', quello è ancora un prompt con un'etichetta. Il vero primitivo vive all'interno di una sessione di worker interattiva. Avvii la CLI, invii /goal e te ne vai.

Il cambiamento è dal prompting (tu guidi) all'assegnazione (l'agente guida verso un obiettivo che hai definito tu).

GIF

I tre strumenti che attualmente parlano /goal

I tre strumenti che accettano /goal non sono tutti dello stesso tipo, quindi vale la pena essere precisi.

Codex è la CLI di coding di OpenAI. Forte nell'implementazione, specialmente quando gli viene data una specifica chiara. /goal è il modo in cui gli fornisci quella specifica.

Claude Code è la CLI di coding di Anthropic. Forte nell'inverso: trovare cosa non va in un codice che sembra corretto. Conformità alle specifiche, problemi di sicurezza, stati di errore, falle di sicurezza. /goal è il modo in cui gli punti del codice e chiedi una revisione.

Hermes Agent è un tipo di strumento completamente diverso. Non è un worker di coding, ma un orchestratore che coordina il lavoro tra worker di coding come i due sopra. /goal è il modo in cui Hermes passa i compiti allo strumento giusto per il lavoro, e anche il modo in cui dico a Hermes cosa voglio, in primo luogo.

Ciò che conta non è che uno qualsiasi di loro abbia rilasciato /goal. È che tre team diversi sono convergiti sullo stesso primitivo, e questa convergenza è ciò che rende possibile combinarli.

GIF

Preparare le cose

La prima volta che ho avuto bisogno di Codex e Claude Code sul Mac Mini che esegue Hermes, non li ho installati manualmente. Ho inviato un messaggio a Hermes chiedendogli di installarli entrambi e di farmi accedere. Ha gestito tutto il resto.

Questo è il flusso di lavoro ora. Non scrivi comandi di installazione. La configurazione è solo un altro goal.

Se non hai ancora un orchestratore in esecuzione, le pagine di installazione di Codex e Claude Code sono abbastanza facili da seguire. Ma una volta che lo hai, non dovresti configurare un altro strumento manualmente. Il punto di avere un orchestratore è che il lavoro meccanico smette di essere tuo.

Cosa aggiunge Hermes a /goal

Un /goal grezzo è utile da solo. Ma ti lascia con un problema di coordinamento.

Se Codex è in esecuzione in un terminale e Claude Code in un altro, devi ricordare quale processo sta facendo cosa. Devi controllare i log. Devi passare manualmente i risultati della revisione da uno strumento all'altro.

Hermes trasforma queste esecuzioni isolate in un flusso di lavoro:

1. Invii un messaggio a Hermes (nel mio caso, tramite Telegram dal telefono)
2. Hermes crea delle schede goal su una bacheca Kanban
3. Hermes sceglie il worker giusto per ogni scheda
4. Il worker esegue il goal in background
5. La scheda memorizza l'ID del processo, il PID, il repository e i criteri di completamento
6. Quando il build è pronto, Hermes passa il repo al revisore
7. Se la revisione blocca, Hermes rimanda i risultati come un fix goal
8. Hermes verifica l'output finale ispezionando il filesystem, i test, il build e lo stato di git

La bacheca è ciò che /goal diventa quando c'è un orchestratore sopra. Ogni goal ha una scheda, ogni scheda ha uno stato, ogni passaggio lascia una traccia. Invece di cercare tra i terminali, guardi il lavoro muoversi tra le colonne sul tuo telefono.

I tre ruoli

Gli strumenti cambiano. I ruoli no.

Orchestratore. Possiede il ciclo di controllo. Scomposizione dei compiti, selezione del worker, schede Kanban, processi in background, dipendenze, verifica finale, riepilogo per l'utente. Nella mia configurazione, Hermes.

Builder. Prende una specifica e produce codice funzionante. L'implementazione è il collo di bottiglia che questo ruolo risolve. Codex tende ad essere forte qui.

Revisore. Legge ciò che il builder ha prodotto e trova cosa non va. La correttezza è il collo di bottiglia. Claude Code tende ad essere forte qui.

Un'esecuzione reale, dall'inizio alla fine

Ho dato all'agente Hermes l'obiettivo di fare questo:

1/goal Crea uno strumento CLI che trova menzioni di me su X e mi avvisa quando
2qualcosa esplode.

Hermes ha suddiviso la richiesta in sei schede.

Shubham Saboo

@Saboo_Shubham_

·

12 Maggio

Codex /goal lo costruisce.

Claude Code /goal lo revisiona e lo affina.

Hermes /goal gestisce l'orchestrazione e il passaggio.

Tutto tracciato su un'unica bacheca Kanban e gli agenti continuano a lavorare nel ciclo.

58

61

852

88K

Scheda 1: Specifica. Hermes ha scritto SPEC.md da solo, catturando lo stack, il percorso del repository, i vincoli di sola lettura, i requisiti della modalità mock, i test e i comandi di verifica. Di proprietà del ruolo PM.

Scheda 2: Codex costruisce. Codex ha eseguito /goal su SPEC.md. Ha creato i file di progetto, implementato l'interfaccia utente e il backend, aggiunto test e portato l'app a uno stato funzionante. Circa 15 minuti. Quando ha finito, npm test è passato, npm run build è passato e git status mostrava solo i nuovi file pertinenti.

Scheda 3: Claude Code revisiona. Claude Code ha eseguito /goal per revisionare ciò che Codex aveva costruito. Ha verificato la conformità alle specifiche, la sicurezza in sola lettura, la gestione delle chiavi API, gli stati di errore, i test, l'utilità dell'interfaccia utente, i bug e i problemi di sicurezza. Risultato: SUPERATO, nessun problema bloccante.

Scheda 4: Ciclo di fix di Codex. Saltata, perché la revisione è stata superata. La scheda conta comunque quando viene saltata. Mostra che Hermes può modellare il lavoro condizionale. Se Claude Code avesse bloccato, Hermes avrebbe passato i risultati a Codex come nuovo /goal.

Scheda 5: Verifica finale di Claude Code. Saltata per lo stesso motivo.

Scheda 6: Riepilogo finale di Hermes. App funzionante al percorso locale, sia l'interfaccia utente che l'API verificate in modalità mock. Codex l'ha costruita con /goal. Claude Code l'ha revisionata con /goal e ha restituito SUPERATO.

Tutto questo è arrivato da un singolo messaggio. Tre strumenti diversi hanno fatto il lavoro vero, ma io ho parlato solo con Hermes.

La regola di verifica

Hermes non si è mai fidato dell'autovalutazione di Codex. Dopo che Codex ha segnato il build come completato, Hermes ha eseguito i comandi da solo:

1npm test         # 17 test superati
2npm run build    # vite build superato

Il verificatore è ciò che trasforma un /goal in un contratto invece che in una promessa. Non fidarti dell'autovalutazione del worker come definitiva. Fidati del verificatore.

Gli agenti di coding sono sicuri di sé. Ti diranno che il build passa quando il build non è mai stato eseguito. Ti diranno che i test passano quando hanno scritto test che non sono mai stati eseguiti. Il verificatore colma quel divario.

Senza verifica, /goal è solo un prompt più elaborato. Con la verifica, diventa un contratto.

GIF

Eseguire più goal

Puoi eseguire più /goal in parallelo, ma non puoi puntare più worker di coding sugli stessi file senza pensarci prima.

La mia impostazione predefinita è un builder principale per repository. Se voglio parallelismo, lo aggiungo lungo confini chiari. Repository diversi, branch diversi, git worktrees, pacchetti separati, documentazione vs codice, test vs implementazione. Ovunque due worker non possano pestarsi i piedi a vicenda.

Lo schema negativo è tre worker che modificano tutti lo stesso file nello stesso repository. Ottieni conflitti, sovrascritture parziali e un worker che annulla silenziosamente il lavoro di un altro.

Lo schema migliore è uno scrittore alla volta su un dato file. Builder scrive, revisore solo legge, i fix goal rimangono limitati alla correzione. Oppure esegui tre builder in tre worktrees su tre approcci concorrenti e lascia che l'orchestratore scelga il migliore.

La bacheca è ciò che rende tutto questo pratico. Senza, i worker paralleli in background diventano caos di terminali.

Cosa cambia per me

L'inquadramento utile qui non è "posso eseguire agenti in background".

È che un singolo messaggio si trasforma in una pipeline attraverso tre diversi strumenti di coding, e guardo l'intera cosa muoversi attraverso un'unica bacheca.

Smetti di sederti in un terminale aspettando che un agente finisca e inizi a gestire una coda di lavoro con uno stato visibile.

Se Codex e Claude Code avessero inventato ciascuno il proprio formato di passaggio dei compiti, nessun orchestratore potrebbe instradare tra di loro. La bacheca è impressionante, ma il primitivo rende la bacheca ancora più utile.

I worker possono cambiare, ma il primitivo rimane lo stesso. Il prossimo strumento di coding che adotterà /goal si unirà a questa pipeline senza che io cambi nulla. Mi limiterò a instradare il lavoro verso di esso.

Questo è ciò che fanno i buoni primitivi.

Per altri suggerimenti interessanti e idee curiose su Hermes, OpenClaw, Claude Code, Codex e altri team di agenti 24/7.

Segui → @Saboo_Shubham_