Anthropic do Claude Code přidal příkaz /goal, který vykonává úlohu, dokud není hotová. Typicky opravuje chybu, dokud není opravená. Takový Ralph Wiggum Loop pro dospělé…
Claude Code nastaví podmínku dokončení a pak už pracuje napříč obrátkami sám, dokud podmínka neplatí. Po každé obrátce promptu malý rychlý model (defaultně Haiku) přečte konverzaci a rozhodne, jestli je hotovo. Když ano, cíl se automaticky vyčistí. Když ne, vrátí Claude orchestrátoru krátký důvod jako vodítko pro další tah.
Koncept autonomní smyčky řízené ověřitelnou podmínkou není nový. Codex i OpenCode podobnou věc nabízejí déle, byť s jinou mechanikou. Anthropic tak dohání trh, ale s elegantnější implementací. Evaluátor je samostatný model, ne hlavní model posuzující sám sebe.
Jak to funguje
Příkaz se volá s podmínkou jako argumentem:
/goal všechny testy v test/auth procházejí a lint je čistý
Setting cíle okamžitě spouští první turn (český překlad obrátka se mi moc nelíbí, tak ho zase chvíli nebudu používat), podmínka samotná slouží jako příkaz. V status baru se objeví indikátor ◎ /goal active. Po každém turnu evaluátor vrátí ano/ne a krátký důvod, který se zobrazí ve status view a v transkriptu.
Pod kapotou je /goal nadstavba nad Stop hookem, která žije jen v aktuální session a vyhodnocuje se promptem. Vyhodnocovací volání jdou na small/fast model, takže cena tokenů je oproti hlavním tahům zanedbatelná. Limit na podmínku je 4000 znaků.
Klíčové omezení: evaluátor nevolá tooly. Posuzuje jen to, co Claude poslal do konverzace. Podmínka tedy musí být ověřitelná z toho, co Claude sám produkuje - výstup testu, exit kód, status git, počet souborů. Není to “spusť testy a zkontroluj”, je to “Claude musí spustit testy a výsledek musí být v transkriptu”.
/goal funguje i v non-interactive režimu přes claude -p a přes Remote Control. Při --resume se podmínka obnoví, ale counter tahů a tokenů se vynuluje.
Jak napsat dobrou podmínku
Dobrá podmínka má tři vrstvy. Měřitelný end state: test result, exit kód, prázdná fronta, počet souborů. Způsob ověření: npm test exit 0, git status je čistý, ruff check . exit 0. Constraints: co se nesmí cestou porušit, například “žádný jiný testovací soubor není modifikován”.
Doplnit fuse je v praxi nutnost: nebo zastav po 20 tazích. Bez něj hrozí smyčka na nesplnitelné podmínce, kdy Claude tlačí Sisyfa nahoru kopcem za tvoje peníze.
Špatné podmínky jsou ty, které evaluátor nedokáže rozhodnout z transkriptu. V poslední době koluje po X “mega prompt”, kde autor cpe do /goal několikastránkový template s pravidly typu “kód vypadá jako od dobře financovaného startupu”. Haiku z transkriptu takovou věc neposoudí. Tento obsah patří do CLAUDE.md, ne do argumentu /goal.
Kam /goal patří v rodině autonomie Claude Code
/goal je nejmenší článek z rodiny. Stojí za to ho zarámovat správně, ať ho čtenář nepoužívá tam, kde se služí použít něco jiného.
/goal | /loop | Routines | |
|---|---|---|---|
| Spouštěč dalšího běhu | Konec předchozího turnu | Časový interval | Schedule, API endpoint, GitHub event |
| Kdy se zastaví | Evaluátor potvrdí podmínku | Restart, exit, ručně | Nikdy (každý trigger = nová session) |
| Žije v | Session | Session | Anthropic cloud, persistentně |
| Vyžaduje běžící notebook | Ano | Ano | Ne |
| Konfigurace | Argument příkazu | Argument příkazu | Web UI, /schedule v CLI |
/goal je pro úkoly s prokazatelným koncem: migrace modulu, refaktor souboru pod size budget, splnění checklistu v jednom souvislém běhu.
/loop je pro pravidelné kontroly během práce na něčem jiném: polling deploymentu, periodická kontrola CI, připomínka.
Routines jsou pro běhy bez tvého notebooku: noční triage issues, reakce na otevřený PR vlastním review checklistem, reakce na alert z monitoringu přes POST request, port změny mezi SDK po každém merge.
Tyto tři vrstvy se skládají. Routine spuštěná každou noc v 8 si v promptu nastaví /goal projdi všechny PR z poslední noci proti checklistu, dokud nezbyde žádný nezpracovaný a během toho běhu /loop 1m kontroluj stav CI polluje dlouhé jobs. Tři vrstvy, tři různé spouštěče, jeden výsledek. Je to první ucelený agentní stack v Claude Code, který drží pohromadě.
Co /goal neřeší
Evaluátor je jen tak dobrý, jak dobře Haiku přečte transkript. U dlouhých běhů s kompakcí kontextu hrozí, že evaluátor přijde o evidenci, na kterou Claude odkazuje. /goal se zacyklí, pokud Claude opakovaně narazí na chybu, kterou nedokáže opravit; bez fuse v podmínce běží dál.
Funkce vyžaduje workspace s přijatým trust dialogem (Stop hook je součást hooks systému). Pokud má organizace v managed policy disableAllHooks: true, /goal je nedostupný.
Routines jako persistentní vrstva mají vlastní problémečky, na které stojí za to upozornit: jsou v research preview, beta API se může změnit, commits a actions jdou pod vaší GitHub identitou (PR otevřený ve 3 ráno vypadá, jako bys ho otevřel ty), denní cap na běhy a hodinový cap na GitHub eventy nejsou v dokumentaci konkrétně vyčísleny, a “green status” v run listu znamená pouze, že session technicky doběhla, nikoli že úkol uspěl.
Praktická doporučení
Začněte jednou krátkou podmínkou s exit kódem. Vždy přidej fuse na počet turns. Quality bar, projektové konvence a stack patří do CLAUDE.md, ne do argumentu /goal. Pro plně neinteraktivní běh zkombinuj /goal s auto mode - auto mode řeší per-tool souhlasy, /goal per-turn pokračování, dohromady to jede bez prompts.
Pro CI/CD je headless varianta:
claude -p "/goal CHANGELOG.md má entry pro každý PR mergovaný tento týden"
Závěr
/goal je dobrá implementace dobrého nápadu, který Anthropic neměl první. Codex jede dlouho na principu “dokud nemyslím, že jsem hotov”, OpenCode má vlastní continue-until-done mechaniky. Anthropic přidává čistou abstrakci - jedna podmínka jako argument příkazu - a oddělený evaluátor, který posuzuje hlavní model zvenku. To je elegantnější než nechávat hlavní model rozhodovat o tom, zda on sám splnil úkol.
S Routines naopak Anthropic zaplnil mezeru, která u konkurence buď chyběla, nebo byla řešena přes externí CI. Trojice /goal + /loop + Routines je první ucelený autonomní stack v Claude Code. Hodnota není v žádném jednotlivém kusu, ale v tom, že do sebe tyto kusy řešení zapadají.
Otevřená otázka zůstává, jak /goal a Routines zvládnou tichá selhání - tedy stavy, kdy session technicky doběhne a evaluátor potvrdí podmínku, ale výsledek je špatně. Zatím to zpravidla padá na člověka, který hlášení otevře a podívá se, kde to failnulo. To je správně. Ale bude to prudit. Uvidíme, jak se s tím vyrovnáme…