--- title: "Sprint od zera: lista kontrolna i tabela zgodności" description: "Sprint z pętlami jako jedna lista dziewięciu kroków z poleceniami, trzy rodzaje branchy, tabela zgodności dla GitLaba, GitHuba, braku CI i Codex oraz przykład z trzema ticketami." url: "https://monolynx.com/blog/sprint-lista-kontrolna-monolynx" lang: "pl" author: "Zespół Monolynx" published: "2026-10-10T12:41:15.286200+00:00" modified: "2026-10-10T13:12:57.696916+00:00" last_verified: "2026-10-10" tags: ["monolynx", "sprint", "plugin", "claude-code"] translations: [] reading_time_minutes: 12 word_count: 2320 --- > [!TLDR] > - Sprint z pętlami to dziewięć kroków w stałej kolejności. Ten wpis podaje je jako jedną listę z poleceniami. > - W sprincie są tylko trzy rodzaje branchy: gałąź główna, branch sprintu i branch ticketu. > - Pełny autopilot działa w GitLabie z CI. W GitHubie pull requesty otwierasz sam, a bez CI sam mergujesz. > - Twoja praca w trakcie to dwie rzeczy: zatwierdzać merge requesty i odpowiadać sesjom, które czekają. > - Przykład na końcu pokazuje trzy tickety i jedną sesję, która utknęła, razem z wynikami komend. ## Co musi być gotowe przed sprintem? Lista zakłada projekt po jednorazowej konfiguracji. Jeśli któregoś punktu brakuje, zacznij od wpisu [Zacznij tutaj: czym jest Monolynx i czego potrzebujesz](https://monolynx.com/blog/zacznij-tutaj-monolynx). **Porównanie** | Warunek | Jak sprawdzić | | --- | --- | | projekt, plugin i połączenie działają | `/monolynx:setup` pokazuje OK przy slugu i stronie `toolchain` | | strona `toolchain` ma sekcję `## Worktree` | ten sam raport; bez niej sesje w tle nie uruchomią testów | | jeden ticket przeszedł ścieżką ręczną | wiesz, jak wygląda plan, raport i ocena krytyka | | test dymny przeszedł | jeden ticket na jednym slocie doszedł do statusu Gotowe; opisuje go wpis [Test dymny przed pierwszym sprintem](https://monolynx.com/blog/test-dymny-przed-sprintem-monolynx) | | `glab` albo `gh` jest zalogowane | `glab auth status` albo `gh auth status` | | Twoja rola pozwala usuwać strony wiki | rola właściciela albo administratora; potrzebna tylko do czyszczenia logów w `sprint-end` | ## Jakie branche występują w sprincie? W sprincie są trzy rodzaje branchy. Pozostałe nazwy spotykane we wpisach i w zmiennych to określenia tych samych trzech. **Porównanie** | Branch | Przykład | Kto go tworzy | Inne nazwy tego samego | | --- | --- | --- | --- | | Gałąź główna | `main` | istnieje w repozytorium | domyślny branch repozytorium | | Branch sprintu | `sprint/platnosci` | Ty, przed sprintem | bazowy, źródłowy, docelowy, integracyjny | | Branch ticketu | `worktree-SKL-12` | sesja ticketu | roboczy, branch merge requesta | **Trzy branche i kierunek merge** Branch sprintu odgałęzia się od gałęzi głównej. Każdy ticket dostaje własny branch odgałęziony od brancha sprintu. Kolejka merguje branche ticketów do brancha sprintu. Na końcu człowiek merguje branch sprintu do gałęzi głównej. ```mermaid flowchart LR M["Gałąź główna: main"] -- "Ty: git switch -c" --> S["Branch sprintu"] S -- "sesja ticketu" --> T1["Branch ticketu SKL-12"] S -- "sesja ticketu" --> T2["Branch ticketu SKL-13"] T1 -- "mr-queue: merge" --> S T2 -- "mr-queue: merge" --> S S -- "Ty: merge na końcu" --> M ``` Branch sprintu ma cztery przymiotniki, bo pełni cztery role naraz. Sesje biorą z niego kod, więc jest bazowy i źródłowy. Merge requesty ticketów trafiają do niego, więc jest docelowy. Zbiera pracę wszystkich ticketów, więc jest integracyjny. Wskazuje go jedna zmienna: `MONOLYNX_MR_TARGET`. > [!NOTE] > Zmienna `MONOLYNX_BRANCH_MODE` dotyczy czegoś innego: sprawdza nazwę brancha ticketu w pracy ręcznej. Jej wartość `sprint` nie oznacza brancha sprintu, tylko zgodę na dowolną nazwę brancha roboczego. W sprincie z pętlami nie musisz jej ustawiać. ## Jak wygląda sprint krok po kroku? Każdy krok ma jedno polecenie albo jedną czynność w panelu. Kolejność jest istotna: pętle sprawdzają stan z kroków wcześniejszych. **Kroki** 1. **Włącz zgody w repozytorium** Do śledzonego pliku `.claude/settings.json` dopisz `MONOLYNX_AUTOTEST`, `MONOLYNX_AUTOCOMMIT`, `MONOLYNX_AUTOPUSH` i `MONOLYNX_AUTOMR` z wartością `true`, zrób commit i wypchnij go. Trzy pierwsze są warunkiem startu dyspozytora. 2. **Napisz i sprawdź tickety** Dla każdego: `/monolynx:ticket-create "opis"`, potem `/monolynx:ticket-review KLUCZ`. 3. **Utwórz sprint i przypisz tickety** W panelu, w module Scrum. Każdy ticket przypisz do sprintu i przestaw z Backlog na Do zrobienia. 4. **Wystartuj sprint** Przycisk Wystartuj przy sprincie. Aktywny może być tylko jeden. 5. **Ustaw blokery** `/monolynx:ticket-review sprint` porównuje pliki ticketów i proponuje, który ma czekać na który. 6. **Utwórz branch sprintu** Odgałęź go od gałęzi głównej, wypchnij i zostań na nim. Krok jest zalecany, ale nieobowiązkowy: bez brancha sprintu pomijasz go razem ze zmienną z kroku 7, a merge requesty idą wprost do gałęzi głównej. 7. **Uruchom dwie pętle** W dwóch osobnych sesjach Claude Code, z tego samego katalogu i z ustawioną zmienną `MONOLYNX_MR_TARGET`. 8. **Zatwierdzaj i odpowiadaj** Kolejka pyta o zatwierdzenie każdego merge requesta. Sesje z werdyktem `waiting` czekają na Twoją odpowiedź. 9. **Zmerguj i zamknij** Gdy obie linie statusu pokazują zero: merge brancha sprintu do gałęzi głównej, potem `/monolynx:sprint-end`. **Kroki 6 i 7: branch sprintu i pętle** ```console $ git switch main $ git pull $ git switch -c sprint/platnosci $ git push -u origin sprint/platnosci $ export MONOLYNX_MR_TARGET=sprint/platnosci # okno 1 $ claude > /loop 15m /monolynx:sprint-run # okno 2, ten sam katalog, ta sama zmienna $ claude > /loop 10m /monolynx:mr-queue ``` **Krok 9: koniec sprintu** ```console # merge request sprint/platnosci -> main: otwierasz, czekasz na CI, mergujesz $ git switch main $ git pull $ unset MONOLYNX_MR_TARGET $ claude > /monolynx:sprint-end ``` > [!IMPORTANT] > Komenda `sprint-end` nie sprawdza, na jakim branchu stoisz. Uruchom ją z gałęzi głównej, po `git pull`. Gałąź główna oznacza w tych wpisach branch, do którego zmergowałeś sprint i od którego odgałęzisz następny. Zwykle jest to `main`, a w projekcie, który zbiera pracę na `develop`, właśnie `develop`. ## Co działa na której platformie? Pełny autopilot zakłada GitLab i CI. W innych układach sprint też działa, ale część kroków wraca do człowieka. **Porównanie** | Krok | GitLab z CI | GitHub z CI | Repozytorium bez CI | | --- | --- | --- | --- | | Sesje ticketów w tle | automat | automat | automat | | Otwarcie merge requesta | automat, przez `glab` | Ty: `gh pr create` dla każdego ticketu | Ty albo automat, zależnie od platformy | | Naprawa konfliktu i czerwonego CI | automat, przez kolejkę | automat, przez kolejkę | nie dotyczy | | Zatwierdzenie | Ty | Ty | Ty | | Merge ticketu | automat po Twojej zgodzie | automat po Twojej zgodzie | Ty; kolejka oddaje każdą pozycję człowiekowi | | Status Gotowe | automat po merge | automat po merge | Ty, w panelu | W GitHubie sesja ticketu kończy pracę normalnie: wypycha branch, ustawia status Review i zapisuje w komentarzu, że merge request nie powstał. Pull request otwierasz sam, a kolejka przejmuje go przy następnym ticku. > [!WARNING] > Pole `pełny przebieg: ci` na stronie `toolchain` wymaga działającego `glab`. W repozytorium na GitHubie zostaw wartość `lokalnie`, inaczej każda sesja w tle zakończy turę linią `SPRINT-RUN STOP`. ### Sprint w Codex zamiast Claude Code Plugin instaluje się w Codex z tego samego repozytorium, a komendy mają prefiks `$monolynx:` zamiast `/monolynx:`. Dyspozytor ma dla Codex osobny tryb, wybierany zmienną `MONOLYNX_SPRINT_RUNTIME=codex`. **Instalacja pluginu w Codex** ```console $ git clone https://gitlab.com/piotrkrych/monolynx.git $ cd monolynx $ codex plugin marketplace add . $ codex plugin add monolynx@monolynx ``` **Porównanie** | Czynność | Claude Code | Codex | | --- | --- | --- | | Pętla dyspozytora | `/loop` w sesji albo skrypt `sprint_run.sh` | tylko skrypt `sprint_run.sh` | | Lista sesji ticketów | `claude agents` | własny rejestr dyspozytora | | Wejście do sesji, która czeka | `claude attach ` | brak; czytasz plik logu sesji wskazany w komentarzu ticketu | | Agenci ról z pluginu | dostępni | nie przenoszą się automatycznie | Wpisy na tym blogu opisują obsługę sesji w Claude Code. W Codex mechanika pętli, werdykty i linia statusu są te same, a różni się tylko sposób podglądania sesji. ## Kto zatwierdza, gdy pracujesz sam? Kolejka potrzebuje Twojej zgody na każdy merge request. Wystarczy odpowiedź "tak" w rozmowie, o ile repozytorium nie wymaga formalnych zatwierdzeń. **Porównanie** | Ustawienie repozytorium | Co wystarcza | | --- | --- | | brak reguły wymaganych zatwierdzeń | Twoje "tak" w sesji kolejki | | wymagane zatwierdzenie, może je dać autor | zatwierdzasz w interfejsie platformy | | wymagane zatwierdzenie innej osoby | zatwierdza druga osoba; agent ani kolejka tego nie obejdą | Agent pracuje na Twoim koncie `glab` albo `gh`, więc autorem merge requestów jesteś Ty. W projekcie jednoosobowym regułę wymaganych zatwierdzeń najprościej wyłączyć, bo nie ma kto jej spełnić. ### Co zrobić z uwagami recenzenta? Agent nie czyta komentarzy w merge requeście sam. Wklej uwagi do komentarza ticketu, a poprawki zrób na branchu ticketu. Status ticketu zostaje Review: dyspozytor uznaje taki ticket za skończony i go nie rusza. Po Twoim pushu kolejka uruchamia CI od nowa i pyta o zatwierdzenie jeszcze raz. > [!CAUTION] > Przy działającej pętli dyspozytora nie przestawiaj ticketu sprintu na W trakcie i nie uruchamiaj na nim `/monolynx:work` w swojej sesji. Dyspozytor nie widzi sesji interaktywnych, więc uznałby ticket za porzucony i wystartował drugą sesję. Bezpieczną kolejność dla poprawek po recenzji i dla ticketów `needs-local` podaje wpis [Praca ręczna w trakcie sprintu](https://monolynx.com/blog/praca-reczna-w-sprincie-monolynx). ## Jak wygląda sprint z trzema ticketami? Poniżej przebieg przykładowego sprintu w projekcie `sklep`. Ticket SKL-13 zależy od SKL-12, a sesja SKL-14 utknie na pytaniu. Wyniki są przykładowe, ale mają dokładnie taki format jak prawdziwe. **Tick 1: dyspozytor startuje dwie sesje** ```console > /monolynx:sprint-run | Ticket | Sesja | Werdykt | Działanie | | SKL-12 | a1b2c3d4 | free -> running | start sesji | | SKL-14 | e5f6a7b8 | free -> running | start sesji | | SKL-13 | - | free -> pominięty | czeka na merge SKL-12 (todo) | SPRINT-RUN: remaining=1 running=2 waiting=0 done=0 ``` **Tick 3: jedna sesja skończyła, druga czeka** ```console | SKL-12 | a1b2c3d4 | done | komentarz + claude rm | | SKL-14 | e5f6a7b8 | waiting | pytanie w ostatniej odpowiedzi | | SKL-13 | - | free -> pominięty | czeka na merge SKL-12 (in_review) | Czekają na człowieka: - SKL-14: sesja pyta, czy eksport ma obejmować zamówienia anulowane claude attach e5f6a7b8 SPRINT-RUN: remaining=1 running=0 waiting=1 done=1 ``` Dwie rzeczy czekają teraz na Ciebie. Sesja SKL-14 potrzebuje odpowiedzi, a merge request SKL-12 zatwierdzenia. **Odpowiedź sesji, która czeka** ```console $ claude attach e5f6a7b8 > Tak, eksport obejmuje też zamówienia anulowane, z osobną kolumną statusu. ``` **Kolejka pyta o zatwierdzenie i merguje** ```console > /monolynx:mr-queue !42 SKL-12: eksport zamówień do CSV CI: zielone | konflikt: brak | zatwierdzenie: brak Approve !42 (SKL-12: eksport zamówień do CSV, SHA 4f2a9c1e)? tak / nie > tak MR-QUEUE: remaining=1 current=!42 verdict=needs_approval done=0 ``` Następny tick kolejki merguje `!42` i ustawia SKL-12 jako Gotowy. Kolejny tick dyspozytora widzi zamknięty bloker i startuje SKL-13. **Koniec: dyspozytor nie ma nic do zrobienia** ```console SPRINT-RUN: remaining=0 running=0 waiting=0 done=3 ``` Kolejka pokazuje w tym samym czasie `remaining=0` w swojej linii `MR-QUEUE`. **Statystyki** - **2** - Twoje interwencje w tym sprincie: jedna odpowiedź i zatwierdzenia - **3** - merge requesty zmergowane przez kolejkę - **0** - poleceń git wpisanych ręcznie między startem pętli a końcowym merge ## Gdzie patrzeć w trakcie sprintu? Trzy miejsca pokazują ten sam sprint z trzech stron. Na co dzień wystarcza pierwsze. **Porównanie** | Miejsce | Co pokazuje | Kiedy tam zajrzeć | | --- | --- | --- | | Ostatnia linia ticku | liczniki dyspozytora i kolejki | po każdym ticku | | Tablica w panelu | statusy ticketów | przed końcowym merge; liczy się status Gotowe | | Moduł Pipelines w panelu | przebieg pracy agentów nad każdym ticketem | gdy chcesz wiedzieć, co agent zrobił i jak go oceniono | Lista w module Pipelines ma jeden wiersz na przebieg pracy nad ticketem. Po wejściu w wiersz widzisz trzy kolumny etapów: `research`, `coding` i `wrap-up`. Każda zawiera karty zadań poszczególnych agentów ze statusem i czasem trwania. Karta otwiera log zadania. Widok odświeża się sam co 15 sekund, a przebieg bez zmian od ponad sześciu godzin jest oznaczony jako zawieszony. > [!TIP] > Logi przebiegów są stronami wiki pod stroną "Pipeline logi". Nie trafiają do wyszukiwania semantycznego, więc nie zaśmiecają odpowiedzi agenta. `sprint-end` przenosi z nich wiedzę do wiki i dopiero potem je usuwa. W projekcie bez metody LLM Wiki zostają i można je usunąć w panelu. ## Najczęstsze pytania **FAQ** ### Ile trwa i ile kosztuje taki sprint? Wpisy nie podają liczb, bo zależą od wielkości ticketów, czasu CI i modelu. Sposób pomiaru na jednym tickecie opisuje wpis [Test dymny przed pierwszym sprintem](https://monolynx.com/blog/test-dymny-przed-sprintem-monolynx). Pierwszy sprint puść na dwóch slotach i z trzema, czterema ticketami. ### Czy mogę pominąć branch sprintu? Tak. Bez `MONOLYNX_MR_TARGET` merge requesty trafiają do domyślnego brancha repozytorium. Kolejka czeka wtedy na zielone CI tego brancha po każdym merge, więc sprint idzie wolniej. ### Co znaczy tryb uprawnień auto? Sesje w tle startują w trybie `auto` Claude Code. Polecenia uznane za bezpieczne przechodzą bez pytania, a pozostałe są odrzucane. W tle nikt nie odpowie na pytanie o zgodę, więc sesja po odmowie kończy turę linią `SPRINT-RUN STOP` z powodem. ### Jak nazywa się branch ticketu w sprincie? Sesja w tle pracuje w osobnym katalogu nazwanym kluczem ticketu, a jej branch ma postać `worktree-SKL-12`. Nazwa zawiera numer ticketu, więc przechodzi domyślną kontrolę nazw. ### Czy mogę zrobić jeden ticket sprintu sam, gdy pętle działają? Tak, ale nie przez samą zmianę statusu. Ticket trzeba najpierw odpiąć od sprintu albo zatrzymać pętlę dyspozytora. Kroki podaje wpis [Praca ręczna w trakcie sprintu](https://monolynx.com/blog/praca-reczna-w-sprincie-monolynx). ### Co, jeśli w trakcie sprintu coś pójdzie źle? Zatrzymanie pętli, wyjęcie ticketu i odblokowanie kolejki opisuje wpis [Awaryjnie: jak zatrzymać sprint, wyjąć ticket i posprzątać](https://monolynx.com/blog/awaryjne-zatrzymanie-sprintu-monolynx). ## Słownik i następny krok **Słownik** - **Gałąź główna** - domyślny branch repozytorium, zwykle `main` - **Branch sprintu** - branch zbierający pracę całego sprintu; wskazuje go `MONOLYNX_MR_TARGET` - **Branch ticketu** - branch jednej sesji, mergowany do brancha sprintu - **Pętla** - komenda powtarzana co stały czas: dyspozytor `sprint-run` albo kolejka `mr-queue` - **Tick** - jedno uruchomienie komendy pętli - **Slot** - miejsce na jedną równoległą sesję ticketu Codzienną obsługę pętli, czyli co wpisać rano i jak czytać obie linie statusu, zbiera wpis [Dzień sprintu: ściąga i tabela decyzji](https://monolynx.com/blog/dzien-sprintu-monolynx). Uzasadnienie każdego kroku i warianty opisuje przewodnik [Sprint z Monolynx krok po kroku](https://monolynx.com/blog/sprint-z-monolynx-krok-po-kroku). Flagi i pliki, w których je ustawiasz, zbiera wpis [Konfiguracja: która zmienna w którym pliku](https://monolynx.com/blog/konfiguracja-monolynx-zmienne). Raporty pętli uczy czytać wpis [Sesje w tle: jak obserwować pętle sprintu](https://monolynx.com/blog/sesje-w-tle-monolynx). **Wezwanie do działania** Chcesz zobaczyć, jak wygląda przebieg pracy agentów w panelu? [Zobacz moduł Pipelines w Monolynx](https://monolynx.com/features/pipelines)