Pętle: /goal i /loop. Agent pracuje, aż cel osiągnięty.

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: pętla do celu

/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".

/loop: powtarzanie co interwał

/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.

• /goal: gdy znasz cel, ale nie wiesz, ile kroków zajmie. Kończy się sam.
• /loop <czas>: gdy chcesz cyklicznie coś sprawdzać lub dorzucać po kawałku w równych odstępach.

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]