Polecenie /goal: autonomiczne uruchomienia sterowane celem
Polecenie /goal daje agentowi kodującemu cel i weryfikowalny warunek zakończenia zamiast pojedynczego promptu, po czym samodzielnie prowadzi pętlę planuj-działaj-testuj-przeglądaj, aż kontroler potwierdzi spełnienie warunku albo wyczerpie się budżet. Claude Code, Codex i Cursor dokumentują je jako polecenie pierwszej kategorii, choć w Cursorze wciąż jest oznaczone jako wdrażane.
Jesteś trzy godziny w migracji. Agent kończy turę, czytasz diff, wpisujesz „dobrze, kontynuuj”, kończy kolejną turę, znów wpisujesz „kontynuuj”. Już nie kierujesz pracą — jesteś zegarem, który mówi tik. Zadanie jest jasne, warunek zakończenia oczywisty („wszystkie testy zielone, wszystkie miejsca wywołań zmigrowane”), a mimo to każdy krok czeka, aż naciśniesz enter.
Polecenie /goal usuwa cię z tej pętli. Dajesz agentowi jeden cel i jedną weryfikowalną linię mety, a on pracuje dalej — planuje, działa, testuje, przegląda — dopóki kontroler nie potwierdzi, że cel został osiągnięty, albo dopóki nie wyczerpie się budżet. Twoja rola przesuwa się z wpisywania każdego kroku na projektowanie linii mety.
Co wyniesiesz z /goal
Dział zatytułowany „Co wyniesiesz z /goal”- Co
/goalfaktycznie robi i jak kończy się pętla planuj → działaj → testuj → przeglądaj - Jak dokładnie sterować nim w Claude Code oraz w Codeksie i czego każde z nich wymaga
- Czym
/goalw Cursorze różni się od dwóch pozostałych i czego jego dokumentacja nie obiecuje - Jak napisać cel i warunek zakończenia, które agent jest w stanie zweryfikować
- Kiedy
/goalto właściwe narzędzie, a kiedy/loop
Co /goal faktycznie robi
Dział zatytułowany „Co /goal faktycznie robi”Zwykła tura agenta kończy się, gdy model uzna, że powiedział wystarczająco dużo. /goal zastępuje to jawnym, sprawdzalnym warunkiem. Pod spodem działa pętla:
- Planuj — ustal następny konkretny krok w stronę celu.
- Działaj — wprowadź zmianę.
- Testuj — uruchom zdefiniowane przez ciebie polecenia walidacyjne.
- Przeglądaj — kontroler pyta „czy warunek zakończenia jest spełniony?”. Jeśli nie — wraca do planowania. Jeśli tak — zatrzymuje się.
Ten wzorzec ma starszy przydomek — „pętla Ralpha” — od pomysłu, by podawać agentowi ten sam cel, aż osiągnie zbieżność. Różnica z /goal polega na tym, że pętla, kontroler i budżet są wbudowane w narzędzie, zamiast być czymś, co skryptujesz ręcznie.
Całość stoi i upada na warunku zakończenia. „Spraw, żeby aplikacja była lepsza” nigdy się nie kończy. „Każdy test w tests/ przechodzi, a npm run typecheck zwraca 0” kończy się w chwili, gdy staje się prawdą.
Wsparcie w narzędziach
Dział zatytułowany „Wsparcie w narzędziach”/goal jest wbudowane i jest tak od wersji 2.1.139. Ustaw cel poleceniem /goal <cel>, a sesja pracuje dalej tura po turze, aż cel zostanie spełniony, zamiast zatrzymywać się po jednej odpowiedzi. Szybki model-kontroler — domyślnie Haiku na API Anthropic — ocenia warunek zakończenia po każdej rundzie i kończy bieg, gdy jest spełniony. Warunki mogą mieć do 4000 znaków; w sesji aktywny jest jeden cel, a nowy zastępuje poprzedni.
O tym, czy polecenie w ogóle zadziała, decydują dwa szczegóły mechaniczne. /goal jest zaimplementowane jako hook Stop oparty na prompcie i związany z sesją, więc działa tylko w przestrzeniach roboczych, w których zaakceptowałeś okno zaufania, i jest niedostępne, gdy disableAllHooks jest ustawione na dowolnym poziomie ustawień albo allowManagedHooksOnly w ustawieniach zarządzanych. W każdym z tych przypadków polecenie mówi ci dlaczego, zamiast po cichu nic nie robić.
Cel aktywny w chwili zakończenia sesji zostaje przywrócony przez --resume lub --continue — warunek przechodzi dalej, a licznik tur, zegar i punkt odniesienia dla tokenów zerują się. Działa też bezgłowo, i to jest forma warta zapamiętania dla CI:
claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"Używaj go, gdy praca rozciąga się na wiele tur w stronę warunku, który potrafisz precyzyjnie opisać — migracja ze sprawdzeniami parzystości, refaktoryzacja zabramkowana zestawem testów, bug, który odtwarzasz jednym poleceniem. Aby uruchamiać w interwale zamiast w stronę warunku, użyj /loop; aby działać bez nadzoru na infrastrukturze Anthropic, użyj Routines.
/goal pojawiło się w Codex CLI 0.128.0 (30 kwietnia 2026) za flagą funkcji, a 0.133.0 (21 maja 2026) uczyniło cele stabilnymi i domyślnie włączonymi, opartymi na dedykowanym magazynie śledzącym postęp między aktywnymi turami. Na każdym aktualnym buildzie nie ma nic do skonfigurowania — po prostu użyj polecenia:
/goal zmigruj każdą trasę w src/api do nowej sygnatury handlera;gotowe, gdy npm test i npm run typecheck przechodząZweryfikuj przez codex features list, które na domyślnej instalacji raportuje goals stable true. Blok [features] goals = true w config.toml oraz codex features enable goals są dziś potrzebne tylko po to, by cofnąć jawne codex features disable goals, albo na buildzie starszym niż 0.133.0 — nie są warunkiem wstępnym konfiguracji, choć część poradników z zewnątrz wciąż przedstawia je jako taki. Sprawdzone 28.08.2026 względem learn.chatgpt.com/docs/developer-commands: /goal jest tam wypisane jako “Set, edit, pause, resume, view, or clear a task goal”, a /loop w tej referencji nie występuje.
Kontroluj bieg poleceniami /goal (pokaż bieżący cel), /goal edit (popraw go w miejscu, dodane w 0.131.0), /goal pause, /goal resume i /goal clear. Codex sam zapętla planuj → działaj → testuj → przeglądaj i potrafi pracować godzinami bez udziału człowieka, aż twój warunek zostanie spełniony albo wyczerpie się tygodniowy limit. Od 0.132.0 kontynuacja zatrzymuje się, gdy trafi na limit użycia albo dwa razy na tę samą blokadę, zamiast zapętlać się i przepalać tokeny, a 0.147.0 pokazuje zablokowany cel w TUI jako stalled.
W odróżnieniu od wersji z Claude Code, związanej z sesją, cele w Codeksie są trwałe: krążą przez app-server, przeżywają --resume i można je wstrzymać na jednej maszynie, a wznowić na innej.
Referencja CLI Cursora opisuje /goal [objective] jako “Give the agent a long-lived objective to work towards until it’s fully complete. Rolling out.” — sprawdzone 28.08.2026 względem cursor.com/docs/cli/reference/slash-commands. Dopisek “Rolling out” jest częścią samej pozycji, więc traktuj dostępność jako zależną od builda i upewnij się, że polecenie pojawia się w twoim /help, zanim zaczniesz je oskryptowywać. Wcześniejsza wersja tego artykułu mówiła, że Cursor nie ma /goal; było to prawdą dla Cursora 3.5 i od tego czasu się zmieniło.
Dwóch rzeczy ta referencja nie daje, a obie zmieniają zachowanie biegu:
- Brak udokumentowanego kontrolera. Claude Code i Codex oceniają warunek zakończenia osobnym wywołaniem modelu po każdej turze. Pozycja Cursora opisuje cel i nic, co go sprawdza, więc decyzję o zakończeniu zostawia agentowi wykonującemu pracę. Gdy warunek musi być sprawdzony niezależnie, lekarstwem jest deterministyczna bramka — polecenie testowe, hook, zadanie CI — a nie lepiej sformułowany cel.
/loopto skill, nie polecenie. Nie występuje w referencji poleceń CLI Cursora (sprawdzone 28.08.2026), ale Cursor 3.5 (20 maja 2026) dostarcza go jako dołączony skill: „run a prompt repeatedly on a local schedule, until a certain outcome is achieved, or until you stop it” — zobacz przewodnik po /loop. Do rytmu po stronie chmury — odpytywania deploya, pilnowania PR-a przy zamkniętym laptopie — odpowiedzią Cursora są Automations, które uruchamiają agenty w chmurze w tle, według harmonogramu albo w reakcji na zdarzenia z GitHuba, GitLaba, Slacka, webhooków, Lineara i innych.
Tryb Agent zostaje alternatywą w IDE do pracy wieloetapowej: planuje, edytuje wiele plików, uruchamia polecenia w terminalu i iteruje — ale jest zbudowany wokół rozumowania w kontekście z podglądem diffów, a nie wokół biegu bez nadzoru względem budżetu tokenów, i zatrzymuje się, gdy potrzebuje twojego wejścia.
Pisanie celu, który agent potrafi dokończyć
Dział zatytułowany „Pisanie celu, który agent potrafi dokończyć”O jakości autonomicznego biegu decyduje to, jak sformułujesz cel, jeszcze zanim się zacznie. Pięć reguł odpowiada za większość efektu:
- Jeden cel, jeden warunek zakończenia. Połączenie „zmigruj API i popraw pokrycie testami” daje kontrolerowi dwie linie mety, między którymi będzie miotać. Rozbij je na dwa biegi.
- Niech warunek będzie poleceniem. „Wygląda dobrze” nie jest sprawdzalne;
npm testzwracające 0 — jest. Daj agentowi dokładne polecenia walidacyjne, które dowodzą postępu — stają się bramką, którą każda iteracja musi przejść. - Wskaż, co przeczytać najpierw. Wymień pliki, plan albo dokumentację, które definiują „poprawnie”. Agent, który musi zgadywać cel, błądzi.
- Poproś o punkty kontrolne. Zażądaj krótkiego logu postępu w każdej rundzie. Daje ci to miejsce, w którym możesz przerwać, i czyni długi bieg audytowalnym po fakcie.
- Ogranicz zasięg rażenia. Określ, co jest poza zakresem i czego agent nigdy nie może tknąć. Pętla bez granic z radością zrefaktoryzuje twoją warstwę autoryzacji, żeby przeszedł jakiś test.
/goal kontra /loop
Dział zatytułowany „/goal kontra /loop”Brzmią podobnie, a rozwiązują różne problemy:
/goaldziała dopóki warunek nie stanie się prawdą. Harmonogram brzmi „tak szybko, jak się da, aż do końca”. Sięgaj po nie do pracy zbieżnej z jasną linią mety./loopdziała w rytmie. Harmonogram brzmi „co N minut” (albo w samodzielnie dobranym interwale). Sięgaj po nie do otwartego monitorowania — odpytywania deploya, pilnowania PR-a — gdzie może nie być jednej linii mety.
Częste połączenie: bieg /goal doprowadza funkcję do „testy zielone”, a potem /loop pilnuje powstałego PR-a pod kątem niepowodzeń CI i komentarzy z przeglądu.