--- title: "Sprint z Monolynx krok po kroku: od planu do sprint-end" description: "Przewodnik po sprincie z agentami AI: plan, pętle sprint-run i mr-queue, merge do develop i main, zamknięcie przez sprint-end. Wyjaśniamy też, kiedy potrzebny jest wiki-sync-merge." url: "https://monolynx.com/blog/sprint-z-monolynx-krok-po-kroku" lang: "pl" author: "Zespół Monolynx" published: "2026-10-08T08:19:27.801846+00:00" modified: "2026-10-09T18:11:38.658438+00:00" last_verified: "2026-10-08" tags: ["plugin", "claude-code", "agenci-ai", "scrum", "sprint"] translations: [] reading_time_minutes: 14 word_count: 2702 --- > [!TLDR] > - Sprint w Monolynx to pięć etapów: przygotowanie projektu, plan, dwie pętle, merge i zamknięcie. > - Pracę wykonują dwie pętle: `/loop 15m /monolynx:sprint-run` startuje sesje ticketów, `/loop 10m /monolynx:mr-queue` merguje ich MR-y po kolei. > - Branch źródłowy i docelowy ticketów to ten sam branch sprintu, a nie `main`. > - Człowiek zatwierdza MR-y, odpowiada sesjom, które czekają na decyzję, i merguje branch sprintu do `develop` i `main`. > - Sprint zamyka `/monolynx:sprint-end`. Osobny `/monolynx:wiki-sync-merge` nie jest wtedy potrzebny. ## Jak wygląda cały sprint w jednym obrazku? Sprint prowadzony przez agentów ma stały rytm. Ty planujesz i decydujesz, a dwie pętle wykonują pracę między Twoimi decyzjami. Poniżej wszystkie komendy, które wpisujesz w trakcie sprintu, w kolejności użycia. **Sprint od startu do zamknięcia** ```console # raz na projekt /monolynx:setup # plan sprintu /monolynx:ticket-create /monolynx:ticket-review SKL-12 # po starcie sprintu w panelu /monolynx:ticket-review sprint # praca: dwie pętle w dwóch sesjach /loop 15m /monolynx:sprint-run /loop 10m /monolynx:mr-queue # po merge brancha sprintu do develop i main /monolynx:sprint-end ``` **Statystyki** - **2** - pętle, które prowadzą sprint między decyzjami człowieka - **15 min** - zalecany odstęp ticków dyspozytora `sprint-run` - **10 min** - zalecany odstęp ticków kolejki `mr-queue` - **1** - komenda zamykająca sprint: `sprint-end` **Obieg sprintu w Monolynx** Plan sprintu trafia do dyspozytora sprint-run, który startuje sesję work dla każdego wolnego ticketu. Sesja kończy się merge requestem do brancha sprintu. Kolejka mr-queue merguje te MR-y po kolei po zielonym CI i zatwierdzeniu przez człowieka. Gdy wszystkie tickety są zamknięte, człowiek merguje branch sprintu do develop i main, a sprint-end przenosi wiedzę do wiki i zamyka sprint. ```mermaid flowchart TD A["Plan: ticket-create i ticket-review"] --> B["Start sprintu i branch sprintu"] B --> C["Pętla sprint-run co 15 min"] C --> D["Sesja work w osobnym worktree"] D --> E["MR do brancha sprintu"] E --> F["Pętla mr-queue co 10 min"] F --> G{"Wszystkie tickety done?"} G -- nie --> C G -- tak --> H["Merge: sprint do develop, develop do main"] H --> I["sprint-end: wiki i complete_sprint"] ``` ## Etap 1: przygotowanie projektu Przygotowanie robisz raz, nie przed każdym sprintem. Komenda `/monolynx:setup` sprawdza konfigurację projektu punkt po punkcie i przy każdym braku proponuje skill, który go naprawi: `/monolynx:project-toolchain` zapisuje komendy lintu i testów na stronie wiki `toolchain`, a `/monolynx:wiki-init` włącza metodę LLM Wiki. O tej metodzie przeczytasz we wpisie [Jak działają skille LLM Wiki](https://monolynx.com/blog/jak-dzialaja-skille-llm-wiki). Dyspozytor startuje sesje w tle, więc nikt nie odpowie im na pytanie "czy mogę uruchomić testy". Zgody ustawiasz z góry jako flagi w śledzonym pliku `.claude/settings.json`. ```json title=".claude/settings.json" { "env": { "MONOLYNX_AUTOTEST": "true", "MONOLYNX_AUTOCOMMIT": "true", "MONOLYNX_AUTOPUSH": "true", "MONOLYNX_AUTOMR": "true" } } ``` **Porównanie** | Flaga | Na co pozwala | Bez niej | | --- | --- | --- | | `MONOLYNX_AUTOTEST` | lint i testy bez pytania | `sprint-run` nie wystartuje | | `MONOLYNX_AUTOCOMMIT` | commit po zielonej bramce | `sprint-run` nie wystartuje | | `MONOLYNX_AUTOPUSH` | push brancha ticketu | `sprint-run` nie wystartuje | | `MONOLYNX_AUTOMR` | otwarcie merge requesta | ostrzeżenie, MR otwierasz ręcznie | | `MONOLYNX_AUTOMERGE` | merge gotowego MR-a bez pytania | `mr-queue` pyta przed każdym merge | > [!IMPORTANT] > Flagi muszą być w śledzonym `.claude/settings.json` albo w środowisku procesu, który uruchamia pętlę. Sesja w osobnym worktree nie widzi pliku `.claude/settings.local.json`. ## Etap 2: plan sprintu Jakość sprintu rozstrzyga się przed jego startem. Agent w tle nie dopyta o szczegóły, więc ticket musi nieść kontrakt: co ma powstać, po czym poznać, że jest gotowe, i czego nie ruszać. **Kroki** 1. **Napisz tickety** Komenda `/monolynx:ticket-create` rozbija temat na tickety z kryteriami akceptacji. Szczegóły opisuje wpis [Jak działa /monolynx:ticket-create](https://monolynx.com/blog/jak-dziala-monolynx-ticket-create). 2. **Przejrzyj każdy ticket** Komenda `/monolynx:ticket-review` szuka luk w kontrakcie, zanim znajdzie je agent w połowie pracy. Więcej we wpisie [Jak działa /monolynx:ticket-review](https://monolynx.com/blog/jak-dziala-monolynx-ticket-review). 3. **Przypisz tickety do sprintu i ustaw Do zrobienia** Nowy ticket ma status Backlog. Dyspozytor bierze tylko tickety w statusie Do zrobienia z aktywnego sprintu, więc każdy ticket planu przypisz do sprintu i przestaw w panelu. Statusy opisuje wpis [Statusy ticketu w Monolynx](https://monolynx.com/blog/statusy-ticketu-w-monolynx). 4. **Uruchom sprint** Sprint startujesz w panelu, w module Scrum. W projekcie może być tylko jeden aktywny sprint. 5. **Przejrzyj sprint jako całość** Wywołanie `/monolynx:ticket-review sprint` czyta tickety Do zrobienia aktywnego sprintu, dlatego działa dopiero po jego starcie. Porównuje pliki, których dotkną tickety, i proponuje blokery tam, gdzie dwa tickety weszłyby sobie w drogę. > [!TIP] > Blokery ustawione w planie to kolejność pracy dyspozytora. Ticket, którego bloker nie jest jeszcze `done`, nie dostanie sesji, więc dwa tickety zmieniające ten sam plik nie pójdą równolegle. ## Jak ustawić branch źródłowy i docelowy sprintu? Każdy ticket ma dwa branche, które decydują o tym, skąd bierze kod i dokąd go oddaje. Branch źródłowy (source) to stan, z którego startuje sesja ticketu. Branch docelowy (target) to branch, do którego sesja otwiera merge request. W sprincie oba powinny wskazywać branch sprintu, na przykład `sprint/platnosci`, a nie `main`. **Porównanie** | Ustawienie | Rola | Kto je czyta | Wartość w sprincie | | --- | --- | --- | --- | | `MONOLYNX_BASE_BRANCH` | branch źródłowy: baza sesji ticketu i punkt synchronizacji przed pracą | `sprint-run`, `work` | branch sprintu | | `MONOLYNX_MR_TARGET` | branch docelowy: cel merge requestów ticketów | `work`, `mr-queue`, `sprint-end` | branch sprintu | Obie zmienne nazywają ten sam branch, dlatego wystarczy ustawić jedną. Zwykle jest to `MONOLYNX_MR_TARGET`, bo tylko ona ustawia także cel merge requesta w sesji `work`, a branch źródłowy przyjmuje wtedy tę samą wartość. **Branch sprintu w środowisku, z którego startują pętle** ```console $ git switch sprint/platnosci $ export MONOLYNX_MR_TARGET=sprint/platnosci $ claude > /loop 15m /monolynx:sprint-run ``` **Kroki** 1. **Utwórz branch sprintu** Odgałęź go od `develop` albo `main` i wypchnij do repozytorium, zanim uruchomisz pętle. 2. **Ustaw zmienną** Najpewniejszy jest `export MONOLYNX_MR_TARGET=...` w terminalu, z którego startujesz pętle. Plik `.claude/settings.local.json` głównego checkoutu też działa, ale tylko pośrednio: czyta go sesja dyspozytora i przekazuje wartość dalej. Powody opisuje wpis [Konfiguracja: które zmienne gdzie ustawić](https://monolynx.com/blog/konfiguracja-monolynx-zmienne). Sesje ticketów dziedziczą środowisko dyspozytora, więc każda zna branch docelowy, choć sama pracuje w worktree i pliku osobistego nie widzi. 3. **Przełącz główny checkout** Checkout, z którego startujesz pętle, stoi na branchu sprintu przez cały sprint. Sesje w tle biorą jego bieżący stan jako punkt wyjścia. 4. **Po sprincie usuń ustawienie** Zmienna wskazująca zamknięty branch sprintu skierowałaby kolejne tickety w złe miejsce. > [!WARNING] > `MONOLYNX_BASE_BRANCH` i `MONOLYNX_MR_TARGET` ustawione na dwa różne branche to błąd konfiguracji. Zarówno `sprint-run`, jak i `mr-queue` odrzucają taki stan w kontroli wstępnej i nie wykonują ticku. Źródło i cel muszą być tym samym branchem z prostego powodu: ticket zmergowany do brancha sprintu powinien być widoczny dla następnego ticketu. Gdy dyspozytor wykryje, że lokalny branch źródłowy jest za zdalnym, sam go dociąga, wyłącznie przez fast-forward. Sesja ticketu robi to samo przed rozpoczęciem pracy. **Dlaczego branch sprintu, a nie main** Merge do brancha sprintu domyka ticket od razu, na podstawie zielonego CI samego merge requesta. Merge do domyślnego brancha wymaga dodatkowo zielonego CI tego brancha po merge, więc kolejka czeka dłużej na każdy ticket. Branch sprintu daje też jedno miejsce, w którym widać cały sprint przed wydaniem: jeden przegląd, jedno CI, jeden merge do `develop`. Jeśli Twój zespół integruje wprost na `develop`, branchem sprintu może być `develop` i wtedy odpada jeden merge w etapie 4. ## Etap 3: dwie pętle Praca nad ticketami to dwie komendy uruchomione w dwóch sesjach Claude Code. Obie są idempotentne: każdy tick czyta stan od zera, wykonuje jeden krok i kończy się jedną linią statusu. **Dwie sesje, dwie pętle** ```console # sesja 1: dyspozytor > /loop 15m /monolynx:sprint-run SPRINT-RUN: remaining=6 running=3 waiting=0 done=2 # sesja 2: kolejka merge requestów > /loop 10m /monolynx:mr-queue MR-QUEUE: remaining=2 current=!84 verdict=wait done=3 ``` **Porównanie** | Cecha | `sprint-run` | `mr-queue` | | --- | --- | --- | | Zadanie | startuje sesje ticketów i zbiera zakończone | prowadzi MR-y do merge, jeden po drugim | | Jednostka pracy | ticket ze statusem `todo` | otwarty merge request | | Zalecana pętla | `/loop 15m` | `/loop 10m` | | Czego nie robi | sam nie pracuje nad ticketem | nie zatwierdza MR-a za człowieka | | Kiedy woła człowieka | sesja czeka na decyzję albo wymaga interwencji | brak zatwierdzenia, konflikt nie do rozwiązania | **Zalecany odstęp ticków w minutach** | Pętla | Minuty | | --- | --- | | sprint-run | 15 | | mr-queue | 10 | Dyspozytor daje każdemu wolnemu ticketowi sesję w tle i własny worktree, a w sesji uruchamia `/monolynx:work`. Co dzieje się w środku takiej sesji, opisuje wpis [Jak działa /monolynx:work](https://monolynx.com/blog/jak-dziala-monolynx-work), a sam dyspozytor ma swój: [Jak działa /monolynx:sprint-run](https://monolynx.com/blog/jak-dziala-monolynx-sprint-run). Kolejka bierze pierwszy niezmergowany MR i wykonuje jedną akcję w stałej kolejności: konflikt, czerwone CI, zatwierdzenie, merge. Pełny opis znajdziesz we wpisie [Jak działa /monolynx:mr-queue](https://monolynx.com/blog/jak-dziala-monolynx-mr-queue). > [!NOTE] > Pętla jest na zewnątrz skilla. Na serwerze bez sesji interaktywnej tę samą rolę pełni skrypt `sprint_run.sh` uruchamiany w tmux albo z crona. ### Co w tym czasie robi człowiek? Pętle nie zastępują Twoich decyzji, tylko zbierają je w kilku miejscach. **Porównanie** | Krok | Automat | Człowiek | | --- | --- | --- | | Start sesji dla ticketu | tak | nie | | Kod, testy, review w sesji | tak | nie | | Rozwiązanie konfliktu: wciągnięcie brancha sprintu do brancha ticketu | tak | gdy konfliktu nie da się rozwiązać | | Poprawka czerwonego CI | tak, najwyżej dwie rundy | po dwóch nieudanych rundach | | Zatwierdzenie MR-a | nie | zawsze | | Odpowiedź sesji, która zadała pytanie | nie | zawsze | | Merge do `develop` i `main` | nie | zawsze | Trzy sygnały wymagają Twojej reakcji: werdykt `waiting` w statusie dyspozytora (sesja zadała pytanie), werdykt `needs_human` (sesja skończyła się bez wyniku) i werdykt `needs_approval` w kolejce (MR czeka na zatwierdzenie). > Zatwierdzenie merge requesta to decyzja człowieka. Żadna flaga jej nie wyłącza. > -- zasada skilla mr-queue ## Etap 4: merge do develop i main Pętle kończą pracę, gdy obie linie statusu pokazują zero: `remaining=0 running=0` w dyspozytorze i `remaining=0` w kolejce. Wtedy cały sprint leży na branchu sprintu i zaczyna się część, której Monolynx celowo nie automatyzuje. **Kroki** 1. **Sprawdź tablicę** Wszystkie tickety sprintu mają status `done`, w panelu Gotowe. Nie myl go z licznikiem `done=` w linii statusu dyspozytora: ten liczy też tickety, które dopiero czekają w review. Ticket, który został w innym statusie, wróci do backlogu przy zamknięciu sprintu. 2. **Zmerguj branch sprintu do develop** Otwórz merge request z brancha sprintu i poczekaj na zielone CI. Ten krok znika, gdy branchem sprintu był od początku `develop`. Projekt bez brancha `develop` też go pomija i w następnym kroku merguje branch sprintu wprost do `main`. 3. **Zmerguj develop do main** Drugi merge request, zielone CI brancha `main`, wdrożenie według zasad Twojego projektu. 4. **Zatrzymaj pętle** Obie sesje z `/loop` można zamknąć. Kolejny tick nie miałby nic do zrobienia. Przełącz główny checkout z powrotem na `main`, wykonaj `git pull` i zdejmij `MONOLYNX_MR_TARGET`, bo wskazuje branch skończonego sprintu. > [!WARNING] > Merge do `main` robi człowiek. Kolejka `mr-queue` prowadzi merge requesty ticketów, a nie wydanie całego sprintu. ## Etap 5: zamknięcie sprintu Sprint zamyka jedna komenda: `/monolynx:sprint-end`. Bez argumentu bierze aktywny sprint i wykonuje dwa kroki: najpierw wiedza, potem zamknięcie. **Kroki** 1. **INGEST** Skill `wiki-ingest` czyta strony "Pipeline logi" sprintu, czyli raporty agentów z pracy nad ticketami, i przenosi wiedzę na strony wiki. 2. **LINT** Skill `wiki-lint` szuka sierot, martwych linków i sprzeczności w wiki. 3. **Czyszczenie logów** Strony logów są usuwane, ale tylko po udanym INGEST. Po nieudanym zostają, bo są jedynym źródłem wiedzy ze sprintu. 4. **Kroki opcjonalne** Pełny przebieg mutacyjny z trendem, retrospektywa `retro` i numer wydania pluginu, każdy tylko wtedy, gdy projekt go używa. 5. **Zamknięcie** Po Twoim potwierdzeniu skill wywołuje `complete_sprint` i wypisuje podsumowanie sprintu. > [!CAUTION] > `complete_sprint` jest nieodwracalne. Niedokończone tickety wracają do backlogu, dlatego skill pyta o potwierdzenie przed tym krokiem. Pełny opis zamknięcia znajdziesz we wpisie [Jak działa /monolynx:sprint-end](https://monolynx.com/blog/jak-dziala-monolynx-sprint-end). Kolejność jest jedna: najpierw merge brancha sprintu do gałęzi głównej, potem `sprint-end`. Komendę uruchamiasz z gałęzi głównej po `git pull`; sama brancha nie sprawdza, więc pilnujesz tego Ty. Jedyny wyjątek opisuje ramka poniżej i dotyczy wyłącznie repozytoriów, które same wydają plugin Claude Code. **Wyjątek: projekt, który sam wydaje plugin Claude Code** Projekt, który wydaje własny plugin i zbiera wpisy changelogu pod nagłówkiem `Unreleased`, ma w `sprint-end` dodatkowy krok: nadanie numeru wydania na osobnym branchu `release/plugin-X.Y.Z`, z merge requestem do brancha docelowego. W takim projekcie numer nadaje się na branchu sprintu, zanim ten trafi do `main`, więc `sprint-end` uruchamiasz przed ostatnim merge. W projekcie bez pluginu krok jest pomijany i kolejność z tego wpisu zostaje bez zmian. ## Czy po drodze trzeba uruchomić wiki-sync-merge? Nie, w sprincie zamykanym przez `sprint-end` osobny `/monolynx:wiki-sync-merge` nie jest potrzebny. Oba skille robią to samo dla wiki, czyli INGEST wiedzy z wykonanej pracy, tylko dla innej porcji pracy i w innym momencie. **Porównanie** | Cecha | `wiki-sync-merge` | `sprint-end` | | --- | --- | --- | | Zakres | ticket albo lista ticketów podana w argumencie | cały aktywny sprint | | Kiedy | po merge ticketu do brancha integracyjnego | po zakończeniu pracy nad sprintem | | Źródło wiedzy | kontekst wskazanych ticketów | logi pipeline'ów całego sprintu | | Audyt wiki | nie | tak, `wiki-lint` | | Zamknięcie sprintu | nie | tak, `complete_sprint` | | Pasuje do | pojedynczy ticket, hotfix, praca poza sprintem | sprint prowadzony pętlami | Po `wiki-sync-merge` sięgasz w trzech sytuacjach: pracujesz ścieżką ręczną nad jednym ticketem, mergujesz hotfix poza sprintem, albo sprint trwa długo i chcesz, żeby wiedza z kluczowego ticketu była w wiki już teraz, bo kolejne tickety z niej korzystają. > [!NOTE] > `wiki-sync-merge` zapisuje do wiki tylko wtedy, gdy checkout stoi na branchu integracyjnym, czyli tym z `MONOLYNX_BASE_BRANCH` albo `MONOLYNX_MR_TARGET`, a projekt ma włączoną metodę LLM Wiki. Gdy żadna z tych zmiennych nie jest ustawiona, branchem integracyjnym jest domyślny branch repozytorium. Na innym branchu kończy pracę bez zapisu. ## Najczęstsze pytania **FAQ** ### Czy obie pętle muszą działać jednocześnie? Nie muszą, ale tak jest najszybciej. Sam `sprint-run` doprowadzi tickety do otwartych merge requestów, które będą czekać. Sam `mr-queue` zmerguje to, co już jest otwarte. Razem tworzą przepływ: ticket, sesja, MR, merge, kolejny ticket. ### Czy branch źródłowy i docelowy mogą być różne? Nie w sprincie. Obie zmienne nazywają jeden branch, a dwie różne wartości zatrzymują obie pętle w kontroli wstępnej. Ustaw samą `MONOLYNX_MR_TARGET` na branch sprintu. ### Ile ticketów idzie równolegle? Liczbę równoległych sesji podajesz jako argument, na przykład `/monolynx:sprint-run 3`. Tickety z migracją bazy idą pojedynczo, a ticket z niezamkniętym blokerem czeka. ### Co zrobić, gdy sesja ticketu czeka na odpowiedź? Wejdź do sesji wskazanej w raporcie dyspozytora i odpowiedz. Dyspozytor nie rusza sesji w stanie `waiting`, a przy zbyt wielu czekających przestaje startować nowe. ### Czy mogę zamknąć sprint, gdy część ticketów nie jest gotowa? Tak. `sprint-end` ostrzeże, że niedokończone tickety wrócą do backlogu, i poczeka na potwierdzenie. Wiedza z ukończonych ticketów trafi do wiki normalnie. ### Co, jeśli projekt nie ma włączonej metody LLM Wiki? Pętle działają bez niej. Kroki wiki w `sprint-end` nie mają wtedy czego zapisać, a `wiki-sync-merge` kończy się informacją, że metoda jest wyłączona. Włączasz ją komendą `/monolynx:wiki-init`. ## Słownik i następny krok **Słownik** - **Tick** - jedno wykonanie skilla w pętli: odczyt stanu, jeden krok, linia statusu - **Branch sprintu** - branch integracyjny, który jest jednocześnie źródłem i celem ticketów sprintu - **Branch źródłowy** - branch, z którego startuje sesja ticketu, wskazany w `MONOLYNX_BASE_BRANCH` - **Branch docelowy** - branch, do którego trafiają merge requesty ticketów, wskazany w `MONOLYNX_MR_TARGET` - **Worktree** - osobny katalog roboczy gita, w którym sesja ticketu pracuje bez kolizji z innymi - **INGEST** - operacja metody LLM Wiki, która przenosi wiedzę ze źródła na strony wiki - **Dyspozytor** - skill `sprint-run`, który startuje i zbiera sesje, ale sam nie pracuje nad ticketem Każdy skill z tego przewodnika ma własny wpis: [ticket-create](https://monolynx.com/blog/jak-dziala-monolynx-ticket-create), [ticket-review](https://monolynx.com/blog/jak-dziala-monolynx-ticket-review), [work](https://monolynx.com/blog/jak-dziala-monolynx-work), [sprint-run](https://monolynx.com/blog/jak-dziala-monolynx-sprint-run), [mr-queue](https://monolynx.com/blog/jak-dziala-monolynx-mr-queue), [sprint-end](https://monolynx.com/blog/jak-dziala-monolynx-sprint-end) i [skille LLM Wiki](https://monolynx.com/blog/jak-dzialaja-skille-llm-wiki). Przed pierwszym sprintem przydadzą się wpisy [Jak połączyć agenta AI z Monolynx](https://monolynx.com/blog/polaczenie-z-monolynx-mcp-claude-code-chatgpt), [Pierwszy projekt w Monolynx](https://monolynx.com/blog/pierwszy-projekt-w-monolynx) i [Sprint w panelu Monolynx](https://monolynx.com/blog/sprint-w-panelu-monolynx). W trakcie sprintu pomagają [Sesje w tle](https://monolynx.com/blog/sesje-w-tle-monolynx), [Konfiguracja: która zmienna w którym pliku](https://monolynx.com/blog/konfiguracja-monolynx-zmienne) i [Gdy coś nie działa w Monolynx](https://monolynx.com/blog/gdy-cos-nie-dziala-w-monolynx). Wszystkie komendy zbiera [Mapa pluginu Monolynx](https://monolynx.com/blog/mapa-pluginu-monolynx). **Wezwanie do działania** Chcesz przeprowadzić pierwszy sprint z agentami na własnym projekcie? [Zobacz moduł Scrum w Monolynx](https://monolynx.com/features/scrum)