Der ultimative Leitfaden für /goal

/goal ist kein Feature. Es ist ein Primitiv.

HTTP ist ein Primitiv. JSON ist ein Primitiv. /goal wird zu einem für Coding-Agenten.

Vor ein paar Wochen hat OpenAI's Codex CLI /goal hinzugefügt, um dem Coding-Worker einen Job mit einem definierten Erledigt-Zustand zu geben. Claude Code hat es diese Woche eingeführt.

Hermes Agent, der Orchestrator, den ich auf einem Mac Mini betreibe, um die Arbeit zwischen Coding-Workern zu koordinieren, hat /goal schon länger eingebaut.

Ich habe jetzt also einen Builder, einen Reviewer und einen Orchestrator, die alle dasselbe Befehlsformat akzeptieren, obwohl sie sonst nichts gemeinsam haben.

Wer /goal nur als ausgefallenen Prompt gesehen hat, hat nicht verstanden, was es wirklich verändert.

Was /goal eigentlich ist

Ein normaler Prompt fordert einen Agenten zur nächsten Antwort auf. Du liest die Antwort, entscheidest, ob sie richtig ist, und schubst den Agenten zum nächsten Schritt. Du steuerst jede Runde.

/goal dreht das um. Du schreibst auf, wie „erledigt“ aussieht, reichst es einmal ein, und der Agent arbeitet darauf hin, bis er es erreicht. Hier ein echtes Beispiel:

1/goal Baue die in SPEC.md beschriebene App. „Erledigt“ bedeutet: Tests bestehen,
2Build besteht, README ist korrekt und git status zeigt nur
3relevante Projektdateien an.

Das Ziel bleibt aktiv, bis es erreicht, pausiert, blockiert, gelöscht wird oder das Budget ausgeschöpft ist.

Das ist etwas anderes, als das Wort „goal“ in einen normalen one-shot Befehl zu setzen. Wenn du codex exec 'goal: build the app' eingibst, ist das immer noch ein Prompt mit einem Label. Das eigentliche Primitiv lebt innerhalb einer interaktiven Worker-Session. Du startest die CLI, gibst /goal ein und gehst weg.

Der Wandel ist weg vom Prompting (du fährst) hin zum Zuweisen (der Agent fährt auf ein von dir definiertes Ziel zu).

GIF

Die drei Tools, die derzeit /goal sprechen

Die drei Tools, die /goal akzeptieren, sind nicht alle dieselbe Art von Sache, daher lohnt es sich, genau zu sein.

Codex ist die Coding-CLI von OpenAI. Stark bei der Implementierung, besonders mit einer klaren Spezifikation. /goal ist die Art, wie du ihm diese Spezifikation gibst.

Claude Code ist die Coding-CLI von Anthropic. Stark im Gegenteil: Finden, was an Code falsch ist, der richtig aussieht. Spezifikationskonformität, Sicherheitsprobleme, Fehlerzustände, Sicherheitslücken. /goal ist die Art, wie du es auf Code richtest und um eine Überprüfung bittest.

Hermes Agent ist eine ganz andere Art von Tool. Kein Coding-Worker, sondern ein Orchestrator, der die Arbeit zwischen Coding-Workern wie den beiden obenstehenden koordiniert. /goal ist die Art, wie Hermes Aufgaben an das richtige Tool für den Job übergibt, und auch, wie ich Hermes überhaupt erst sage, was ich will.

Wichtig ist nicht, dass irgendeiner von ihnen /goal ausgeliefert hat. Sondern, dass drei verschiedene Teams auf dasselbe Primitiv gekommen sind, und diese Konvergenz macht es möglich, sie zu kombinieren.

GIF

Einrichtung

Als ich zum ersten Mal Codex und Claude Code auf dem Mac Mini brauchte, der Hermes betreibt, habe ich sie nicht von Hand installiert. Ich habe Hermes eine Nachricht geschickt, es solle beide installieren und mich einloggen. Es hat den Rest erledigt.

Das ist jetzt der Workflow. Du tippst keine Installationsbefehle ein. Setup ist nur ein weiteres Ziel.

Wenn du noch keinen Orchestrator laufen hast, sind die Installationsseiten für Codex und Claude Code leicht zu befolgen. Aber sobald du einen hast, solltest du kein weiteres Tool mehr von Hand einrichten. Der Sinn eines Orchestrators ist, dass mechanische Arbeit nicht mehr deine ist.

Was Hermes zusätzlich zu /goal bietet

Ein rohes /goal ist für sich genommen nützlich. Aber es hinterlässt ein Koordinationsproblem.

Wenn Codex in einem Terminal läuft und Claude Code in einem anderen, musst du dir merken, welcher Prozess was macht. Du musst Logs prüfen. Du musst Überprüfungsergebnisse manuell von einem Tool zum anderen weiterreichen.

Hermes verwandelt diese losen Läufe in einen Workflow:

1. Du schreibst Hermes (in meinem Fall über Telegram von meinem Handy aus)
2. Hermes erstellt Zielkarten auf einem Kanban-Board
3. Hermes wählt den richtigen Worker für jede Karte aus
4. Der Worker führt das Ziel im Hintergrund aus
5. Die Karte speichert die Prozess-ID, PID, das Repository und die Erledigt-Kriterien
6. Wenn der Build fertig ist, übergibt Hermes das Repository an den Reviewer
7. Wenn die Überprüfung blockiert, schickt Hermes die Ergebnisse als Fix-Ziel zurück
8. Hermes verifiziert die endgültige Ausgabe durch Inspektion des Dateisystems, der Tests, des Builds und des Git-Status

Das Board ist das, was /goal wird, wenn ein Orchestrator darüber liegt. Jedes Ziel hat eine Karte, jede Karte hat einen Status, jede Übergabe hinterlässt eine Spur. Anstatt Terminals zu durchsuchen, beobachtest du, wie die Arbeit auf deinem Handy über die Spalten wandert.

Die drei Rollen

Die Tools ändern sich. Die Rollen nicht.

Orchestrator. Besitzt die Kontrollschleife. Aufgabenzerlegung, Worker-Auswahl, Kanban-Karten, Hintergrundprozesse, Abhängigkeiten, finale Verifikation, die zusammenfassende Anzeige für den Benutzer. In meinem Setup: Hermes.

Builder. Nimmt eine Spezifikation und produziert funktionierenden Code. Implementierung ist der Engpass, den diese Rolle löst. Codex ist hier meist stark.

Reviewer. Liest, was der Builder produziert hat, und findet, was daran falsch ist. Korrektheit ist der Engpass. Claude Code ist hier meist stark.

Ein echter Durchlauf, von Anfang bis Ende

Ich habe Hermes Agent das Ziel gegeben, Folgendes zu tun:

1/goal Baue ein CLI-Tool, das X Erwähnungen von mir findet und mich benachrichtigt, wenn
2etwas explodiert.

Hermes hat die Anfrage in sechs Karten aufgeteilt.

Shubham Saboo

@Saboo_Shubham_

·

12. Mai

Codex /goal baut es.

Claude Code /goal überprüft und verfeinert es.

Hermes /goal verwaltet die Orchestrierung und Übergabe.

Alles verfolgt auf einem einzigen Kanban-Board, und Agenten laufen weiter in der Schleife.

58

61

852

88K

Karte 1: Spezifikation. Hermes hat die SPEC.md selbst geschrieben, mit Stack, Repository-Pfad, Read-Only-Einschränkungen, Mock-Mode-Anforderungen, Tests und Verifikationsbefehlen. Eigentum der PM-Rolle.

Karte 2: Codex baut. Codex hat /goal gegen die SPEC.md ausgeführt. Es hat die Projektdateien erstellt, die UI und das Backend implementiert, Tests hinzugefügt und die App in einen funktionierenden Zustand gebracht. Etwa 15 Minuten. Als es fertig war, bestand npm test, npm run build bestand, und git status zeigte nur relevante neue Dateien.

Karte 3: Claude Code überprüft. Claude Code hat /goal ausgeführt, um zu überprüfen, was Codex gebaut hat. Geprüft wurden Spezifikationskonformität, Read-Only-Sicherheit, API-Key-Handling, Fehlerzustände, Tests, Nützlichkeit der UI, Bugs und Sicherheitsprobleme. Ergebnis: BESTANDEN, keine blockierenden Probleme.

Karte 4: Codex Fix-Schleife. Übersprungen, weil die Überprüfung bestanden wurde. Die Karte ist trotzdem wichtig, wenn sie übersprungen wird. Sie zeigt, dass Hermes bedingte Arbeit modellieren kann. Wenn Claude Code blockiert hätte, hätte Hermes die Ergebnisse als neues /goal an Codex zurückgegeben.

Karte 5: Claude Code finale Verifikation. Aus demselben Grund übersprungen.

Karte 6: Hermes finale Zusammenfassung. Funktionierende App unter dem lokalen Pfad, UI und API beide im Mock-Mode verifiziert. Codex hat es mit /goal gebaut. Claude Code hat es mit /goal überprüft und BESTANDEN zurückgegeben.

All das kam von einer einzigen Nachricht. Drei verschiedene Tools haben die eigentliche Arbeit erledigt, aber ich habe nur mit Hermes gesprochen.

Die Verifikationsregel

Hermes hat nie dem Selbstbericht von Codex vertraut. Nachdem Codex den Build als erledigt markiert hatte, hat Hermes die Befehle selbst ausgeführt:

1npm test         # 17 Tests bestanden
2npm run build    # vite build bestanden

Der Verifizierer macht aus einem /goal einen Vertrag statt eines Versprechens. Vertraue nicht dem Selbstbericht des Workers als endgültig. Vertraue dem Verifizierer.

Coding-Agenten sind selbstbewusst. Sie sagen dir, der Build bestünde, obwohl der Build nie ausgeführt wurde. Sie sagen dir, Tests bestünden, obwohl sie Tests geschrieben haben, die nie ausgeführt wurden. Der Verifizierer schließt diese Lücke.

Ohne Verifikation ist /goal nur ein ausgefallenerer Prompt. Mit Verifikation wird es zu einem Vertrag.

GIF

Mehrere Ziele gleichzeitig ausführen

Du kannst mehrere /goals parallel ausführen, aber du kannst nicht mehrere Coding-Worker auf dieselben Dateien richten, ohne vorher darüber nachzudenken.

Mein Standard ist ein Haupt-Builder pro Repository. Wenn ich Parallelität möchte, füge ich sie entlang klarer Grenzen hinzu. Verschiedene Repositories, verschiedene Branches, Git-Worktrees, separate Pakete, Dokumentation vs. Code, Tests vs. Implementierung. Überall dort, wo sich zwei Worker nicht in die Quere kommen können.

Das schlechte Muster ist, wenn drei Worker alle dieselbe Datei im selben Repository bearbeiten. Du bekommst Konflikte, teilweise Überschreibungen, und ein Worker macht die Arbeit eines anderen stillschweigend rückgängig.

Das bessere Muster ist: immer nur ein Schreiber pro Datei. Builder schreibt, Reviewer liest nur, Fix-Ziele bleiben auf den Fix beschränkt. Oder lass drei Builder in drei Worktrees an drei konkurrierenden Ansätzen arbeiten und den Orchestrator den besten auswählen.

Das Board macht das praktikabel. Ohne es werden parallele Hintergrund-Worker zu einem Terminal-Chaos.

Was sich für mich ändert

Die nützliche Betrachtungsweise ist nicht „Ich kann Agenten im Hintergrund laufen lassen“.

Sondern, dass eine einzige Nachricht zu einer Pipeline über drei verschiedene Coding-Tools wird, und ich beobachte das Ganze auf einem einzigen Board.

Du hörst auf, in einem Terminal zu sitzen und darauf zu warten, dass ein Agent fertig wird, und fängst an, eine Warteschlange von Arbeit mit sichtbarem Status zu verwalten.

Wenn Codex und Claude Code jeweils ihr eigenes Job-Übergabeformat erfunden hätten, könnte kein Orchestrator zwischen ihnen routen. Das Board ist beeindruckend, aber das Primitiv macht das Board noch nützlicher.

Die Worker können sich ändern, aber das Primitiv bleibt gleich. Das nächste Coding-Tool, das /goal übernimmt, wird sich dieser Pipeline anschließen, ohne dass ich etwas ändern muss. Ich leite die Arbeit einfach dorthin.

Das ist es, was gute Primitive tun.

Für weitere coole Tipps und interessante Ideen rund um Hermes, OpenClaw, Claude Code, Codex und andere 24/7 Agenten-Teams.

Folge → @Saboo_Shubham_