Az utóbbi hetekben megjelent egy újfajta felfogás a kódoló ügynököknél: a "/goal" nem pusztán egy szebb prompt, hanem egy alapszintű primitív, amellyel munkát lehet kiosztani egy kódoló munkásnak meghatározott kész állapot kritériumával.
HTTP és JSON is primitívek — a szerző állítása szerint a /goal ilyen irányba tart. OpenAI Codex CLI néhány héttel ezelőtt bevezette a /goal-t, Claude Code pedig ezen a héten szintén hozzáadta. Hermes Agent, az a orchestrátor, amelyet a szerző a Mac Minijén futtat, már egy ideje támogatja a /goal-t.
A lényeg: most a builder, a reviewer és az orchestrátor ugyanazt az utasításformátumot értik, még ha máshonnan is jöttek és mást is csinálnak.
Mi az, ami valóban megváltozik?
Egy hagyományos prompt arra kér egy ügynököt, hogy adja a következő választ — te vezeted minden lépésnél: kiolvasod a választ, döntesz róla, és továbbirányítod. A /goal ezt megfordítja: egyszer leírod, mi a „kész” állapot, egyszer benyújtod, és az ügynök addig dolgozik rajta, amíg el nem éri.
Példa egy valós /goal-ra:
/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.
A cél aktív marad, amíg teljesül, szünetel, blokkolt lesz, törlik, vagy le nem jár a költségvetése. Ez különbözik attól, ha egyszerűen beleírod a "goal" szót egy one-shot parancsba: a valódi primitív egy interaktív munkamenet része — elindítod a CLI-t, beadod a /goal-t, és el tudsz tőle vonulni.
A váltás lényege: a promptingból (te vezetsz) az assigningbe (az ügynök a cél felé dolgozik) kerülünk.
A három eszköz, amely jelenleg beszéli a /goal-t
A három eszköz nem azonos típusú, ezért érdemes külön kezelnünk őket:
- Codex — OpenAI kódoló CLI-je. Erőssége a megvalósítás, különösen, ha világos specifikációt kap. A /goal a specként működik számára.
- Claude Code — Anthropic kódoló CLI-je. Erőssége inkább az inverse: olyan problémák megtalálása, amelyek a látszat szerint rendben vannak (spec-kompatibilitás, biztonság, hibakezelés, sebezhetőségek). A /goal a review irányítására szolgál.
- Hermes Agent — teljesen más jellegű eszköz: nem egy kódoló munkás, hanem egy orchestrator, amely a különböző kódoló munkásokat koordinálja. A /goal a Hermes számára a feladat kiosztásának eszköze, és ugyanígy így adom meg neki a kívánt végeredményt.
Fontos nem az, hogy bármelyikük bevezette-e külön, hanem az, hogy három külön csapat hasonló primitívben állapodott meg — ez tette lehetővé az összekapcsolhatóságot.
Beállítás és telepítés munkafolyamatként
Amikor először szükségem volt a Codexre és a Claude Code-ra azon a Mac Minin, amelyen Hermes fut, nem telepítettem őket kézzel. Egy üzenetet küldtem Hermesnek, hogy telepítse őket és jelentkezzen be — ő intézte a teljes folyamatot.
Ez lett a munkafolyamat: nem gépelsz install parancsokat; a beállítás egyszerűen egy újabb /goal.
Ha még nincs orchestratorod, a Codex és Claude Code telepítési oldala követhető. De ha van orchestrator, akkor nem érdemes új eszközt kézzel felinstallálni: az orchestrator lényege, hogy a mechanikus munkát leveszi a válladról.
Mit ad hozzá Hermes a /goal fölé?
Egy nyers /goal önmagában hasznos, de koordiációs problémákat hagy maga után: ha Codex egy terminálon fut és Claude Code egy másikon, meg kell jegyezned, melyik folyamat mit csinál, nézned kell a logokat, manuálisan kell átadnod a review-jelentéseket.
Hermes ezeket rendezi egy munkafolyammá:
- Üzensz Hermesszel (a szerző esetében Telegramról a telefonról)
- Hermes létrehozza a goal-kártyákat egy Kanban táblán
- Hermes kiválasztja az adott kártyához a megfelelő munkást
- A munkás háttérben lefuttatja a /goal-t
- A kártya tárolja a folyamat azonosítóját (PID), repo-t és a done-kritériumokat
- Amikor a build kész, Hermes átadja a repót a reviewernek
- Ha a review blokkol, Hermes visszaküldi a talált hibákat fix-célként
- Hermes végül ellenőrzi a kimenetet a fájlrendszer, tesztek, build és git állapot alapján
A tábla az, amivé a /goal válik, amikor van felette orchestrátor: minden célnak van egy kártyája, minden kártyának státusza, és minden átadás nyomot hagy. Ahelyett, hogy terminálok között keresgélnél, a munkát oszlopokon keresztül követheted a telefonodon.
A három szerep
Az eszközök változnak, a szerepek nem:
- Orchestrator: a kontroll-ciklus tulajdonosa — feladatra bontás, munkás kiválasztás, Kanban-kártyák, háttérfolyamatok, függőségek, végső verifikáció és a felhasználó felé összefoglaló. A szerző esetében Hermes.
- Builder: átveszi a specifikációt és működő kódot készít. A megvalósítás problémáját oldja meg. Codex erős ebben.
- Reviewer: átnézi, mit adott a builder, és megkeresi a hibákat. A helyesség az ő szűk keresztmetszete. Claude Code erős itt.
Egy valódi lezajlás lépésről lépésre
A szerző Hermesszel a következő célt adta:
/goal Build a CLI tool that finds X mentions of me and pings me when something blows up.
Hermes ezt hat kártyára bontotta:
- Card 1: Spec. Hermes maga írta meg a SPEC.md-et: stack, repo útvonal, read-only korlátok, mock mode követelmények, tesztek és verifikációs parancsok. A PM szerep birtokolja.
- Card 2: Codex build. Codex futtatta a /goal-t a SPEC.md ellen. Létrehozta a projektfájlokat, implementálta az UI-t és a backendet, hozzáadta a teszteket, és elérte a passing állapotot. Kb. 15 perc alatt. Amikor végzett, npm test átment, npm run build átment, és a git status csak a releváns új fájlokat mutatta.
- Card 3: Claude Code review. Claude Code futtatta a /goal-t, és átnézte, hogy a Codex által készített munka megfelel-e a specnek, biztonsági és read-only aggályokat, API kulcsok kezelését, hibakezelést, teszteket, UI hasznosságát és sebezhetőségeket. Eredmény: PASS, nem voltak blokkoló problémák.
- Card 4: Codex fix loop. Kihagyva, mert a review átment; a kártya mégis fontos, mert mutatja, hogy Hermes tud feltételes munkát modellezni — ha Claude Code blokkolt volna, Hermes visszautalta volna a hibajelentéseket Codex-nek egy új /goal-ként.
- Card 5: Claude Code final verification. Szintén kihagyva ugyanebből az okból.
- Card 6: Hermes final summary. Dolgozó alkalmazás a helyi útvonalon, UI és API ellenőrizve mock módban. Codex építette /goal-lal, Claude Code review-olta /goal-lal és PASS visszaadást adott.
Mind ez egyetlen üzenetből indult. Három különböző eszköz végezte a tényleges munkát, de a szerző csak Hermesszel kommunikált.
A verifikáció szabálya
Hermes sosem bízott Codex önbejelentésében. Miután Codex késznek jelölte a buildet, Hermes maga lefuttatta a parancsokat:
npm test # 17 tests passed npm run build # vite build passed
A verifikátor az, ami szerződés-szerűvé teszi a /goal-t, nem csak ígéretté. Ne higgy a munkás önbejelentésének végsőnek — bízz a verifikátorban.
A kódoló ügynökök magabiztosak: elmondják, hogy a build átment, amikor a buildet soha nem futtatták; azt állítják, hogy a tesztek átmentek, amikor olyan teszteket írtak, amelyek nem futottak le. A verifikátor bezárja ezt az ellentmondást.
Verifikáció nélkül a /goal csupán egy fessebb prompt. Verifikációval szerződés lesz belőle.
Több cél párhuzamos futtatása
Több /goal párhuzamosan futhat, de nem lehet több kódoló munkást ugyanazokra a fájlokra irányítani megfelelő tervezés nélkül.
A szerző alapelve: egy fő builder per repo. Ha párhuzamosítást akar, azt világos határok mentén vezeti be: külön repo-k, külön branchek, git worktree-k, külön csomagok, docs vs code, tesztek vs megvalósítás. Bármi, ahol két munkás nem léphet egymás háta közé.
A rossz minta az, amikor három munkás ugyanazt a fájlt szerkeszti ugyanabban a repo-ban: konfliktusok, részleges felülírások és olyan csendes visszavonások jönnek, amikor az egyik munkás felülírja a másik munkáját.
A jobb minta: egyszerre csak egy író egy adott fájlon. A builder ír, a reviewer csak olvas, a fix célok a javításokra vannak korlátozva. Vagy futtass három buildert három worktree-ben három versengő megközelítéssel, és hagyd, hogy az orchestrátor kiválassza a legjobbat.
A Kanban-tábla teszi ezt gyakorlatilag használhatóvá; nélküle a párhuzamos háttérmunkások terminál-káoszhoz vezetnek.
Mit változtat ez a szerző munkáján?
A hasznos keret nem az, hogy "ügynököket futtathatok a háttérben". Hanem az, hogy egyetlen üzenetből egy csővezeték lesz három különböző kódoló eszköz között, és egy tábla fölött látom, hogyan halad a munka.
Nem ülsz egy terminálban arra várva, hogy egy ügynök befejezze; kezelni kezded a munkák sorát látható státusszal.
Ha Codex és Claude Code külön-külön találták volna ki a saját handoff formátumukat, egy orchestrator nem tudta volna irányítani köztük a munkát. A tábla látványos, de a primitív teszi a táblát még hasznosabbá.
A munkások változhatnak, de a primitív marad. A következő kódoló eszköz, amely elfogadja a /goal-t, becsatlakozik a csővezetékbe anélkül, hogy bármin változtatnom kellene — csak a munkát irányítom majd rá. Pontosan ezt csinálják a jó primitívek.
Következtetés
A /goal mint primitív egységesíti a feladatleírást kódoló munkások és orchestrátorok között, lehetővé téve, hogy különböző eszközök együttműködjenek egy közös munkafolyamatban. Ha ehhez egy verifikációs réteg és egy Kanban-szerű orchestráció társul, a háttérben futó ügynökök megbízható, ellenőrizhető munkavégzést nyújtanak anélkül, hogy a felhasználónak a terminálok között kellene ingáznia.
Kiemelt eszközök a példában: OpenAI Codex CLI, Anthropic Claude Code, és Hermes Agent.
A szerző további tippeket és ötleteket említ Hermes, OpenClaw, Claude Code, Codex és más 24/7 ügynök csapatokkal kapcsolatban, és Twitteren követhető: @Saboo_Shubham_.
