Praca z celem: /goal w Claude Code
Komenda /goal w Claude Code ustawia warunek zakończenia i utrzymuje sesję w pracy tura po turze, dopóki osobny mały, szybki model (w Claude API domyślnie Haiku) nie uzna warunku za spełniony lub niemożliwy, albo dopóki nie wyczyści go błąd, którego nie da się ponowić automatycznie. Pasuje do migracji, kryteriów akceptacji i innej pracy ze sprawdzalnym stanem końcowym.
Ta strona jest dla programistów, którzy prowadzą długie sesje Claude Code, i dla tech leadów, którzy chcą, żeby takie przebiegi kończyły się dowodem, a nie wrażeniem „chyba gotowe”. Sytuacja, którą rozwiązuje: od dwóch godzin prowadzisz migrację, a cała twoja praca sprowadza się do wpisywania „działaj dalej” po każdej turze. Zadanie jest jasne, meta oczywista, a mimo to każdy krok czeka na ciebie.
Co zyskujesz dzięki pracy z celem
Dział zatytułowany „Co zyskujesz dzięki pracy z celem”- Trzyczęściowy szablon warunku (stan końcowy, komenda dowodowa, ograniczenia), który ewaluator naprawdę potrafi ocenić.
- Cztery cele do skopiowania: migracja, kryteria akceptacji, budżet rozmiaru plików i triage zgłoszeń.
- Przepis na przebieg bez nadzoru przez
claude -pz twardym limitem wydatków i listą dozwolonych narzędzi. - Procedurę weryfikacji, która dowodzi wyniku bez czytania każdej zmienionej linii.
- Tabelę awarii, która łączy każdy sposób, w jaki cel utyka lub „kłamie”, z jego naprawą.
Kiedy /goal to właściwy sposób na podtrzymanie pracy Claude Code?
Dział zatytułowany „Kiedy /goal to właściwy sposób na podtrzymanie pracy Claude Code?”Używaj /goal, gdy stan końcowy da się sprawdzić, a droga do niego jest nieprzewidywalna. Cztery mechanizmy podtrzymują sesję bez twojego udziału. Różnią się tym, co uruchamia kolejną turę i co kończy przebieg.
| Mechanizm | Kolejna tura startuje, gdy | Przebieg kończy się, gdy | Sięgnij po niego, gdy |
|---|---|---|---|
/goal | Kończy się poprzednia tura (w sesjach interaktywnych także automatyczne ponowienia i check-iny w bezczynności) | Ewaluator zwraca „spełniony” lub „niemożliwy”, wystąpi błąd wymagający twojej naprawy albo uruchomisz /goal clear | Meta to wynik testów, kod wyjścia, liczba lub pusta kolejka |
/loop | Upływa interwał czasu | Zatrzymasz go albo Claude uzna pracę za skończoną | Odpytujesz stan zewnętrzny w stałym rytmie, np. CI albo deploy |
| Hook Stop w ustawieniach | Kończy się poprzednia tura | Decyduje twój skrypt lub prompt | Sprawdzenie ma być deterministyczne albo obejmować każdą sesję w danym zakresie |
| Tryb auto | Nigdy; działa wewnątrz jednej tury | Claude uzna turę za zakończoną | Chcesz mniej pytań o uprawnienia, a nie więcej tur |
Tryb auto i /goal się uzupełniają. Tryb auto usuwa pytania o pojedyncze narzędzia, /goal usuwa pytania po każdej turze i przekazuje decyzję „czy już skończone?” świeżemu modelowi zamiast temu, który wykonuje pracę. Uruchomienie z /goal to agentowy przepływ pracy: model pracuje nad zadaniem tura po turze, aż osobne sprawdzenie uzna je za zakończone. Jeśli zadanie przerasta jedną sesję, np. setki plików rozdzielonych między agentów, użyj dynamicznych workflowów. Jeśli ma działać według harmonogramu bez otwartego terminala, użyj rutyn (routines). Jeśli pętla ma przetrwać sesję, ze stanem na dysku i świeżym kontekstem w każdej iteracji, porównaj /goal z pętlą Ralph w przewodniku pętle autonomiczne.
Uruchom swój pierwszy cel
Dział zatytułowany „Uruchom swój pierwszy cel”-
Najpierw wybierz tryb uprawnień. Cel nie zmienia trybu uprawnień. W trybie Manual Claude nadal pyta przed każdym wywołaniem narzędzia, na które nie pozwalają twoje ustawienia, więc cel pozostawiony bez nadzoru utknie na pierwszym
npm test. Od v2.1.283 (kanał wydańlatest) interaktywne sesje w terminalu i w VS Code startują w trybie auto na każdym planie, chyba że plik ustawień ustawiadisableAutoModealbo sesja działa na modelu, którego tryb auto nie obsługuje, np. na Haiku. Na kanalestable(26 września 2026 r. była to v2.1.274) uruchom sesję jawnie, jeśli twój plan, dostawca i model obsługują tryb auto (zob. przewodnik po uprawnieniach podlinkowany niżej); w przeciwnym razie zezwól na polecenia celu jawnymi regułamiallow:Okno terminala # Terminalclaude --permission-mode autoZachowaj jawne reguły
deny; tryb auto nadal je respektuje. Pełną macierz trybów znajdziesz w przewodniku uprawnienia, sandboksy i tryby zatwierdzania. -
Zablokuj sprawdzenia, od których zależy cel. Cel „testy przechodzą” nagradza agenta, który edytuje testy. Zanim odejdziesz od komputera, dodaj do
.claude/settings.jsonregułydenydla katalogu testów. Początkowy/zakotwicza ścieżkę w katalogu głównym projektu:{"permissions": {"deny": ["Edit(/tests/**)", "Edit(**/*.test.ts)", "Edit(/vitest.config.ts)"]}}Reguły
denyobejmują narzędzia plikowe Claude, a nie polecenia powłoki, które zapisują pliki. Ochrona wyroczni dokłada warstwę sandboksa i hooków, która zamyka tę lukę. -
Ustaw cel. Uruchom
/goal, a po nim warunek o długości do 4000 znaków. Ustawienie celu od razu rozpoczyna turę, w której warunek jest poleceniem, więc nie wysyłasz osobnego promptu. Wskaźnik◎ /goal activepokazuje, jak długo cel trwa. W sesji aktywny jest jeden cel; nowe/goalzastępuje poprzedni. -
Obserwuj werdykty, nie diff. Transkrypt pokazuje każdy werdykt ewaluatora; Ctrl+O wyświetla jego uzasadnienie.
/goalbez argumentu pokazuje warunek, czas trwania, liczbę ocenionych tur, zużycie tokenów i ostatnie uzasadnienie. -
Zweryfikuj i zamknij. Gdy ewaluator zwróci „spełniony”, Claude Code czyści cel i zapisuje wpis o osiągnięciu. Ten werdykt to deklaracja, a nie dowód. Zanim zmergujesz, wykonaj kroki z sekcji Jak udowodnić wynik celu bez czytania każdej linii? Aby przerwać wcześniej, uruchom
/goal clear(aliasy:stop,off,reset,none,cancel); cel usuwa także/clear.
Cele do skopiowania, które wytrzymują wiele tur
Dział zatytułowany „Cele do skopiowania, które wytrzymują wiele tur”Każdy cel poniżej nazywa jeden stan końcowy, komendę, która go dowodzi, ograniczenia, które muszą przetrwać, i klauzulę stopu. Wklej go w prompt Claude Code i zmień ścieżki.
Cel triage potrzebuje narzędzia, które czyta i zapisuje zgłoszenia. Dodaj serwer MCP GitHuba raz na projekt, zgodnie z przewodnikiem konfiguracji GitHub MCP:
# Terminal. Apostrofy zostawiają ${GITHUB_PAT} nierozwinięte w .mcp.json.claude mcp add -s project --transport http github https://api.githubcopilot.com/mcp/ \ -H 'Authorization: Bearer ${GITHUB_PAT}'Ten cel zamyka zgłoszenia bez nadzoru, więc niech GITHUB_PAT będzie tokenem fine-grained z uprawnieniem Issues: read and write tylko do tego jednego repozytorium.
Jak napisać warunek, który ewaluator potrafi ocenić?
Dział zatytułowany „Jak napisać warunek, który ewaluator potrafi ocenić?”Ewaluator czyta wyłącznie rozmowę. Nie uruchamia komend i nie otwiera plików, więc warunek jest tyle wart, ile dowodów wypisze Claude. Każdy warunek zbuduj z trzech części, a potem dodaj klauzulę stopu.
| Część | Słabo | Mocno |
|---|---|---|
| Stan końcowy | „migracja jest zrobiona” | „npm run db:status nie zgłasza oczekujących migracji” |
| Dowód widoczny w transkrypcie | „testy przechodzą” | „npm test kończy się kodem 0, a linia podsumowania pokazuje 0 failed i 0 skipped” |
| Ograniczenia | brak | „nie edytuj package.json, lockfile’ów ani tests/” |
| Klauzula stopu | brak | „zatrzymaj się po 25 turach i wypisz, co zostało” |
Z konstrukcji ewaluatora wynikają trzy zasady:
- Wpisz komendę dowodową do warunku. Jeśli Claude edytuje pliki, ale nigdy nie uruchomi sprawdzenia, ewaluator nie ma czego przeczytać i tura po turze zwraca „jeszcze niespełniony”.
- Zamień gust na pomiar. „Kod jest czytelniejszy” nie da się ocenić z transkryptu. „Każdy plik w
src/utils/ma mniej niż 200 linii” już tak. - Traktuj klauzulę stopu jako miękką. „Stop after 25 turns” ocenia ewaluator na podstawie rozmowy; nie pilnuje tego żaden licznik. Twarde limity to
/goal clearw sesji i--max-budget-usdw przebieguclaude -p.
Jak Claude Code decyduje, że cel jest osiągnięty?
Dział zatytułowany „Jak Claude Code decyduje, że cel jest osiągnięty?”/goal to hook Stop oparty na prompcie, działający w obrębie sesji. Po każdej turze Claude Code wysyła warunek i dotychczasową rozmowę do małego, szybkiego modelu. W Claude API tym modelem jest Haiku; na Bedrocku, Google Cloud czy Foundry obowiązuje domyślny model dostawcy. Ewaluator zwraca jeden z trzech werdyktów, każdy z uzasadnieniem:
- Jeszcze niespełniony. Claude zaczyna kolejną turę i traktuje uzasadnienie jako wskazówkę.
- Spełniony. Claude Code czyści cel i zapisuje wpis o osiągnięciu.
- Niemożliwy. Claude Code czyści cel i zapisuje wpis o porażce wraz z uzasadnieniem.
Cztery zachowania zmieniają przebieg długiego celu:
- Wykrywanie zastoju. Jeśli Claude przez kilka tur z rzędu odpowiada ewaluatorowi bez użycia narzędzi, Claude Code zatrzymuje pętlę, wypisuje ostrzeżenie i oddaje ci sterowanie, zostawiając cel ustawiony. Ocena wraca po twoim następnym prompcie.
- Błędy, które musisz naprawić, czyszczą cel. Błąd uwierzytelniania (gdy Claude Code sam zarządza poświadczeniami), wyczerpane saldo kredytów, przepełnienie kontekstu, którego nie usunęła automatyczna kompakcja, albo niedostępny model powodują komunikat
Goal cleared after an unrecoverable error. Usuń przyczynę i ustaw cel ponownie. - Inne błędy ponawiają lub wstrzymują cel (v2.1.269+, sesje interaktywne). Przejściowe awarie, np. przeciążony serwer, są ponawiane automatycznie, z komunikatem
Goal still active; po trzech automatycznych ponowieniach cel zostaje wstrzymany. Limity zapytań, limity użycia i hook, który zakończył turę, dają komunikatGoal paused. - Praca w tle odracza ocenę. Dopóki działa subagent albo polecenie powłoki w tle, ocena czeka. Po 30 minutach oczekiwania check-in prosi Claude o przeczytanie wyjścia uruchomionych zadań oraz naprawienie lub zatrzymanie tych, które utknęły. Kolejne check-iny przychodzą rzadziej: po godzinie, a potem co 2 godziny. Sesja interaktywna uruchamia najwyżej trzy check-iny w bezczynności na cel między twoimi promptami.
CLAUDE_CODE_GOAL_CHECKIN_MINUTESzmienia pierwszy interwał;0wyłącza check-iny i automatyczne ponowienia.
Aby oceniać na innym modelu, ustaw ANTHROPIC_DEFAULT_HAIKU_MODEL. Ta zmienna zmienia też alias haiku i zadania w tle, np. streszczanie rozmowy, więc ustawiaj ją świadomie. Tokeny oceny są rozliczane według małego, szybkiego modelu; aktualne ceny znajdziesz w hubie modeli.
Jak udowodnić wynik celu bez czytania każdej linii?
Dział zatytułowany „Jak udowodnić wynik celu bez czytania każdej linii?”Werdykt „spełniony” oznacza, że mały model przeczytał transkrypt i w niego uwierzył. Traktuj go jako deklarację agenta i zweryfikuj dowodami, które od transkryptu nie zależą.
-
Uruchom decydujące sprawdzenie poza sesją. Wypchnij gałąź i pozwól CI uruchomić te same testy, sprawdzenie typów i linter. Zielony przebieg CI na czystym checkoucie jest dowodem; transkrypt nim nie jest.
-
Potwierdź, że ograniczenia wytrzymały. Uruchom
git diff --stat main...HEAD -- tests/ package.json(dopasuj ścieżki do swoich ograniczeń). Puste wyjście oznacza, że cel nie dotknął tego, czego obiecał nie ruszać. -
Przeglądaj według ryzyka, nie linia po linii. Uruchom
/code-reviewna gałęzi, a potem czytaj tylko pliki, które przegląd oznaczył, i wszystko, co dotyka uwierzytelniania, płatności lub usuwania danych. -
Dołącz dowody do pull requesta. Wklej do opisu końcowy status
/goal(warunek, liczba tur, zużycie tokenów) i link do CI. Pełny kontrakt definiuje pakiet dowodów.
Odpowiedzialność za zatwierdzenie zostaje przy programiście, który ustawił cel: to on jest autorem warunku, więc to on odpowiada za ocenę, czy warunek opisywał właściwy wynik. Tech lead, który standaryzuje cele w zespole, powinien przeglądać szablony warunków, a nie każdy diff, który z nich powstaje.
Uruchom cel bez nadzoru przez claude -p
Dział zatytułowany „Uruchom cel bez nadzoru przez claude -p”/goal działa w trybie nieinteraktywnym, w aplikacji desktopowej i przez Remote Control. Z -p pętla biegnie do końca w jednym wywołaniu. Sesja claude -p startuje w trybie uprawnień Manual, więc zezwól dokładnie na te narzędzia, których potrzebuje warunek, i ogranicz wydatki:
# Terminal albo zaufany job CI na twojej własnej gałęziclaude -p "/goal CHANGELOG.md has an entry for every PR merged since the v4.2.0 tag, \as listed by 'git log v4.2.0..HEAD --merges --oneline'. Do not edit any other file. \Stop after 15 turns." \ --allowedTools "Bash(git log *)" "Read" "Edit(/CHANGELOG.md)" \ --max-budget-usd 5 \ --output-format stream-json --verbose--max-budget-usdto twardy limit, którym klauzula tur nie jest; działa tylko z--print.- Przy domyślnym wyjściu tekstowym nic się nie wypisuje do końca przebiegu, więc długi cel wygląda na zawieszony.
--output-format stream-json --verboseemituje każdą wiadomość na bieżąco. - Ctrl+C przerywa przebieg, zanim cel się rozstrzygnie.
- W sesji nieinteraktywnej check-iny przychodzą tylko na końcu tury; nie ma check-inów w bezczynności.
Nigdy nie uruchamiaj celu na niezaufanym refie, np. pull requeście z forka, gdy w środowisku są sekrety: hooki projektu i serwery MCP działają z poświadczeniami joba. Bezpieczny wzorzec checkoutu pokazuje integracja z CI/CD.
Cel, który był aktywny w chwili zakończenia sesji, wraca każdą drogą wznowienia: --continue, --resume z ID sesji, nazwą lub ścieżką transkryptu oraz przez wybór sesji. Warunek się przenosi; licznik tur, zegar i bazowe zużycie tokenów się zerują. Cele osiągnięte lub wyczyszczone nie wracają.
Czego wymaga /goal?
Dział zatytułowany „Czego wymaga /goal?”Komenda /goal pojawiła się w Claude Code v2.1.139. Automatyczne ponowienia wymagają v2.1.269 lub nowszej, a check-iny w bezczynności v2.1.236 lub nowszej. Ponieważ ewaluator jest częścią systemu hooków, /goal podlega tej samej regule zaufania do workspace’u co hooki w plikach ustawień. Komenda jest niedostępna, gdy po zastosowaniu kolejności ustawień disableAllHooks ma wartość true albo gdy w ustawieniach zarządzanych ustawiono allowManagedHooksOnly. W każdym z tych przypadków komenda podaje powód, zamiast po cichu nic nie robić.
Kiedy /goal zawodzi w Claude Code
Dział zatytułowany „Kiedy /goal zawodzi w Claude Code”| Objaw | Przyczyna | Naprawa |
|---|---|---|
| Cel się nie kończy, choć praca wygląda na zrobioną | Claude nigdy nie wypisał dowodu, którego wymaga warunek | Wpisz komendę dowodową do warunku: „npm test exits 0 and its summary line is shown” |
| Ewaluator zwraca „spełniony” po jednym zielonym przebiegu | Warunek przyjmuje częściowe dowody | Wymagaj sum: „0 failed and 0 skipped across the whole suite” |
| Testy przechodzą, bo zmieniły się testy | Nic nie powstrzymało agenta przed edycją wyroczni | Dodaj reguły deny dla katalogu testów i ograniczenie „do not edit tests/”; sprawdź przez git diff --stat |
| Cel wyczyszczony jako niemożliwy | Warunek przeczy ograniczeniu albo komenda dowodowa nie może się udać w tym środowisku | Przeczytaj zapisane uzasadnienie, uruchom komendę dowodową sam, poluzuj sprzeczne ograniczenie i ustaw cel ponownie |
Goal cleared after an unrecoverable error | Uwierzytelnianie, saldo kredytów, przepełnienie kontekstu albo dostępność modelu | Usuń wskazaną przyczynę i uruchom /goal z tym samym warunkiem |
Goal paused | Limit zapytań, limit użycia, hook, który zakończył turę, albo trzy nieudane automatyczne ponowienia | Poczekaj na odnowienie limitu albo wyślij wiadomość, żeby wznowić od razu |
| Cel stoi bezczynnie, gdy działa subagent albo polecenie w tle | Ocena jest odroczona do zakończenia pracy w tle | Sprawdź /tasks, zatrzymaj zawieszone zadanie albo obniż CLAUDE_CODE_GOAL_CHECKIN_MINUTES; po trzech check-inach w bezczynności Claude Code wstrzymuje je do twojego następnego promptu |
| Pętla staje z ostrzeżeniem, a cel pozostaje ustawiony | Wykrycie zastoju: kilka tur bez użycia narzędzi | Wyślij prompt, który nazywa następny konkretny krok, albo przepisz warunek |
| Zużycie tokenów stale rośnie | Brak klauzuli stopu albo nieosiągalny stan końcowy | Uruchom /goal, żeby odczytać zużycie, potem /goal clear; w przebiegach -p zawsze podawaj --max-budget-usd |
/goal odmawia działania | Niezaufany workspace, disableAllHooks albo allowManagedHooksOnly | Zaakceptuj okno zaufania albo poproś właściciela ustawień zarządzanych o dopuszczenie hooków |