Polecenie /goal: autonomiczne uruchomienia sterowane celem
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 tego rozdziału
Dział zatytułowany „Co wyniesiesz z tego rozdziału”- Co
/goalfaktycznie robi i jak kończy się pętla planuj → działaj → testuj → przeglądaj - Jak dokładnie włączyć je i sterować nim w Claude Code oraz w Codeksie
- Po co sięgnąć w Cursorze, który nie ma natywnego
/goal - 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. 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 ocenia warunek zakończenia po każdej rundzie i kończy bieg, gdy jest spełniony.
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 (kwiecień 2026) jako funkcja eksperymentalna i jest dziś udokumentowanym przypadkiem użycia. Włącz je raz, a potem poprzedzaj nim swoją pracę.
Włącz w config.toml:
[features]goals = trueAlbo z powłoki:
codex features enable goalsNastępnie steruj nim:
/goal zmigruj każdą trasę w src/api do nowej sygnatury handlera;gotowe, gdy npm test i npm run typecheck przechodząKontroluj bieg poleceniami /goal (pokaż bieżący cel), /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.
Cursor nie ma natywnego polecenia /goal — prośba społeczności o „tryb Goal jak w Claude Code” jest otwarta od połowy 2026. Dwie istniejące funkcje pokrywają część tej roli:
- Tryb Agent uruchamia autonomiczne, wieloetapowe zadania wewnątrz IDE: 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. Zatrzymuje się, gdy potrzebuje twojego wejścia.
- Automations uruchamiają agenta według harmonogramu lub w reakcji na zdarzenia (zapisy plików, commity, niepowodzenia testów), co bardziej pokrywa się z
/loopniż z/goal.
Aby uzyskać dziś w Cursorze prawdziwą pętlę sterowaną celem, albo sterujesz trybem Agent ręcznie, albo instalujesz skill społeczności odtwarzający ten wzorzec.
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.