Konfiguracja
Parametry i zasady obu komend
Wymagane wersje i limity, twardy limit tur, przerywanie i wznawianie — plus cztery zasady, żeby pętla nie zwariowała.
Akademia · Pętle
Najwięcej daje nie pojedyncze polecenie, tylko agent prowadzony w pętli. Dwie komendy: /goal — pracuje, aż osiągnie cel, oraz /loop — powtarza zadanie co zadany czas. Spinają je wzorzec checklisty: plik z zadaniami, który agent sam odhacza.
Ostatnia aktualizacja:
01 / Dwie pętle · Czym są i dlaczego działają
Pojedynczy prompt kończy się, gdy agent uzna, że skończył. Pętla kończy się, gdy warunek jest spełniony — to cała różnica i cały powód, dla którego pętle działają.
/goal uruchamia agenta w trybie zadaniowym: dostaje cel i pracuje w kółko, aż go osiągnie. Idealny do zadań, które da się rozbić na listę kroków o jasnym warunku zakończenia: „zrób wszystko z listy", „napraw, aż testy przechodzą", „uzupełnij brakujące pliki".
Sedno: definiujesz cel i warunek osiągnięcia celu, nie pojedynczą czynność. Spełnienie warunku ocenia po każdej turze osobny mały, szybki model (domyślnie Haiku) i zwraca tak/nie z uzasadnieniem. Agent, który wykonuje pracę, nie ocenia jej sam.
/loop 5m sprawdź status builda powtarza to samo polecenie co zadany czas — tu co 5 minut. Sprawdza się przy monitorowaniu i pracy reaktywnej: „zerkaj na nowe zgłoszenia", „pilnuj kolejki, aż się opróżni". Bez podanego interwału pętla sama dobiera tempo — częściej, gdy coś się dzieje, rzadziej, gdy cisza. Działa, dopóki jej nie zatrzymasz albo nie wygaśnie.
02 / Filozofia · Praca to pisanie pętli
Boris Cherny, twórca Claude Code, ujął to wprost: „I don't prompt Claude anymore. I have loops that are running. My job is to write loops." Ewolucja wygląda tak: najpierw kod z autouzupełnianiem, potem promptowanie kilku agentów równolegle, na końcu pętle, które promptują same. Anatomia dobrej pętli to kontekst + cel + definicja sukcesu — agent iteruje i sam ocenia wyniki, aż przejdą test.
03 / Dalej · Część praktyczna
Konfiguracja
Wymagane wersje i limity, twardy limit tur, przerywanie i wznawianie — plus cztery zasady, żeby pętla nie zwariowała.
Wzorzec
Plik z checkboxami jako plan, pamięć i warunek końca w jednym — z gotowym promptem do skopiowania i wyjaśnieniem, dlaczego ewaluator go „widzi".
Pętle samodoskonalące
Mechanika w trzech krokach i dwa wdrożenia z projektów: optymalizacja JavaScriptu i komunikacja z drukarką w embedded.
04 / Konfiguracja · Parametry i zasady
Wymagania i sterowanie: /goal wymaga Claude Code w wersji v2.1.139 lub nowszej; działa też nieinteraktywnie (claude -p "/goal …") i przeżywa --resume sesji. /goal clear przerywa bieżący cel, a samo /goal bez argumentu pokazuje status — liczbę tur, zużyte tokeny i uzasadnienie ostatniej oceny.
Interwał jest opcjonalny: /loop <prompt> bez czasu sam dobiera odstęp (od 1 minuty do 1 godziny), a po wykonaniu zadania potrafi sam zakończyć pętlę. Samo /loop bez argumentów odpala wbudowany prompt utrzymaniowy (albo Twój plik .claude/loop.md): dociąga niedokończoną robotę, pilnuje PR-a bieżącej gałęzi i sprząta kod.
Wymagania: /loop stoi na cronie, więc stały interwał ma granularność 1 minuty (sekundy zaokrąglają się w górę). Zadania są przypięte do sesji: wygasają po 7 dniach, maksymalnie 50 na sesję. Klawisz Esc kasuje najbliższe wybudzenie. Wymaga Claude Code w wersji v2.1.72 lub nowszej.
or stop after 20 turns. Cały warunek może mieć do 4000 znaków./loop. Doprowadzenie zadania do końca → /goal. Można je łączyć: /loop pilnuje, a po wykryciu zmiany odpala pracę.05 / Wzorzec · Checklista jako pamięć
Najprostszy sposób, żeby pętla wiedziała, co już zrobiła, a co zostało — to plik z listą zadań i checkboxami. Agent po każdym wykonanym zadaniu zamienia [ ] na [x]. Plik jest jednocześnie planem, pamięcią i warunkiem zakończenia: cel osiągnięty, gdy wszystkie pozycje są zaznaczone.
Przykładowy TODO.md:
# Lista zadań do wykonania
- [ ] 1. Utwórz plik `hello.txt` z tekstem "Hello SZRON"
- [ ] 2. Utwórz plik `data.json` z obiektem {"version": 1}
- [ ] 3. Dopisz do `hello.txt` drugą linię z aktualną datą
- [ ] 4. Utwórz `README.md` z nagłówkiem "# Demo /goal"
- [ ] 5. Policz pliki w katalogu i zapisz liczbę do `count.txt` I prompt, który uruchamia całość:
/goal wykonaj po kolei każdy task z TODO.md, po wykonaniu
zamień [ ] na [x] przy tym tasku; po każdej turze wypisz w
odpowiedzi aktualną listę checkboxów; cel osiągnięty gdy w
tym wypisie wszystkie checkboxy są zaznaczone [x] Dlaczego to działa: ewaluator /goal nie czyta plików ani nie uruchamia komend — ocenia wyłącznie transkrypt rozmowy. Dlatego warunek pisz tak, by dało się go udowodnić z odpowiedzi agenta: każ mu po każdej turze wypisać stan checklisty (ile [ ], ile [x]) wprost w odpowiedzi. To, czego nie widać w transkrypcie, dla ewaluatora nie istnieje. Ty w każdej chwili widzisz postęp w tym samym pliku.
06 / Pętle samodoskonalące · Agent uczy się z błędów
Ten sam wzorzec w wersji, którą wdrażamy w zespołach jako pętle samodoskonalące (Self-Improving Loops): agent nie oddaje kodu po pierwszym podejściu, tylko sam go uruchamia, czyta wyniki i poprawia. /goal plus checklista z poprzedniej sekcji to jego gotowa implementacja.
01 · Sprawdza
Agent uruchamia kod i testy, weryfikuje działanie narzędziami MCP (ChromeDevTools, Playwright).
02 · Poprawia
Naprawia błędy, optymalizuje wydajność, refaktoruje kod — bez interwencji człowieka.
03 · Powtarza
Iteruje, dopóki nie osiągnie celu i wszystkie testy nie przejdą.
Jak wdrażamy ten wzorzec w całych zespołach — na stronie transformacji AI dla programistów.
Wdrożenie u Was
Pętle, checklisty i AGENTS.md jako kontrakt zespołu wdrażamy na Waszym kodzie — w ramach dwóch kwartałów transformacji. Audyt 90 minut wystarczy, żeby sprawdzić, czy ma to u Was sens.