LaunchRepoUżywaj CLI: Aby uzyskać najlepsze wyniki, zawsze korzystaj z Claude Code CLI lub Codex CLI zamiast aplikacji desktopowych.
Gdy przestrzeń robocza i dashboard są gotowe, agent postępuje według ONBOARDING.md, wypełnia pliki na podstawie zweryfikowanych źródeł i wykorzystuje odpowiedzi, których już udzielono. Jeśli sesja się przerwie, onboarding.json i SESSION.md przechowują następny krok.
Fazy 1–2: orientacja i prywatne miejsce na dane
Agent zaczyna od wyjaśnienia planu: zrozumieć produkt, podłączyć przeglądarkę i skrzynkę do weryfikacji, uzgodnić, jak może publikować wpisy i odznaki na stronie, oraz zachować konfigurację na przyszłe sesje. Pyta o nazwę pierwszego produktu, jego URL i lokalny folder z kodem — i zapoznaje się z nimi, zanim zapyta o cokolwiek innego. Sprawdza też, co faktycznie może zrobić w tej sesji: sam terminal to jeszcze nie sterowanie przeglądarką, a zestaw zabrania deklarowania narzędzi, których sesja nie potrafi wywołać.
Faza 2 daje twoim danym prywatne miejsce. Jeśli agent wciąż pracuje w zakupionym repozytorium zestawu, inicjalizuje niezależną przestrzeń roboczą, którą tworzy start w trzech krokach, i pomaga ci skonfigurować własny prywatny remote. Mówi wprost, że zapisane dane logowania — jeśli zgodzisz się na ich przechowywanie — trafiają do tego prywatnego repozytorium, gdzie może je odczytać każdy, kto ma do niego dostęp (także do jego historii), i nigdy do repozytorium zestawu. Właściciel, repozytorium, sprawdzenie widoczności i wybrany sposób przechowywania danych logowania trafiają do workspace.json; przy menedżerze sekretów zapisywane są wyłącznie odwołania.
Faza 3: brief produktu i data premiery
Agent uruchamia scripts/new-product.py z krótkim slugiem pisanym małymi literami i wypełnia product.json — plik kontekstu produktu, z którego korzysta każdy playbook — na podstawie twoich odpowiedzi: grupa docelowa, problem, wyróżnik, faktyczne funkcje, cennik lub okres próbny, etap premiery, prawdziwe zrzuty ekranu i logo. Powstałe teksty dostajesz do poprawienia. Przed kompromitującymi wpisami chronią cię dwie zasady: możliwości produktu nigdy nie są wywodzone z oferty konkurencji, a planowane funkcje nigdy nie są opisywane jako dostępne. Nieznane informacje zostają puste.
W tej fazie agent pyta też, kiedy pierwsze premiery mają się pojawić i czy istnieje data, przed którą nic nie może zostać opublikowane — z jasnym ostrzeżeniem, że katalogi w darmowych planach kolejkują zgłoszenia do moderacji, a publikacja może zająć tygodnie, nie dni. Twoja odpowiedź trafia do pola earliest_launch_date w product.json i staje się dolną granicą daty premiery, której później pilnuje record.py.
Następnie w identity.json zapisywane są nazwa publiczna, kontaktowy adres e-mail, pseudonim i informacje o organizacji, na które się zgodzisz — przy czym prywatny e-mail twojego konta pozostaje oddzielony od publicznego adresu kontaktowego. Zanim cokolwiek z tego trafi do wpisu, agent przeprowadza krótki briefing wizerunkowy.
Faza 4: Chrome i skrzynka pocztowa
Zgodnie z przewodnikiem po łączeniu z Chrome agent przeprowadza cię przez stronę zdalnego debugowania Chrome i ewentualne uprawnienia macOS, a potem wykonuje na publicznej stronie szybki test, który możesz obserwować. Do swojej poczty webowej logujesz się w podłączonej przeglądarce samodzielnie; agent potwierdza, że to właściwe konto, nie kopiując żadnych wiadomości. E-maile weryfikacyjne kończą rejestracje i dodawanie wpisów, dlatego zakres dostępu do skrzynki trafia do authorizations.json. Ręczne przekazywanie kodów to wspierana alternatywa, zapisywana jako przekazanie do człowieka, a nie jako zautomatyzowany dostęp.
Faza 5: uprawnienia, uzgadniane raz na produkt
Agent pyta, gdzie leży kod strony produktu, jak jest wdrażana, która gałąź jest produkcyjna i jaki jest kanoniczny URL. Potem pada pytanie, które później oszczędza najwięcej zachodu: czy może dodać oficjalną odznakę katalogu do stopki strony tego produktu, zrobić commit, push i ponownie ją wdrożyć? Zakres, odpowiedź, data oraz dozwolone repozytorium i gałąź trafiają do authorizations.json. Odpowiedź „nie” nie blokuje katalogów, które nie wymagają odznaki. W tym samym pliku zapisuje się też, czy dozwolone są darmowe rejestracje, darmowe ostateczne zgłoszenia i konkretne działania związane z e-mailami weryfikacyjnymi. Wydatki pozostają zerowe, a zgoda udzielona dla jednego produktu nigdy nie obejmuje innego.
Fazy 6–7: zaplanuj serię, a potem pilnuj jej postępu
Po zakończeniu konfiguracji agent uruchamia doctor.py, który oddziela brakującą konfigurację od uprawnień, których celowo nie przyznano. Otwórz planer serii i zacznij od 10 nowych potwierdzonych zgłoszeń, maksymalnie 2 równolegle. Rekomendacja oparta na lokalnym sprzęcie to punkt wyjścia; użyj jednego workera, gdy brakuje pamięci, komputer jest obciążony albo nie ma osobnego sterowania przeglądarką. Przed pracą równoległą agent sprawdza, czy każdy worker ma własną przydzieloną platformę i odizolowane środowisko przeglądarki. Wybiera odpowiednie playbooki, wyjaśnia, dlaczego pasują, i zaczyna od dostępnej darmowej ścieżki: wyszukanie istniejącego wpisu, weryfikacja miejsca docelowego, przygotowanie rzetelnych tekstów, potwierdzenie, że nic nie zostanie naliczone, zgłoszenie w ramach udzielonej zgody i zapisanie rzeczywistego wyniku. Dobrym pierwszym rezultatem jest często zgłoszenie czekające na moderację, a nie opublikowana strona — zobacz przewodnik po zapisywaniu wyników.
Jeśli twój agent obsługuje /goal, użyj go z zapisanym promptem serii; w przeciwnym razie wklej prompt jako zwykłą wiadomość. Chodzi o to, żeby agent pracował dalej nad uzgodnioną serią, zamiast zatrzymać się po pierwszym wyniku. Potwierdzone nowe zgłoszenie — oczekujące na moderację, w kolejce, zaplanowane lub opublikowane — liczy się raz na platformę. Szkice, istniejące wpisy, płatne ścieżki i przekazania do człowieka się nie liczą. Agent zapisuje każdy wynik, po zapisaniu dowodów zamyka tylko okno przydzielone danemu zgłoszeniu i przechodzi do odpowiednich alternatyw. Niezapisane formularze i przekazania do człowieka zostawia nietknięte.
Przy wstrzymaniu lub zamknięciu sesji agent aktualizuje onboarding.json wyłącznie o kontrole, które faktycznie zaobserwował, zapisuje niewrażliwe dowody i otwarte kroki w SESSION.md, terminy ponownych sprawdzeń w FOLLOW-UP.md i podsumowuje, co jest zrobione, co jeszcze trwa, co czeka na ciebie i co dalej. Przed każdym pushem wykonywana jest kontrola prywatności w git. Sprawdzian dobrej pierwszej sesji: kolejny agent może kontynuować bez ponownego zakładania kont i bez drugiego pytania o stałe uprawnienia. Strona o tym, jak to działa, pokazuje, jakie miejsce zajmuje ten etap w całym procesie.