/goal w Claude Code: tryb autonomiczny i Agent View w 2026

Dokumentacja referencyjna Ailoot: ailoot.ai/docs/.

Czym jest /goal w Claude Code?#

Wcześniej Claude Code zatrzymywał się po każdej odpowiedzi i czekał na następne polecenie. Sprawdzało się to przy krótkich zadaniach, ale zawodziło przy długich: migracja API, naprawa 12 niezaliczonych testów, refaktoryzacja pliku liczącego 800 wierszy — takie zadania wymagają 20–30 iteracji, a każda z nich zmuszała do powrotu do terminala.

/goal rozwiązuje ten problem prostą ideą: oddziela „tego, kto wykonuje pracę”, od „tego, kto decyduje, kiedy jest ukończona”. Główny agent pisze kod. Osobny ewaluator (szybki model Haiku) po każdej turze odczytuje rozmowę i odpowiada na jedno pytanie: „Czy warunek został spełniony?”. Jeśli nie, agent rozpoczyna kolejną turę. Jeśli tak, sterowanie wraca do Ciebie.

Oficjalna dokumentacja Anthropic definiuje to tak:

Claude Code w Anthropic opisano w wywiadzie z 4 maja 2026 r.:

Tysiące agentów uruchomionych nocą z telefonu — to nie marketing, lecz obecna praktyka inżyniera Anthropic. Mechanizmem, który to umożliwia, jest połączenie /goal + Agent View, wprowadzone w tej samej wersji 11 maja 2026 r.

Dlaczego potrzebny jest tryb autonomiczny: co było przed 11 maja 2026 r., a co po tej dacie?#

Pomysł „pozostawienia AI do pracy na noc” istniał już od jesieni 2025 r., gdy Cursor Composer i tryb auto w Cline potrafiły już działać w tle. Jednak przed 11 maja 2026 r. Claude Code wymagał do tego ręcznego skryptu: zadania cron wywołującego claude -p co N minut albo skryptu obserwującego status gita i uruchamiającego kolejne polecenie.

To samodzielne podejście regularnie prowadziło do katastrof. 22 maja 2026 r. programista zostawił taki skrypt uruchomiony na noc i obudził się z rachunkiem na 6000 $. Przyczyna: Anthropic po cichu zmienił TTL pamięci podręcznej Claude Code z jednej godziny na pięć minut, nie ogłaszając tego. Cron wywoływał produkcyjne środowisko co 30 minut — pamięć podręczna zdążyła wygasnąć między uruchomieniami. Każde uruchomienie odtwarzało od zera historię liczącą 800 000 tokenów. Zapis świeżych danych do pamięci podręcznej kosztuje znacznie więcej niż odczyt z aktywnej pamięci.

Programista nie robił niczego niezwykłego — korzystał z narzędzia dokładnie tak, jak reklamowało je Anthropic.

/goal rozwiązuje ten problem dzięki wbudowanej architekturze:

1. Proces nadzorujący, który utrzymuje sesję poza terminalem i działa dalej po zamknięciu okna oraz uśpieniu laptopa.
2. Ewaluator Haiku — niedrogi model sprawdza każdą turę; tokeny ewaluatora kosztują grosze.
3. Twardy limit tur w warunku — możesz jawnie wpisać or stop after 20 turns, a sesja na pewno się zatrzyma.
4. Izolacja w worktree dla sesji działających w tle — zmiany trafiają do osobnej gałęzi bez ingerencji w Twoją kopię roboczą.

Różnica w porównaniu z podejściem „napisz własny skrypt bash” polega na tym, że Anthropic uczynił wszystkie te mechanizmy integralnymi elementami narzędzia, a nie rozwiązaniami firm trzecich.

Jak włączyć /goal w 3 krokach#

Krok 1. Zaktualizuj Claude Code do wersji 2.1.139 lub nowszej.

Sprawdź wersję:

claude --version

Jeśli jest niższa niż 2.1.139, zaktualizuj:

claude update
# or force it through npm
npm install -g @anthropic-ai/claude-code@latest

Wydania z okresu od 12 do 19 maja 2026 r. naprawiły ważne błędy pierwszej wersji. W wersji 2.1.140 naprawiono ciche zawieszanie się, gdy disableAllHooks blokowało ewaluator. W wersji 2.1.143 pojawiło się worktree.bgIsolation: "none" oraz poprawka pętli haków zatrzymujących. W wersji 2.1.144 (19 maja) dodano --resume dla sesji w tle oraz --json dla agentów, aby można było ich używać w skryptach. Minimalna wersja to 2.1.143.

Krok 2. Wpisz /goal z warunkiem.

Otwórz zwykłą sesję Claude Code i wpisz polecenie:

/goal all tests in test/auth pass and the linter is clean, or stop after 15 turns

Nie musisz później wysyłać osobnego polecenia — komenda natychmiast rozpoczyna pierwszą turę. Warunek można zapisać po rosyjsku, angielsku lub w obu językach; model rozumie oba. Limit długości wynosi do 4000 znaków.

Krok 3. Monitoruj postęp na bieżącym panelu.

Po uruchomieniu /goal u dołu terminala pojawi się bieżący panel:

/goal active · 3 turns · 12m elapsed · 18,400 tokens · last: tests in test/auth/login.test.ts still fail

Pokazuje on:

• Tury — ile tur zostało ukończonych
• Czas — ile czasu minęło od uruchomienia
• Tokeny — łączną liczbę wykorzystanych tokenów (główny wskaźnik monitorowania budżetu)
• Ostatni powód — ostatnie uzasadnienie ewaluatora dla odpowiedzi „jeszcze nie”

Przydatna sztuczka: jeśli ewaluator poda ten sam powód trzy tury z rzędu, to znak, że utknąłeś w pętli. Naciśnij wtedy Ctrl+C albo wpisz /goal clear (synonimy: stop, off, reset, cancel), zmień brzmienie warunku i uruchom ponownie. Ta zasada pojawia się w poradnikach społeczności dotyczących /goal jako główny znak zapętlenia: „ten sam powód trzy razy — to pętla, wyjdź”.

Jak napisać dobry warunek: 5 zasad + 5 przykładów#

Dokumentacja Anthropic opisuje trzy wymagane elementy dobrego warunku:

Gotowy szablon obejmujący wszystkie trzy elementy w jednym wierszu:

\n/goal [wykonaj pracę] aż do [mierzalnego stanu końcowego] bez [naruszania określonych ograniczeń]\n

Pięć zasad, które sprawiają większości osób trudność:

Zasada 1. Stan końcowy musi dać się zweryfikować poleceniem, a nie oceną gustu.

Nie „spraw, żeby wyglądało dobrze”, lecz npm test exits 0. Nie „popraw UX”, lecz Lighthouse Performance score above 90. Ewaluator czyta tylko transkrypcję — nie uruchamia poleceń ani nie ogląda zrzutów ekranu. Jeśli wyniku nie da się zapisać tekstem, ewaluator nigdy nie odpowie „tak”.

Zasada 2. Ograniczenia muszą być jawne i wąsko określone.

Bez ograniczeń Claude może naprawić testy, usuwając same testy albo komentując niezaliczone asercje. Określ without modifying any file outside /auth, without removing existing assertions, without bumping major versions of dependencies.

Zasada 3. Twardy limit tur jest konieczny.

Dodaj or stop after N turns do każdego warunku. To zabezpieczenie przed niekończącą się pętlą. Bez limitu pętla działająca przez godzinę zużywa więcej tokenów niż ręczne wykonanie tego samego zadania. Uwzględnij to w budżecie.

Zasada 4. Opisz CO, a nie tylko JAK.

Jeśli nie wspomnisz o grafice w warunku, Claude jej nie stworzy. Jeśli warunek wymaga tylko, by „testy przechodziły”, Claude może zakomentować złożone testy. Opisz, CO chcesz uzyskać, a nie tylko JAK to zweryfikujesz.

Zasada 5. Wymagaj od Claude’a przedstawienia dowodów na czacie.

Ewaluator nie uruchamia poleceń — czyta tylko to, co Claude już pokazał. Jeśli warunek wymaga, by „npm test zakończył się powodzeniem”, ale Claude nie pokazał w transkrypcji wyniku npm test, ewaluator będzie bez końca odpowiadał „jeszcze nie”. Dodaj do warunku frazę „pokaż w rozmowie wynik działania <command>”.

Pięć działających przykładów typowych zadań:

1. API migration:
/goal every call to getUser() has been replaced with fetchUser(), npm test passes, npm run build is green, no other API names have been touched, or stop after 30 turns

2. Fixing tests:
/goal all failing tests in test/auth are now green (npm test shows 0 fails in the chat), without changing assertions or deleting tests, or stop after 20 turns

3. Code quality (file size):
/goal src/legacy/UserService.ts has been split into files under 200 lines each, all imports are updated, npm run build is green, or stop after 25 turns

4. Closing the backlog:
/goal process every issue labeled 'good-first-issue': read the description, implement a fix in a worktree branch, open a PR. Continue until the queue is empty or 6 issues have been processed

5. Security audit:
/goal every npm audit vulnerability with severity >= high is fixed, all existing tests pass, no breaking API changes, or stop after 15 turns

Chcesz zrobić więcej niż tylko uruchomić /goal i zbudować konfigurację, w której tryb autonomiczny naprawdę sprawdzi się w Twoim projekcie? /goal to tylko ostatnie ogniwo. Wcześniej trzeba zadbać o trzy filary: klon AI (Twoja metodologia w Skills i Subagents), drugi mózg (CLAUDE.md i folder plans/) oraz inżynierię kontekstu (Plan Mode i /compact). Wszystkie trzy elementy należy rozważyć łącznie — to ich połączenie umożliwia pracę z kontekstem.

5 przykładów, w których /goal naprawdę się sprawdza#

Dokumentacja Anthropic wskazuje cztery rodzaje zadań, do których /goal dobrze pasuje:

Oto pięć przykładów z gotowymi warunkami — skopiuj je i dostosuj do swojego projektu.

Przykład 1. Przenieś moduł na nowe API.

Scenariusz: przechodzisz z REST na GraphQL albo zastępujesz starą funkcję getUser() nową fetchUser(). Zadanie jest mechaniczne, ale obejmuje 30–50 plików.

Warunek:

/goal every getUser() in src/ has been replaced with fetchUser(), all calls updated to the new interface (id instead of userId), npm test passes, no files outside src/ touched, or stop after 30 turns

Dlaczego to działa: stan końcowy można sprawdzić poleceniem grep -r getUser src/ | wc -l (wynik powinien wynosić 0) oraz npm test exits 0. Ograniczenie chroni pliki testowe.

Przykład 2. Napraw niezaliczone testy.

Scenariusz: po aktualizacji biblioteki zepsuło się 15 testów. Wiesz, że naprawa jest mechaniczna — trzeba zaktualizować atrapy i dostosować asercje do nowego formatu. Nie chcesz robić tego ręcznie.

Warunek:

/goal all failing tests in test/ are now green, npm test shows the results in the chat with 0 failures, without deleting tests or commenting out assertions, or stop after 25 turns

Inny przykład tego rodzaju warunku:

\nNapraw wszystkie niezaliczone testy, aż npm test zwróci 0, bez zmieniania jakiegokolwiek pliku poza katalogiem /auth\n

Przykład 3. Podziel klasę boga.

Scenariusz: jeden plik liczący 1200 wierszy zawiera wszystko — model, serwis, narzędzia i klienta API. Chcesz go podzielić zgodnie z zasadą „jeden plik, jedna odpowiedzialność”, zaktualizować wszystkie importy i zachować przechodzące testy.

Warunek:

/goal src/legacy/UserService.ts has been split into files under 200 lines, each file handles one responsibility (model, repository, api-client, validator), all imports are updated, npm run build is green, existing tests pass, or stop after 25 turns

Przykład 4. Zamknij zaległe zgłoszenia w nocy.

Scenariusz: masz repozytorium open source z 20 zgłoszeniami oznaczonymi etykietą good-first-issue. Chcesz, aby Claude zajął się nimi przez noc.

Warunek:

/goal process every issue labeled 'good-first-issue': read the description, implement a fix in a separate worktree branch worktree-issue-N, open a PR with a description. Continue until the queue is empty or 6 issues have been processed, or stop after 80 turns

Liczba 6 nie jest przypadkowa — to realistyczny limit na jedną noc w planie Pro. „Tysiące” uruchamianych agentów to indywidualny przypadek, a nie powtarzalna norma.

Przykład 5. Audyt bezpieczeństwa.

Scenariusz: npm audit pokazuje 8 luk o wysokim poziomie zagrożenia. Chcesz, aby Claude je naprawił bez aktualizowania głównych wersji.

Warunek:

/goal every npm audit vulnerability with severity high+ is fixed, npm audit shows 0 high in the chat, all existing tests pass, no breaking API changes, no major version bumps to packages, or stop after 15 turns

Czego NIE robić za pomocą /goal:

Croucher stanowczo formułuje zasadę kciuka w swoim poradniku: nie używaj /goal do zadań, w których „gotowe” oznacza „dobrze wygląda”, „wydaje się właściwe”, „jest dobrze zaprojektowane” albo „jest fajne”. Ewaluator czyta tylko transkrypcję — nie uruchamia narzędzi i nie potrafi ocenić, jak działa rezultat. Ta zasada wyklucza 80% subiektywnych zadań, przy których /goal zapętla się bez użytecznego wyniku.

Kiedy /goal przepala pieniądze: 3 antywzorce#

Antywzorzec 1. Nieprecyzyjny warunek bez twardego limitu tur.

Najczęstszym błędem jest warunek w rodzaju „popraw kod” / „zrób dobrze” / „zoptymalizuj”. Bez limitu tur agent będzie działał dalej, aż wyczerpie Twój limit.

Findskill opisał prawdziwy przypadek:

200 $ w ciągu 14 godzin za nieprecyzyjny warunek to cały tygodniowy limit w planie Max. Rano budzisz się bez limitu i bez użytecznego wyniku.

Zabezpieczenie: zakończ każdy warunek frazą or stop after N turns (15 dla łatwych zadań, 50 dla trudnych i maksymalnie 100 dla nocnych uruchomień).

Antywzorzec 2. Rekurencyjna pętla z uszkodzonym buforowaniem.

Historia z 22 maja 2026 r.: 6000 $ przez noc, ponieważ Anthropic po cichu zmienił TTL pamięci podręcznej z jednej godziny na 5 minut. Programista nie używał bezpośrednio /goal, ale logika była taka sama: autonomiczna pętla z 30-minutowym timerem cron za każdym razem odtwarzała od zera historię liczącą 800 000 tokenów.

Problem polegał na tym, że zewnętrzna automatyzacja nie wiedziała o wewnętrznych zmianach dostawcy. To samo mogłoby się zdarzyć z /goal, gdyby działało przez 8 godzin bez nadzoru: zużycie tokenów rośnie nieliniowo, a pamięć podręczna promptów nie działa tak, jak się spodziewasz.

Zabezpieczenia:

1. Nie uruchamiaj /goal przez 8+ godzin bez kontroli pośrednich.
2. Włącz limity użycia w Settings → Usage (nowe zabezpieczenie wprowadzone po incydencie z 6000 $).
3. Otwórz claude agents dwa razy w ciągu nocy — rzuć okiem za pomocą Space i sprawdź, czy liczba tur nie rośnie szybciej, niż oczekiwano.
4. W przypadku kosztownych łańcuchów modeli (Opus 4.7) ustaw ostrzejszy limit tur — maksymalnie 30.

Antywzorzec 3. Kreatywność za pomocą /goal.

Croucher uruchomił /goal, by zbudować grę — warunek obejmował determinizm, niezmienniki i sprawdzenie, czy da się przejść poziom. Gra powstała, testy przeszły, a ewaluator stwierdził, że cel został „osiągnięty”. Gra nie miała grafiki — warunek o niej nie wspominał.

To ilustruje ogólną zasadę: ewaluator optymalizuje dokładnie to, co mierzysz. Jeśli warunek nie wspomina o grafice, grafiki nie będzie. Jeśli wspomina tylko o testach, agent może zakomentować asercje.

Zabezpieczenie: nie używaj /goal do niczego, co zależy od gustu (projektowanie, teksty, UX). Wróć do zwykłej sesji albo Plan Mode — te rozwiązania pozostawiają Cię w pętli decyzyjnej.

Czym jest Agent View i jak otworzyć pulpit#

Jeśli /goal jest poleceniem „pracuj, aż skończysz”, Agent View to centrum sterowania, w którym możesz zobaczyć wszystkie te zadania naraz. Anthropic opisuje je tak:

Polecenie otwierające:

claude agents

Otworzy się TUI — tekstowy pulpit w terminalu. Lista sesji znajduje się po lewej, a panel podglądu z ostatnią wiadomością z wybranego wiersza po prawej.

Sześć stanów sesji:

Główne skróty:

↑ / ↓             przechodzenie po liście sesji
Space             panel podglądu (wyświetlanie bez dołączania)
Enter / →         dołączenie do sesji (wejście do niej)
←                 odłączenie (wyjście bez jej zakończenia)
Ctrl+T            przypięcie (ochrona sesji przed automatycznym zatrzymaniem)
Ctrl+X            zatrzymanie sesji; naciśnij ponownie w ciągu 2 sec, aby usunąć
Ctrl+R            zmiana nazwy
Ctrl+S            przełączanie grupowania (stan ↔ katalog)

Jak uruchomić sesję w tle:

Z interaktywnego Claude Code:

/bg fix the failing test test/auth/login.test.ts

Albo bezpośrednio z powłoki:

claude --bg "fix the failing test test/auth/login.test.ts"

Albo z nazwą (aby sesja pojawiła się w Agent View pod rozpoznawalną etykietą):

claude --bg --name "flaky-test-fix" "fix test/auth/login.test.ts"

Sesja w tle zostaje automatycznie dodana do Agent View — uruchom ją z --bg, otwórz claude agents, a zobaczysz ją na liście.

Główna funkcja: sesje przetrwają uśpienie laptopa i zamknięcie okna:

Jednak wyłącz laptop albo uruchom go ponownie ręcznie, a sesje w tle zakończą się statusem Failed. Wszystkie te działające w stylu Chern’y’ego „kilka tysięcy agentów przez noc” pracują na laptopie, który nie jest wyłączany.

Worktree: jak Claude izoluje równoległe sesje#

Worktree rozwiązuje główny problem równoległej pracy autonomicznej: co, jeśli dwie sesje spróbują jednocześnie edytować src/auth.ts? Przed wersją 2.1.139 takie sesje mogły dosłownie nadpisywać nawzajem swoje zmiany. Wraz z Agent View Anthropic wprowadził automatyczną izolację:

Jak to wygląda w praktyce:

# Launched three background sessions:
claude --bg --name "fix-tests" "fix the failing tests in test/"
claude --bg --name "add-oauth" "add Google OAuth according to the plan in plans/oauth.md"
claude --bg --name "split-userservice" "split UserService.ts into modules"

# File structure after launch:
.claude/worktrees/
├── fix-tests/             # separate repo copy on branch worktree-fix-tests
├── add-oauth/             # separate copy on branch worktree-add-oauth
└── split-userservice/     # separate copy on branch worktree-split-userservice

Każda sesja pracuje we własnej kopii. Po ukończeniu zadania scal potrzebne gałęzie z main.

Niebezpieczna pułapka — usunięcie sesji usuwa jej worktree.

Jeśli zakończysz sesję w Agent View (naciskając Ctrl+X dwa razy), jej worktree zniknie. Wszystkie niezatwierdzone zmiany zostaną utracone. Przed usunięciem sesji w Agent View zawsze zatwierdź lub wypchnij zmiany.

Wyłączenie izolacji (w rzadkich przypadkach):

Jeśli masz repozytorium, w którym git worktree nie działa (na przykład konfigurację wykorzystującą dowiązania symboliczne albo duże monorepo z powolnym checkoutem), możesz wyłączyć izolację:

// .claude/settings.json
{
  "worktree": {
    "bgIsolation": "none"
  }
}

Sesje w tle będą wtedy edytować bezpośrednio Twoją kopię roboczą. Opcja ta pojawiła się w wersji 2.1.143 po skargach zespołów pracujących z dużymi monorepo.

Równoległość zużywa limit:

To oznacza, że plan Pro (20 $ miesięcznie) wystarczy na 1–2 równoległe sesje działające przez noc, a nie na dziesięć. Jeśli chcesz naśladować styl Chern’y’ego i uruchamiać tysiące agentów, potrzebujesz planu Max albo Enterprise.

Łączenie /goal + Plan Mode + subagentów przy długich zadaniach#

Typowym błędem jest natychmiastowe wpisanie /goal build a new feature. To nie działa, ponieważ ewaluator nie wie, jak wygląda „ukończona funkcja”. Potrzebujesz planu z polami wyboru, które ewaluator może sprawdzać jedno po drugim.

Warstwa 1. Plan Mode tworzy plan etapowy.

W Plan Mode poproś Claude’a o przygotowanie szczegółowego planu zmian podzielonego na 5–7 etapów z weryfikowalnymi polami wyboru. Zapisz go jako plans/2026-05-24-google-oauth.md. Każdy etap obejmuje 3–7 pól wyboru z konkretnymi działaniami.

Warstwa 2. Subagenci dzielą pracę według etapów.

Jeśli plan można podzielić na równoległe zadania (na przykład etapy są niezależne — punkt końcowy backendu + formularz frontendowy + migracja DB), możesz uruchomić każdy etap w osobnej sesji w tle przez claude --bg --name "<phase>". Każda sesja otrzyma własne worktree.

Warstwa 3. /goal powtarza cykl, aż pola zostaną ukończone.

/goal all phases 1–7 in plans/2026-05-24-google-oauth.md are complete and marked [x], all tests in test/auth pass (npm test shows 0 failures), npm run build is green, or stop after 50 turns

Po każdej turze ewaluator odczytuje plan, sprawdza, które pola są ukończone, i jeśli coś pozostało, agent kontynuuje pracę.

To połączenie opiera się na trzech elementach:

• inżynieria kontekstu: odpowiedni kontekst w plans/ — ewaluator go odczytuje
• drugi mózg: folder plans/ przechowuje plan między sesjami
• klon AI: CLAUDE.md określa zasady, których agent przestrzega

Bez CLAUDE.md /goal może zaproponować rozwiązanie naruszające architekturę. Bez planu w plans/ ewaluator nie zna kryteriów sukcesu. Bez subagentów nie ma równoległych etapów; wszystko odbywa się sekwencyjnie.

Jak porównać /goal z Codex, Cursor i innymi trybami agentów#

/goal dodaje osobne sprawdzenie ukończenia po turze. Inne produkty mają różne tryby; lokalne CLI, zadanie chmurowe i nadzorowana sesja edytora nie są zamiennymi jednostkami porównania. Nie opisuj całego Codex CLI jako kontenera chmurowego ani nie zakładaj jednego walidatora i rozliczenia każdego przebiegu.

Użyj tego samego stanu repozytorium, zadania i kryteriów odbioru. Dla każdego kandydata zapisz:

Stały mnożnik tokenów wymaga tych warunków i zmierzonych liczb dla tego samego udanego wyniku. Procent benchmarku też wymaga wersji testu, modelu, programu testowego i ustawień; dawne nieudokumentowane procenty Terminal-Bench nie zastępują dowodów. Artykuł nie podaje niezależnego benchmarku między narzędziami.

Wybierz potrzebny proces: nadzorowane edycje, ograniczone zadanie w tle lub wieloturowe zadanie z jawnym warunkiem. Sprawdź obsługiwany tryb zainstalowanego produktu zamiast zakładać brak autonomii konkurenta. Oddziel zgodę na narzędzie od kontynuacji: automatyczne zatwierdzenie wywołania samo nie ustala osiągnięcia celu.

/goal a /loop:

/loop to kolejne polecenie z tego samego wydania; uruchamia zadania cykliczne w określonych odstępach czasu (co N minut). /goal działa na podstawie warunku (aż do jego spełnienia). Używaj /loop do zadań przypominających cron, a /goal do osiągania konkretnych celów.

Z dokumentacji Anthropic:

Lista kontrolna przed uruchomieniem /goal: 7 punktów#

Lista kontrolna przed każdym uruchomieniem /goal:

1. Claude Code w wersji 2.1.139+ — sprawdź poleceniem claude --version i zaktualizuj, jeśli masz starszą wersję. Zalecane minimum to wersja 2.1.143 (15 maja 2026 r.), która naprawia pętle haków zatrzymujących.

2. Warunek zawiera weryfikowalny stan końcowy — zamiast „popraw to” wpisz npm test exits 0. Jeśli nie możesz wymyślić polecenia bash, które zweryfikuje wynik, /goal nie nadaje się do tego zadania.

3. Obowiązuje twardy limit tur — każdy warunek określa or stop after N turns. Użyj 15 dla łatwych zadań, 50 dla trudnych i maksymalnie 100 dla uruchomień nocnych.

4. Ograniczenia są jawne i wąsko określone — without modifying files outside /auth, without removing existing assertions, without bumping major versions. Bez nich Claude może naprawić testy, usuwając same testy.

5. Wszystkie ważne zmiany są zatwierdzone lub wypchnięte — jeśli nie pracujesz w worktree (na przykład przy worktree.bgIsolation: "none"), Claude edytuje Twoją kopię roboczą. Każdy błąd może oznaczać utratę niezapisanej pracy.

6. Limity użycia są włączone w Settings → Usage — nowe zabezpieczenie wprowadzone po incydencie z 6000 $. Ustaw limity dzienne, na sesję i miesięczne.

7. Agent View claude agents jest otwarty w osobnym oknie — podczas długich zadań zaglądaj do niego raz na godzinę za pomocą Space. Jeśli liczba tur rośnie szybciej, niż oczekiwano, albo ewaluator trzy razy powtórzy ten sam powód, naciśnij Ctrl+C i zmień brzmienie warunku.

Jeden dodatkowy punkt — nigdy nie uruchamiaj /goal z --dangerously-skip-permissions na cudzym ani nieznanym kodzie. Takie połączenie wyłącza wszystkie kontrole i pozwala agentowi robić w projekcie, co zechce. Autor tej analizy używa tej opcji tylko w nowym worktree, w którym nie ma niczego do stracenia.

/goal to potężna funkcja, ale nie magia. Działa dokładnie tak dobrze, jak potrafisz sformułować warunek. Jeśli umiesz opisać „gotowe” słowami tak, by można było to sprawdzić poleceniem, /goal zrobi resztę. Jeśli nie, wróć do zwykłej sesji albo Plan Mode.

Możesz dalej poznawać Ailoot na ailoot.ai.