Lekcja 24 · Faza 3 · Planowanie wieloetapowe

loop-me: specyfikowanie automatyzacji, nie kodu

Zmiana kierunku względem wszystkiego dotąd: loop-me nie planuje kodu, treści ani architektury — planuje Twoje własne, powtarzalne czynności. Pod spodem działa ten sam prymityw co zawsze: /grilling, jedno pytanie naraz. Nowe jest to, na co ten wywiad celuje.

Polecane źródło Lokalny plik .agents/skills/loop-me/SKILL.md w tym repo.

Loop kontra workflow — dwa różne słowa, celowo

Loop to powtarzający się wzorzec w Twoim życiu — kariera, tydzień, poranek, pojedyncza czynność robiona w kółko. Patrzenie na życie jako na pętle zagnieżdżone w pętlach pokazuje, jak bardzo przewidywalne są te czynności — a to właśnie czyni je wartymi delegowania.

Workflow to spec jednej pętli, sprowadzony do konkretu. Uruchamiasz workflow na loopie — loop jest jego żywą instancją, workflow jest źródłem prawdy. Workflowy mieszkają w workflows/*.md, po jednym pliku na workflow.

Skill sam proponuje loopy, których jeszcze nie zauważyłeś — nie tylko czeka, aż je nazwiesz. To odróżnia go od czystego notowania: aktywnie szuka w Twoim opisie dnia/tygodnia wzorców wartych wydzielenia w osobny workflow.

Słownictwo — używane tylko, gdy workflow tego wymaga

Cztery terminy, żadnego z nich nie narzucasz z góry. Zasada wprost: workflow nie potrzebuje ani AI, ani checkpointu, ani harmonogramu, dopóki grillowanie nie pokaże, że jednak potrzebuje.

Termin	Znaczenie
Trigger	Co odpala każdy przebieg: event (nowy e-mail, nowy issue) albo schedule (codziennie rano). Trigger zdarzeniowy jest zwykle wydajniejszy.
Checkpoint	Punkt human-in-the-loop, gdzie użytkownik weryfikuje albo decyduje. Niektóre workflowy nie mają żadnego i działają w pełni autonomicznie; niektóre w ogóle nie używają AI.
Push right	Odsuń checkpoint jak najdalej się da — wykonaj maksimum pracy, zanim zaangażujesz człowieka, żeby zapytać go raz, późno, z gotowym materiałem.
Brief	To, co checkpoint pokazuje: zwięzłe, gotowe-do-decyzji podsumowanie — co powstało, dlaczego, i link w dół do samego zasobu. Nigdy surowy output. Użytkownik czyta brief, nie szkic.

Kluczowy wniosek: "mandate nothing structural" to ta sama dyscyplina, co "jeden adapter to hipotetyczny seam" z Lekcji 18 — nie wprowadzaj checkpointu, harmonogramu ani AI na zapas, tylko dlatego, że "prawdopodobnie się przyda". Każdy z tych elementów pojawia się w specu wyłącznie wtedy, gdy konkretna odpowiedź w grillowaniu go wymusiła.

Definition of done: bez pytań dla implementera

Spec workflow jest gotowy dokładnie wtedy, gdy agent-implementer mógłby go zbudować, nie zadając ani jednego pytania. Grilluj, dopóki tak nie jest — nic nie jest gotowe, dopóki zostaje choć jedno pytanie otwarte. To ten sam twardy bar, co "ready-for-agent" w /triage z Lekcji 21 — różne konteksty, identyczne kryterium ukończenia.

Przestrzeń robocza: workflows/*.md i NOTES.md

workflows/*.md — jeden plik na jeden workflow. NOTES.md — surowe notatki o świecie użytkownika: jakich narzędzi używa, jakie kanały przetwarza, jakim własnym słownictwem je nazywa. Gdy ten plik jest pusty albo ubogi, skill ma najpierw przeprowadzić wywiad o tym świecie, zanim zacznie cokolwiek specyfikować — dopiero potem ostrzy niejasne terminy w kanoniczne i zapisuje je tam na stałe.

NOTES.md pełni tu rolę bardzo podobną do CONTEXT.md z domain-modeling (Lekcja 21) — glosariusz sharpening się na żywo — tylko że dotyczy słownictwa Twojego własnego świata pracy, nie domeny oprogramowania.

Zadanie praktyczne — znajdź jedną pętlę wartą delegowania

To zadanie nie dotyczy tego workspace ani niekoniecznie Twojego projektu firmowego — loop-me tworzy pliki tam, gdzie go uruchomisz, więc uruchom go w miejscu, gdzie faktycznie chcesz trzymać specyfikacje swoich automatyzacji (osobne repo notatek, albo folder w projekcie firmowym, jeśli chodzi o pracę). Wpisz /loop-me:

Jeśli NOTES.md jest puste, pozwól się wywiadować o swój świat pracy, zanim przejdziesz dalej.
Znajdź jedną powtarzalną czynność (loop) i przejdź przez grillowanie aż do workflow bez otwartych pytań.
Sprawdź, czy skill faktycznie zaproponował Trigger/Checkpoint/Brief tylko tam, gdzie to wynikało z rozmowy — nie z góry, jako checklistę.

Sprawdź się

1. Czym różni się "loop" od "workflow" w słownictwie tego skilla?

Workflow jest specem — źródłem prawdy zapisanym w workflows/*.md. Loop jest powtarzającym się wzorcem w życiu użytkownika, którego dana instancja workflow dotyczy.

2. Co dokładnie oznacza termin "push right"?

Push right to odsuwanie checkpointu jak najdalej w toku procesu — maksimum pracy wykonuje się przed zaangażowaniem człowieka, żeby zapytać go raz, późno, z gotowym materiałem.

3. Co powinien pokazywać "brief" na checkpoincie?

Brief ma być tight i decision-ready: co powstało, dlaczego, link w dół do zasobu — nigdy surowy draft. Szybkość przeglądu jest tu najważniejsza.

4. Kiedy workflow powinien dostać checkpoint albo harmonogram, według zasady "mandate nothing structural"?

Żaden element słownictwa nie jest domyślny — pojawia się w specu tylko wtedy, gdy konkretna odpowiedź w rozmowie pokazała, że jest potrzebny.

5. Do czego służy NOTES.md i kiedy warto go uzupełnić przed specyfikowaniem workflow?

Gdy NOTES.md jest puste albo ubogie, skill najpierw przeprowadza wywiad o świecie użytkownika — narzędziach, kanałach, ich nazwach — zanim zacznie cokolwiek specyfikować.

Coś niejasne? Zapytaj mnie wprost — mogę pomóc ocenić, czy konkretna powtarzalna czynność z Twojej pracy faktycznie zasługuje na osobny workflow, czy to za mało regularne.

← Lekcja 23: decision-mapping Następna lekcja: wizard — jednorazowe skrypty onboardingowe →