Prompt říká agentovi, co chceš teď. /goal říká agentovi, co znamená hotovo.
To je celý rozdíl. A ten rozdíl mění způsob, jak s coding agenty pracuješ.
Před pár týdny přidal /goal OpenAI do Codex CLI. Tento týden ho přidal Anthropic do Claude Code. Hermes Agent — orchestrátor, který koordinuje práci mezi coding workers — ho má od začátku. Tři různé týmy, tři různé produkty, jeden primitiv. Když se tohle stane, není to náhoda. Je to signál.
Proč je /goal primitiv, ne feature
HTTP je primitiv. JSON je primitiv. Na těchto věcech se nezávisle shodli vývojáři napříč různými projekty, protože řeší reálný problém způsobem, který se dá skládat dohromady.
/goal je na cestě stát se totéž pro coding agenty.
Běžný prompt funguje takhle: napíšeš instrukci, agent odpoví, přečteš výsledek, rozhodneš jestli je dobrý, pošleš další instrukci. Ty řídíš každý tah. Agent je reaktivní.
/goal to otočí. Napíšeš co znamená „hotovo" — konkrétní done criteria, ne vágní zadání — a agent pracuje dokud tam nedojde. Sám. Bez toho, aby ses musel vracet po každém kroku.
/goal Build a CLI that pulls X mentions of @handle and scores them by signal.
Done when: npm test passes, npm run build passes, git status shows only new relevant files.
Budget: 30 minutes wall time.
Cíl zůstane aktivní dokud se nedosáhne výsledku, agent není zablokovaný, nebo nevyprší budget. Tohle není fancier prompt s klíčovým slovem „goal" na začátku. Je to jiný způsob interakce — z promptování (ty řídíš) na přiřazení (agent řídí k cíli, který jsi definoval).
Tři nástroje, tři role
Codex CLI, Claude Code a Hermes Agent — všechny tři přijímají /goal, ale dělají různé věci.
Codex je builder. Dostane specifikaci, implementuje ji. Je silný v tom, vzít jasně definovaný cíl a dovést ho k funkčnímu kódu. /goal je způsob, jak mu tu specifikaci předat.
Claude Code je reviewer. Je silný v opaku: najít co je špatně na kódu, který vypadá správně. Spec compliance, bezpečnostní díry, error states, edge cases, které builder přehlédl. /goal je způsob, jak ho nastavit na konkrétní review zadání.
Hermes Agent je orchestrátor jiného druhu — ne coding worker, ale koordinátor, který řídí práci mezi Codexem a Claude Code. /goal je způsob, jak mu zadáš co chceš, a on to rozloží na karty, přiřadí správný nástroj a hlídá průběh.
Klíčová věc není, že každý z nich přidal /goal. Je to, že tři různé týmy konvergovaly na stejném primitivu — a tato konvergence umožňuje je skládat dohromady.
Reálný run: od jedné zprávy k hotové appce
Konkrétní příklad jak to funguje v praxi s Hermesem jako orchestrátorem.
Zadání: "Postav CLI tool, který najde X zmínky o mně a upozorní mě, když něco exploduje."
Hermes to rozložil na šest karet:
Karta 1 — Spec. Hermes napsal SPEC.md sám. Stack, cesta k repozitáři, read-only omezení, mock mode requirements, testy, verifikační příkazy.
Karta 2 — Codex buildí. Codex spustil /goal proti SPEC.md. Vytvořil project files, implementoval UI a backend, přidal testy. Asi 15 minut. Výsledek: npm test prošel, npm run build prošel, git status ukázal jen relevantní nové soubory.
Karta 3 — Claude Code reviewuje. Claude Code spustil /goal na review. Zkontroloval spec compliance, bezpečnost API klíčů, error states, testy, UI použitelnost, bugy a bezpečnostní problémy. Výsledek: PASS, žádné blocking issues.
Karty 4 a 5 — fix loop a finální verifikace. Přeskočeny, protože review prošel. Karty ale existovaly. Hermes modeluje podmíněnou práci — kdyby Claude Code zablokoval, findings by šly zpět Codexu jako nový /goal.
Karta 6 — Hermes finální shrnutí. Funkční appka na lokální cestě.
Celé to přišlo z jedné zprávy. Tři různé nástroje udělaly práci. Ty jsi mluvil jen s Hermesem.
Pravidlo, které dělá /goal spolehlivým
Hermes nikdy nevěřil Codexovu self-reportu. Poté co Codex označil build za hotový, Hermes sám spustil verifikační příkazy.
npm test
npm run build
git status
Pravidlo je jednoduché: nevěř self-reportu workeru jako finálnímu výsledku. Věř verifieru.
Coding agenti jsou sebevědomí. Řeknou ti, že build prošel, i když ho nikdy nespustili. Řeknou ti, že testy prošly, i když napsali testy, které se nikdy nespustily. Verifikátor tento gap zavírá.
Bez verifikace je /goal jen fancier prompt. S verifikací se stává kontraktem.
Jak spustit více /goal najednou bez konfliktů
Paralelní goals jsou mocné, ale musíš na to myslet. Nemůžeš namířit více coding workers na stejné soubory bez koordinace.
Špatný pattern: Tři workers editují stejný soubor ve stejném repozitáři. Dostaneš konflikty, partial overwrites, jeden worker potichu přepíše práci druhého.
Dobrý pattern: Jeden writer na jeden soubor v daném čase. Builder píše, reviewer jen čte. Fix goals jsou scoped na fix. Nebo spusť tři buildery ve třech git worktrees na třech competing approaches a nech orchestrátora vybrat nejlepší.
Prakticky: jeden hlavní builder per repo. Parallelismus přidávej přes čisté hranice — různé repozitáře, různé branches, worktrees, oddělené packages, docs vs. kód, testy vs. implementace.
Jak začít bez orchestrátoru
Hermes je pokročilý setup. Pro většinu vývojářů stačí jako začátek Claude Code samotný nebo kombinace Claude Code + Codex bez orchestrátoru.
Klíč je napsat /goal správně. Vágní cíl = vágní výsledek.
Špatně:
/goal Make the app better
Dobře:
/goal Refactor the authentication module.
Done when:
- All existing tests pass (npm test)
- No new TypeScript errors (tsc --noEmit)
- Auth middleware extracted to /src/middleware/auth.ts
- Session handling decoupled from route handlers
Budget: 20 minutes
Done criteria jsou to, co dělá /goal skutečným primitivem. Čím konkrétnější, tím lépe agent ví, kdy se zastavit — a tím snáze ty ověříš, jestli to zvládl.
Co se mění pro tvůj workflow
Praktická změna není „můžu spustit agenty na pozadí."
Je to, že jedna zpráva se může stát pipeline přes tři různé nástroje, a ty sledujete průběh přes jeden board nebo terminál — místo toho, abyste seděli u terminálu a čekali na každý krok.
Přestáváš čekat na agenta aby dokončil jednu věc, a začínáš spravovat frontu práce s viditelným stavem.
Workers se mohou měnit. Primitiv zůstává stejný. Každý coding nástroj, který přidá /goal, se připojí do tohoto pipeline bez toho, abys cokoliv měnil. Jen nasměruješ práci k němu.
To je to, co dělají dobré primitivy.
Zdroj: analýza @Saboo_Shubham_ na X.com, 14. května 2026