A growing view among coding-agent developers is that "/goal" is not merely a fancier prompt but a low-level primitive for assigning work to coding workers with explicit done criteria.
Like HTTP or JSON, /goal is becoming a foundational interface. OpenAI's Codex CLI added /goal a few weeks ago; Anthropic's Claude Code added it this week. Hermes Agent, the orchestrator the author runs on a Mac Mini, has supported /goal for some time.
The practical consequence: a builder, a reviewer, and an orchestrator now accept the same instruction format even though they are otherwise unrelated.
What actually changes
A normal prompt asks an agent for the next response; you read it, judge it, and steer the conversation turn by turn. /goal flips that model: you describe what "done" looks like once, submit it, and the agent works toward that target until it is reached.
Example of a real /goal:
/goal Build the app described in SPEC.md. Done means tests pass, build passes, README is accurate, and git status only shows relevant project files.
The goal remains active until it is achieved, paused, blocked, cleared, or it runs out of budget. This is different from simply using the word "goal" inside a one-shot command: the true primitive lives inside an interactive worker session. You launch the CLI, submit /goal, and walk away.
The shift is from prompting (you driving) to assigning (the agent driving toward a target you defined).
The three tools that currently speak /goal
They are not the same kind of tool, so specifics matter:
- Codex — OpenAI's coding CLI. Strong at implementation, especially with a clear spec. /goal is how you hand it that spec.
- Claude Code — Anthropic's coding CLI. Strong at the inverse: finding what's wrong with code that looks fine — spec compliance, safety issues, error states, security holes. /goal is how you point it at code and ask for a review.
- Hermes Agent — a different category: an orchestrator that coordinates work among coding workers like the two above. /goal is how Hermes hands tasks to the right tool and how the author tells Hermes what they want.
The important point is not which one shipped /goal first but that three separate teams converged on the same primitive, enabling composition.
Setting things up as a workflow
The first time the author needed Codex and Claude Code on the Mac Mini running Hermes, they didn't install them manually. They told Hermes to install both and log them in; Hermes handled the rest.
That's the workflow now: you don't type install commands. Setup is just another goal.
If you don't yet run an orchestrator, the install pages for Codex and Claude Code are straightforward. But once you have an orchestrator, you shouldn't set up tools by hand — the point is that mechanical work stops being yours.
What Hermes adds on top of /goal
A raw /goal is useful, but it leaves coordination problems. If Codex runs in one terminal and Claude Code in another, you must remember which process is doing what, check logs, and manually pass review findings between tools.
Hermes turns that into a workflow:
- You message Hermes (in the author's case, via Telegram from a phone)
- Hermes creates goal cards on a Kanban board
- Hermes picks the right worker for each card
- The worker runs the goal in the background
- The card stores the process id (PID), repo, and done criteria
- When the build is ready, Hermes hands the repo to the reviewer
- If the review blocks, Hermes sends the findings back as a fix goal
- Hermes verifies final output by inspecting the filesystem, tests, build, and git state
The board is what /goal becomes with an orchestrator on top: every goal has a card, every card a status, and every handoff leaves a trail. Instead of hunting through terminals, you watch work move across columns on your phone.
The three roles
Tools can change; roles remain stable:
- Orchestrator: owns the control loop — task decomposition, worker selection, Kanban cards, background processes, dependencies, final verification, and the user-facing summary. In the author's setup, Hermes.
- Builder: takes a spec and produces working code. Implementation is the bottleneck this role solves. Codex tends to be strong here.
- Reviewer: reads what the builder produced and finds what is wrong. Correctness is the bottleneck. Claude Code tends to be strong here.
An end-to-end run
The author gave Hermes this goal:
/goal Build a CLI tool that finds X mentions of me and pings me when something blows up.
Hermes split the request into six cards:
- Card 1: Spec. Hermes wrote SPEC.md itself, capturing stack, repo path, read-only constraints, mock mode requirements, tests, and verification commands. Owned by the PM role.
- Card 2: Codex builds. Codex ran /goal against SPEC.md. It created project files, implemented UI and backend, added tests, and reached a passing state in about 15 minutes. When finished, npm test passed, npm run build passed, and git status showed only relevant new files.
- Card 3: Claude Code reviews. Claude Code ran /goal to review Codex's output: spec compliance, read-only safety, API key handling, error states, tests, UI usefulness, bugs, and security issues. Result: PASS, no blocking issues.
- Card 4: Codex fix loop. Skipped because the review passed. The card still matters: it shows Hermes can model conditional work. If Claude Code had blocked, Hermes would have handed the findings back to Codex as a new /goal.
- Card 5: Claude Code final verification. Skipped for the same reason.
- Card 6: Hermes final summary. Working app at the local path, UI and API verified in mock mode. Codex built it with /goal. Claude Code reviewed it with /goal and returned PASS.
All of that came from one message. Three different tools did the work, but the author only ever talked to Hermes.
The verification rule
Hermes never trusted Codex's self-report. After Codex marked the build done, Hermes ran the commands itself:
npm test # 17 tests passed npm run build # vite build passed
The verifier is what makes a /goal a contract rather than a promise. Don't trust a worker's self-report as final — trust the verifier.
Coding agents are confident: they'll say the build passes when it was never run, or that tests pass when they wrote tests that never executed. The verifier closes that gap.
Without verification, /goal is just a fancier prompt. With verification, it becomes a contract.
Running multiple goals
You can run multiple /goals in parallel, but you mustn't point multiple coding workers at the same files without planning.
The author's default is one main builder per repo. For parallelism, add it across clear boundaries: different repos, different branches, git worktrees, separate packages, docs vs code, tests vs implementation. Anywhere two workers can't step on each other.
The bad pattern: three workers editing the same file in the same repo — you get conflicts, partial overwrites, and silent undoing of work.
The better pattern: one writer at a time per file. Builder writes, reviewer only reads, fix goals scoped to the fix. Or run three builders in three worktrees on competing approaches and let the orchestrator pick the best one.
The board makes this practical. Without it, parallel background workers become terminal chaos.
What changes for the author
The useful framing isn't merely "I can run agents in the background." It's that one message becomes a pipeline across three coding tools, and the author watches the whole thing move across one board.
You stop sitting in a terminal waiting for a single agent to finish and start managing a visible queue of work.
If Codex and Claude Code had each invented their own job-handoff format, no orchestrator could route between them. The board is impressive, but the primitive makes the board even more useful.
Workers can change, but the primitive remains. The next coding tool that adopts /goal will join this pipeline without any changes from the author — just route work to it. That's what good primitives do.
For more tips and ideas about Hermes, OpenClaw, Claude Code, Codex and other 24/7 agent teams, the author points readers to follow @Saboo_Shubham_.
