Polecenie /goal: autonomiczne uruchomienia sterowane celem

Polecenie /goal daje agentowi kodującemu cel ze sprawdzalną linią mety i utrzymuje go w pracy tura po turze, dopóki cel nie zostanie spełniony, nie zatrzyma go budżet lub limit albo dopóki go nie wyczyścisz. Claude Code, Codex i Cursor mają /goal, ale różnią się tym, kto orzeka o zakończeniu pracy, a od tego zależy, na ile możesz ufać wynikowi.

Ta strona jest dla programistów, którzy prowadzą długie sesje z agentem, i dla tech leadów, którzy chcą, żeby takie sesje kończyły się dowodami. Od trzech godzin prowadzisz migrację. Agent kończy turę, przeglądasz diff, wpisujesz „kontynuuj”, a on kończy kolejną. Linia mety jest oczywista („wszystkie miejsca wywołań zmigrowane, wszystkie testy zielone”), a mimo to każdy krok czeka, aż naciśniesz Enter.

Co wyniesiesz z pracy z /goal

• Zestawienie, jak /goal działa w Claude Code, Codeksie i Cursorze oraz kto w każdym z nich orzeka „gotowe”
• Polecenia do uruchamiania, podglądu, wstrzymywania i czyszczenia celu w każdym narzędziu
• Trzy cele do skopiowania, które kończą się czysto, oraz prompt audytu zakończonego przebiegu
• Czterokrokową kontrolę, która dowodzi wyniku bez czytania każdej zmienionej linii
• Tabelę awarii: co zatrzymuje lub oszukuje przebieg z celem i jak z tego wyjść

Jak /goal rozstrzyga, że przebieg się zakończył?

Zwykła tura agenta kończy się, gdy model uzna, że powiedział dość. /goal zastępuje to warunkiem i pętlą: agent planuje krok, wprowadza zmianę, uruchamia twoje sprawdzenia, a potem „coś” pyta: „czy warunek jest spełniony?”. Jeśli nie, następna tura startuje bez ciebie.

Tym „czymś” narzędzia się różnią:

	Claude Code	Codex	Cursor
Kto orzeka „gotowe”	Osobny mały, szybki model (domyślnie Haiku na Claude API) czyta transkrypt po każdej turze	Ten sam agent, który wykonuje pracę, przeprowadza wbudowany audyt ukończenia i sam oznacza cel jako zakończony	Nieudokumentowane (sprawdzone 28.08.2026)
Werdykty	niespełniony · spełniony · niemożliwy	complete · blocked (agent); paused (ty); stalled, usage-limited, budget-limited (środowisko uruchomieniowe)	—
Sterowanie	/goal <warunek>, /goal, /goal clear	/goal <cel>, /goal, /goal edit, /goal pause, /goal resume, /goal clear	/goal [cel]
Kończy się sam, gdy	cel jest spełniony albo uznany za niemożliwy (cel usunięty); wystąpi błąd, który musisz naprawić (cel usunięty); wykrycie zastoju albo limit użycia wstrzymuje go, a cel pozostaje ustawiony	agent oznaczy cel jako complete; ta sama blokada powtórzy się w trzech kolejnych turach (blocked); wyczerpie się limit użycia albo budżet tokenów celu	—
Bez próśb o zatwierdzenie	claude -p "/goal …"	Sesja interaktywna z --approve-for-me (w codex exec 0.157.1 nie potwierdzono bezobsługowej formy /goal)	Sprawdź w swoim buildzie
Dostępne od	v2.1.139	goals stabilne i domyślnie włączone w 0.157.1	19.08.2026, z adnotacją „Rolling out” (nadal, sprawdzone 12.10.2026)

Źródła: dokumentacja /goal w Claude Code (sprawdzone 26.09.2026, CLI 2.1.283); w Codeksie codex features list i prompty celu wbudowane w binarkę codex-cli 0.157.1 (sprawdzone 26.09.2026); referencja poleceń CLI Cursora (sprawdzone 28.08.2026).

Wynikają z tego dwie rzeczy. W Claude Code ewaluator nie uruchamia poleceń ani nie czyta plików: ocenia wyłącznie to, co agent wypisał. W Codeksie sędzia i wykonawca to ten sam model, więc nawet dobrze sformułowany audyt pozostaje samooceną. W Cursorze nic udokumentowanego w ogóle nie sprawdza celu. We wszystkich trzech niezależny dowód musi przyjść z zewnątrz: z polecenia testowego, hooka albo CI. Sekcja o dowodzie poniżej pokazuje, jak to zrobić.

Uruchom przebieg z celem w każdym narzędziu

Claude Code

1. Najpierw wybierz tryb uprawnień. Cel nie zmienia trybu uprawnień, więc sesja w trybie Manual zatrzyma się na pierwszym niezatwierdzonym npm test. Sesje interaktywne od v2.1.283 (oba kanały wydań w dniu 2026-10-12) startują w trybie auto, chyba że ustawienia go wyłączają albo model go nie obsługuje. claude -p startuje w trybie Manual, poza zewnętrznymi dostawcami i wyłączoną telemetrią, gdzie od v2.1.285 startuje w trybie auto. Zobacz uprawnienia, sandboksy i tryby zatwierdzania.

2. Ustaw cel. Wpisz /goal i warunek (do 4000 znaków). Pierwsza tura startuje od razu; nie wysyłasz osobnego promptu. W sesji aktywny jest jeden cel, a nowy zastępuje poprzedni.

3. Obserwuj werdykty. Każdy werdykt ewaluatora pojawia się w transkrypcie; Ctrl+O pokazuje jego uzasadnienie. /goal bez argumentu pokazuje warunek, czas trwania, liczbę ocenionych tur, zużycie tokenów i ostatnie uzasadnienie.

4. Zatrzymaj albo wznów. /goal clear usuwa cel. Cel aktywny w chwili zakończenia sesji wraca po --continue lub --resume, a licznik tur, zegar i punkt odniesienia tokenów zerują się.

Do przebiegu bez nadzoru na własnej gałęzi zezwól tylko na narzędzia potrzebne warunkowi i ogranicz wydatki:

# Terminal, na gałęzi, którą posiadasz
claude -p "/goal every file under src/components imports useAppStore, not useStore; \
'npm run typecheck' exits 0 and 'npm test' shows 0 failed. Do not edit tests/. \
Stop after 25 turns." \
  --allowedTools "Read,Edit,Bash(npm test *),Bash(npm run typecheck *)" \
  --max-budget-usd 10 \
  --output-format stream-json --verbose

--max-budget-usd działa tylko z -p i jest twardym limitem, którym klauzula „stop after 25 turns” nie jest. Bez stream-json nic się nie wypisuje aż do końca przebiegu. /goal należy do systemu hooków, więc jest niedostępne w niezaufanej przestrzeni roboczej oraz gdy ustawiono disableAllHooks albo zarządzane allowManagedHooksOnly; polecenie mówi wtedy dlaczego. Pełny opis dla Claude Code znajdziesz w przepływach pracy z /goal w Claude Code.

Codex

1. Sprawdź, czy cele są włączone. Uruchom codex features list; domyślna instalacja codex-cli 0.157.1 zgłasza goals stable true. Jeśli ktoś wykonał codex features disable goals, cofnij to przez codex features enable goals.

2. Uruchom izolowaną sesję z automatycznym przeglądem zatwierdzeń. --worktree trzyma przebieg z dala od twojego drzewa roboczego, a --approve-for-me kieruje prośby o zatwierdzenie do automatycznego przeglądu w sandboksie workspace-write, więc cel nie czeka na ciebie przy każdym poleceniu:

   # Terminal, w repozytorium
   codex --worktree --approve-for-me

3. Ustaw cel. W sesji wpisz /goal i cel. Codex śledzi względem niego zużyte tokeny i czas.

4. Steruj nim. /goal pokazuje stan i zużycie; /goal edit przepisuje cel w miejscu; /goal pause i /goal resume wstrzymują go i wznawiają; /goal clear go usuwa.

Codex sam rozstrzyga o ukończeniu. Jego instrukcje celu (0.157.1) każą agentowi traktować ukończenie jako nieudowodnione, przypisać każdemu wymaganiu z celu dowód, taki jak wynik polecenia czy testów, i oznaczyć cel jako zakończony dopiero wtedy, gdy dowody pokrywają wszystkie wymagania. Status blocked agent nadaje dopiero wtedy, gdy ta sama blokada powtórzy się w trzech kolejnych turach celu. TUI zgłasza Goal paused, Goal stalled albo zatrzymanie z powodu limitu użycia; każde z nich wznowisz przez /goal resume. Cel może też mieć budżet tokenów, a gdy ten się wyczerpie, tura kończy się komunikatem Goal budget reached.

Skoro wykonawca ocenia sam siebie, wpisz polecenia dowodowe do celu i uruchom je ponownie poza sesją.

Cursor

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 i ponownie 12.10.2026; wprowadził je changelog z 19.08.2026). Dostępność zależy od builda, więc zanim zaplanujesz na nim pracę, sprawdź, czy polecenie jest w /help.

1. Sprawdź, czy twój build je ma. Uruchom /help w Cursor CLI i poszukaj /goal.

2. Wpisz bramkę do celu. Referencja Cursora nie opisuje ewaluatora (sprawdzone 28.08.2026), więc o zatrzymaniu decyduje ten sam agent, który wykonuje pracę. Podaj dokładne polecenie dowodzące ukończenia i poproś o jego wynik jako ostatni krok.

3. Dodaj deterministyczną bramkę poza agentem. Wiarygodność wynikowi daje wymagane sprawdzenie w CI albo przebieg testów przed scaleniem, a nie sformułowanie celu.

Do pracy cyklicznej Cursor ma /loop jako wbudowany skill (Cursor 3.5, 20.05.2026), a do harmonogramów i wyzwalaczy zdarzeń w chmurze — Automations (Scheduled, Source control, Slack, Webhook, Linear, Sentry, PagerDuty; sprawdzone 28.08.2026). Oba opisują polecenie /loop i porównanie agentów w tle i w chmurze.

Jak napisać cel, który agent potrafi ukończyć?

O przebiegu decydujesz, zanim się zacznie — w warunku. Większość ciężaru niesie pięć zasad:

1. Jeden cel, jedna linia mety. „Zmigruj API i popraw pokrycie” daje sędziemu dwa cele, a przebieg miota się między nimi. Rozbij to na dwa cele.
2. Niech linią mety będzie polecenie. „Wygląda dobrze” nie da się sprawdzić; „npm test pokazuje 0 failed i 0 skipped” już tak. W Claude Code ewaluator widzi tylko wynik, więc poproś o wypisanie linii podsumowania.
3. Wskaż, co definiuje poprawność. Podaj specyfikację, przewodnik migracji i jeden już zmigrowany plik. Agent, który zgaduje cel, błądzi.
4. Napisz, czego nie wolno zmieniać. „Nie edytuj tests/” i „Nie dotykaj src/auth/” to ograniczenia, które pętla łamie jako pierwsze, gdy test trudno spełnić.
5. Ogranicz przebieg. Dodaj klauzulę tur lub czasu („stop after 25 turns”), a w przebiegach claude -p limit --max-budget-usd.

Cel do skopiowania: migracja API z bramką zgodności

/goal Every file under src/components/ imports useAppStore instead of useStore.
Read docs/migration/store.md and the migrated example src/components/Header.tsx first.
Done when: `grep -rl "useStore" src/components` prints nothing, `npm run typecheck`
exits 0, and `npm test` shows 0 failed and 0 skipped. Print each command's summary
line as proof. Do not edit anything under tests/ or src/store/. After each turn,
append one line to MIGRATION_LOG.md: files migrated, files left. Stop after 25 turns.

Cel do skopiowania: naprawa błędu, który umiesz odtworzyć

/goal `npm test -- tests/checkout/rounding.test.ts` passes, and the full suite
still shows 0 failed. The bug: orders with three or more discount lines total
one cent too high. First write a failing test that reproduces it, show it failing,
then fix the cause in src/checkout/. Do not change existing assertions. Print the
failing run and the passing run. Stop after 15 turns and report the root cause.

Cel do skopiowania: kryteria akceptacji ze specyfikacji

/goal Every acceptance criterion in specs/export-csv.md is met, each one proved by
a named test in tests/export/ that you show passing. Done when `npm test --
tests/export` shows 0 failed, `npm run lint` exits 0, and you print a table mapping
each criterion to its test name. Do not change specs/export-csv.md. If a criterion
is ambiguous, stop and list the question instead of guessing.

Samo pisanie kryteriów opisuje strona o kryteriach akceptacji, które agent potrafi zweryfikować.

Jak udowodnić, że przebieg z celem wykonał zadanie?

Werdykt „spełniony” czy „complete” to deklaracja agenta, oceniona na podstawie jego własnego transkryptu. Udowodnij ją dowodami, których pętla nie mogła wytworzyć sama:

1. Uruchom bramkę ponownie poza sesją. Wypchnij gałąź i pozwól CI uruchomić te same testy, sprawdzenie typów i lint na czystym checkoucie. Dowodem jest ten przebieg, a nie transkrypt.

2. Sprawdź, czy ograniczenia wytrzymały. Uruchom w terminalu; dopasuj ścieżki do tego, czego cel obiecywał nie ruszać:

   git diff --stat main...HEAD -- tests/ src/store/ package.json

   Pusty wynik oznacza, że wyrocznia testowa i chroniony kod są nietknięte. Pętle świetnie zazieleniają testy, osłabiając je; ochrona wyroczni dodaje reguły deny i hooki, które blokują to u źródła.

3. Przeglądaj według ryzyka, nie linia po linii. Uruchom agenta przeglądu na gałęzi, a potem czytaj tylko to, co oznaczy, oraz wszystko, co dotyka uwierzytelniania, płatności lub usuwania danych.

4. Dołącz dowody. Wklej do pull requesta końcowy stan celu (warunek, tury, zużycie tokenów), link do CI i wynik git diff --stat. Pełny kontrakt definiuje pakiet dowodowy.

Zatwierdza programista, który ustawił cel: to on odpowiada za warunek i za ocenę, czy opisywał właściwy rezultat. Tech lead standaryzujący przebiegi z celem przegląda szablony warunków i bramki, a nie każdy diff, który z nich powstaje.

Prompt do skopiowania: audyt zakończonego przebiegu

The goal reported complete. Before I merge, prove it independently. Report only;
do not fix anything.
1. Run `git diff --stat main...HEAD` and list every file changed outside the paths
   the goal allowed.
2. Run the full test suite, the type check and the linter from scratch, and show
   each summary line.
3. List every test you added, deleted, skipped or whose assertions changed, with
   the reason for each.
4. For each requirement in the goal, name the evidence that proves it, or say
   "not proven".

Uruchom audyt w nowej sesji albo w innym narzędziu, żeby model, który wykonał pracę, nie był tym, który ją ocenia.

Kiedy użyć /goal zamiast /loop albo frameworka?

Potrzebujesz	Użyj	Dlaczego
Pracy zbieżnej do sprawdzalnego stanu końcowego w jednej sesji	/goal	Wbudowane, ograniczone, z werdyktem po każdej turze
Tego samego promptu w rytmie: odpytywanie wdrożenia, pilnowanie PR	/loop	Działa w interwale, bez jednej linii mety
Deterministycznego sprawdzenia po każdej turze, w każdej sesji	Hook Stop (automatyzacja hookami)	Decyduje skrypt, a nie model
Nocnych buildów przez wiele sesji ze stanem na dysku	Pętle autonomiczne (Ralph, GSD Core)	Przetrwają wiele sesji; wymagają sandboksa
Pracy, która trwa przy zamkniętym laptopie	Agenci w tle i w chmurze	Routines, Codex cloud i automatyzacje, Cursor Cloud Agents

Częste połączenie: przebieg /goal doprowadza funkcję do „testy zielone”, a potem /loop pilnuje powstałego pull requesta pod kątem awarii CI i komentarzy z przeglądu.

Co psuje przebiegi z /goal i jak z tego wyjść?

Objaw	Przyczyna	Wyjście
Cel nigdy się nie kończy, choć praca wygląda na skończoną	Agent nie wypisał dowodu, którego wymaga warunek	Wpisz polecenie dowodowe do warunku i poproś o linię podsumowania
Przebieg melduje koniec po jednym zielonym pliku testów	Warunek akceptuje częściowe dowody	Wymagaj sum: „0 failed i 0 skipped w całym zestawie”
Testy przechodzą, bo zmieniły się testy	Nic nie chroniło wyroczni	Dodaj „nie edytuj tests/” i reguły deny; sprawdź przez git diff --stat
Claude Code czyści cel jako niemożliwy	Warunek przeczy ograniczeniu albo polecenie dowodowe nie może się tu powieść	Przeczytaj zapisane uzasadnienie, uruchom polecenie sam, usuń sprzeczność, ustaw cel ponownie
Codex pokazuje Goal stalled albo oznacza cel jako blocked	Ta sama blokada powtarzała się przez kolejne tury	Usuń blokadę (brakujący sekret, niedziałająca usługa), potem /goal resume albo /goal edit, by zawęzić cel
Przebieg czeka przy każdym poleceniu	Tryb Manual albo brak przeglądu zatwierdzeń w Codeksie	Tryb auto w Claude Code albo --approve-for-me w Codeksie, w sandboksie
Zużycie tokenów stale rośnie	Brak klauzuli stopu albo nieosiągalny stan końcowy	Sprawdź zużycie przez /goal, potem /goal clear; w przebiegach claude -p zawsze podawaj --max-budget-usd
Przebieg w Cursorze kończy się wcześnie i melduje sukces	Brak udokumentowanego ewaluatora; zdecydował wykonawca	Uruchom ponownie polecenie bramki i pozwól rozstrzygnąć CI

Uruchamiaj cele bez nadzoru tam, gdzie szkody są ograniczone

Pętla z celem zrobi wszystko, co zadowoli jej sędziego. Uruchamiaj ją na gałęzi lub w worktree, w sandboksie, bez produkcyjnych poświadczeń w środowisku, i napisz w warunku, czy agent może pushować, usuwać lub wdrażać. Nigdy nie łącz /goal z --dangerously-skip-permissions ani --dangerously-bypass-approvals-and-sandbox poza jednorazowym sandboksem z ograniczoną siecią.

Dokąd dalej po przebiegach sterowanych celem

Przepływy pracy z /goal w Claude Code Pogłębienie dla Claude Code: check-iny, ponowienia, model ewaluatora i koszt.

Polecenie /loop Prompty uruchamiane w rytmie: odpowiednik /goal oparty na interwale.

Godziny autonomii: pętle autonomiczne Pętle Ralph, GSD Core i nocne buildy w sandboksie.

Ochrona wyroczni Nie pozwól pętli przejść testów przez ich edycję.