Polecenie /loop: prompty cykliczne i samodzielnie tempowane

Polecenie /loop ponawia prompt w rytmie zamiast pojedynczego warunku zakończenia, w trzech trybach: stałym interwale zamienianym na harmonogram cron, samodzielnie dobieranym opóźnieniu wybieranym w każdej rundzie na podstawie obserwacji agenta, albo wbudowanej rutynie utrzymaniowej, gdy nie podano promptu. Claude Code i Cursor dostarczają je jako dołączony skill; Codex CLI 0.145 nie ma odpowiednika.

Deploy trwa jakieś osiem minut. Więc czekasz, wpisujesz „już gotowe?”, czytasz „wciąż się buduje”, czekasz, pytasz znów. Albo PR jest w przeglądzie i ciągle wracasz sprawdzić wyniki CI i nowe komentarze. Nic z tego nie jest trudne — to po prostu prompt, który uruchamiałbyś w kółko, gdybyś mógł, a bycie tym, kto uruchamia go w kółko, to marnowanie programisty.

/loop jest tym powtarzaczem. Dajesz mu prompt i, opcjonalnie, rytm, a on ponawia prompt za ciebie — w stałym interwale, w interwale dobranym na podstawie tego, co widzi, albo jako stałą rutynę utrzymaniową. To rytmiczna połowa autonomicznej pracy; jej rodzeństwo, /goal, to połowa oparta na warunku.

Co wyniesiesz z /loop

Trzy tryby /loop w Claude Code — stały interwał, samodzielne tempo i utrzymanie — oraz kiedy używać którego
Dokładną składnię, w tym jak interwały mapują się na cron i jak zatrzymać pętlę
Jak zastąpić domyślny prompt utrzymaniowy własnym loop.md
Czym różni się własny skill /loop Cursora i czego użyć zamiast tego w Codeksie
Czym /loop różni się od /goal

Trzy tryby (Claude Code)

/loop to dołączony skill (wymaga Claude Code w wersji 2.1.72 lub nowszej). Zarówno interwał, jak i prompt są opcjonalne, a to, co podasz, decyduje o zachowaniu:

Co podajesz	Przykład	Co się dzieje
Interwał i prompt	`/loop 5m sprawdź deploy`	Prompt działa według stałego harmonogramu
Tylko prompt	`/loop sprawdź deploy`	Prompt działa w interwale, który Claude dobiera w każdej rundzie
Tylko interwał albo nic	`/loop`	Działa wbudowany prompt utrzymaniowy (albo twój `loop.md`)

Stały interwał

Podaj interwał, a Claude przekształca go w wyrażenie cron, planuje zadanie i potwierdza rytm oraz identyfikator zadania:

/loop 5m sprawdź, czy deploy się zakończył, i powiedz mi, co się stało

Interwał może prowadzić jako goły token (30m) albo zamykać zdanie jako klauzula (every 2 hours). Jednostki to s, m, h, d. Sekundy zaokrąglają się w górę do najbliższej minuty (granulacja crona), a nietypowe interwały jak 7m czy 90m zaokrąglają się do najbliższego czystego kroku crona — Claude mówi ci, co wybrał. Jako prompt możesz też podać inne polecenie: /loop 20m /review-pr 1234 ponawia zapisany skill w każdej iteracji.

Ta ostatnia forma ma ograniczenie, o którym warto wiedzieć, zanim na niej polegniesz. Od wersji 2.1.196 zaplanowane odpalenie wykonuje tylko te skille, które Claude może wywołać sam. Wszystko inne dociera do Claude’a jako zwykły tekst i po cichu nic nie robi: polecenia wbudowane jak /permissions, /model czy /clear; skille oznaczone disable-model-invocation: true, w tym dołączony /verify; skille wstrzymane ustawieniem skillOverrides albo regułą odmowy Skill; oraz prompty MCP takie jak /mcp__github__list_prs. Pętla owinięta wokół jednego z nich wygląda na zaplanowaną i nie produkuje nic.

Odpalenia celowo nie są też punktualne. Harmonogram dodaje przesunięcie jitter wyprowadzone z identyfikatora zadania, więc dane zadanie zawsze dryfuje tak samo: zadania cykliczne odpalają się do 30 minut później (albo do połowy interwału, gdy jest krótszy niż godzina), a jednorazowe zaplanowane na :00 lub :30 do 90 sekund wcześniej. Jeśli dokładny czas ma znaczenie, planuj na minutę, która nie jest żadną z nich, na przykład 3 9 * * * zamiast 0 9 * * *. Sesja utrzymuje jednocześnie najwyżej 50 zaplanowanych zadań.

Samodzielne tempo

Pomiń interwał, a Claude sam dobiera opóźnienie po każdej rundzie — od jednej minuty do godziny — na podstawie tego, co zaobserwował, i wypisuje powód każdego czekania:

/loop sprawdź, czy CI przeszło, i zajmij się komentarzami z przeglądu

Krótkie czekania, gdy build się kończy, dłuższe, gdy zrobi się cicho. W tym trybie Claude może użyć narzędzia Monitor, by strumieniować wyjście skryptu działającego w tle zamiast ponawiać prompt — często szybciej i oszczędniej tokenowo niż odpytywanie.

Utrzymanie

Gołe /loop (bez promptu) uruchamia wbudowaną rutynę utrzymaniową w samodzielnie dobranym interwale. W każdej rundzie przechodzi, w kolejności: kontynuuje niedokończoną pracę z rozmowy, zajmuje się PR-em bieżącej gałęzi (komentarze z przeglądu, niepowodzenia CI, konflikty scalania), a potem — gdy nic innego nie czeka — uruchamia przebiegi porządkowe, jak polowanie na bugi czy upraszczanie. Nie zaczyna nowych inicjatyw poza tym zakresem, a działania nieodwracalne wykonuje tylko wtedy, gdy kontynuują coś, co transkrypt już autoryzował.

Zastąp domyślny prompt plikiem loop.md. Wrzuć plik Markdown do .claude/loop.md (projekt) albo ~/.claude/loop.md (użytkownik), by zdefiniować własny domyślny prompt dla gołego /loop. Napisz go tak, jakbyś wpisywał prompt bezpośrednio:

Sprawdź PR release/next. Jeśli CI jest czerwone, ściągnij log
nieudanego zadania, zdiagnozuj i wypchnij minimalną poprawkę. Jeśli
pojawiły się nowe komentarze z przeglądu, zajmij się każdym i zamknij
wątek. Jeśli wszystko jest zielone i cicho, powiedz to w jednej linii.

Edycje wchodzą w życie przy następnej iteracji, więc możesz dopracowywać instrukcje w trakcie działania pętli. Trzymaj plik krótko: treść powyżej 25 000 bajtów jest ucinana.

Zatrzymywanie i wygaśnięcie

Naciśnij Esc, gdy pętla czeka na następną iterację, by wyczyścić oczekujące wybudzenie. W trybie samodzielnego tempa Claude może też sam zakończyć pętlę: od wersji 2.1.202 wywołuje narzędzie ScheduleWakeup z stop: true, co natychmiast anuluje oczekujące wybudzenie. Przed tym wydaniem jedynym sposobem samodzielnego zatrzymania było po prostu niezaplanowanie kolejnego wybudzenia — i to nadal pozostaje ścieżką zapasową. Jeśli iteracja ani nie planuje kolejnej, ani nie zatrzymuje pętli, Claude Code planuje jeszcze jedno wybudzenie mniej więcej 20 minut później i kończy pętlę, gdy tamta iteracja też nic nie zaplanuje.

Każda pętla niesie siedmiodniowe wygaśnięcie — odpala się ostatni raz siedem dni po utworzeniu, po czym sama się usuwa, więc zapomniana pętla nie może działać w nieskończoność. Pętle są związane z sesją; claude --resume lub --continue przywraca te, które nie wygasły. Przeniesienie sesji w tło zabiera jej zadania /loop do sesji działającej w tle, która odpala je dalej bez terminala.

Wsparcie w narzędziach

Natywne, jak opisano wyżej. Dla harmonogramów przeżywających sesję Claude Code oferuje też Routines (chmura zarządzana przez Anthropic, minimum 1 godzina), zadania zaplanowane w aplikacji Desktop (twoja maszyna) oraz GitHub Actions — samo /loop jest opcją do szybkiego odpytywania w obrębie sesji. Ustaw CLAUDE_CODE_DISABLE_CRON=1, by wyłączyć harmonogram (i /loop) całkowicie.

Codex nie ma polecenia /loop — sprawdzone na Codex CLI 0.145, którego wyjście codex features list nie zawiera żadnej flagi pętli, crona ani harmonogramu. Jego prymitywem zapętlania jest /goal: ustaw cel, a Codex sam uruchamia planuj → działaj → testuj → przeglądaj, aż warunek zostanie spełniony. To pętla oparta na warunku, a nie zaplanowana w czasie — w CLI nie ma natywnego „co 5 minut”. Dla biegów sterowanych czasem lub zdarzeniami podłącz Codeksa do CI albo do automatyzacji GitHub/Linear.

Cursor dostarcza własny skill /loop, dodany w Cursorze 3.5 (20 maja 2026). Uruchamia prompt wielokrotnie według lokalnego harmonogramu, aż osiągnięty zostanie wynik albo go zatrzymasz, a gdy nie podasz stałego interwału, agent sam decyduje, kiedy — albo na jakie zdarzenie — się wybudzić. Własne przykłady Cursora to „sprawdzaj status deploya co 5 minut” i „pracuj nad tą funkcją, aż testy przejdą”, i to jest tu rzecz ciekawa: ten sam skill pokrywa i rytm, i zadanie kończone wynikiem, które Claude Code wydziela do /goal.

Dwa zastrzeżenia co do tego, gdzie to żyje. To dołączony skill, a nie jedno z 35 poleceń wbudowanych w referencji poleceń CLI, i jest nakierowany na lokalnych, długo działających agentów w oknie Agents. Cursor dokumentuje go też znacznie skrótowiej niż Anthropic dokumentuje wersję z Claude Code, więc szczegóły powyżej — jitter, wygaśnięcie, loop.md, zastrzeżenia dotyczące dostawców chmurowych — opisują zachowanie Claude Code i nie należy zakładać, że obowiązują tutaj.

Cursor Automations pozostają opcją trwałą: uruchamiają agenta według harmonogramu lub w reakcji na zdarzenia (zapisy plików, commity, niepowodzenia testów) bez otwartej sesji, co czyni je analogiem Routines z Claude Code, a nie /loop.

/loop kontra /goal

Dwa autonomiczne polecenia odpowiadają na różne pytania:

/loop odpowiada „jak często?” — ponawia prompt w rytmie i samo z siebie może nigdy się nie zakończyć (siedmiodniowe wygaśnięcie to bezpiecznik, a nie linia mety).
/goal odpowiada „do kiedy?” — działa na pełnych obrotach, aż weryfikowalny warunek zakończenia stanie się prawdą, po czym się zatrzymuje.

Używaj /loop do monitorowania i stałego utrzymania; używaj /goal do pracy zbieżnej z jasną definicją ukończenia. Dobrze się łączą: /goal doprowadza funkcję do zieleni, a potem /loop pilnuje powstałego PR-a.

Zabezpieczenia

Pętla odpala się tylko, gdy sesja jest otwarta i bezczynna. Zamknij terminal, a się zatrzyma — chyba że najpierw przeniesiesz sesję w tło, co zabiera zadania ze sobą. Pominięte odpalenie podczas długiej tury wykona się raz, gdy Claude następnym razem będzie bezczynny, a nie raz na każdy pominięty interwał.
Pamiętaj o koszcie częstotliwości. Jednominutowa pętla na gadatliwym prompcie to mnóstwo tokenów. Wybieraj tryb samodzielnego tempa albo dłuższy interwał, chyba że naprawdę potrzebujesz rozdzielczości minutowej.
Bądź jednoznaczny co do działań nieodwracalnych w każdym prompcie, który zapętlasz. Rutyna utrzymaniowa jest z założenia zachowawcza; własny loop.md, który mówi „wypchnij poprawkę”, wypchnie ją bez nadzoru za każdym razem, gdy warunek będzie spełniony.

Dokąd pójść dalej po /loop

Polecenie /goal Uruchom agenta, aż spełni weryfikowalny warunek zakończenia -- odpowiednik /loop oparty na warunku.

Człowiek w pętli Gdzie utrzymać człowieka na ścieżce decyzji, gdy agenci działają autonomicznie.