Sprint z Monolynx krok po kroku: od planu do sprint-end

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.

# 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

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.

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.

{
  "env": {
    "MONOLYNX_AUTOTEST": "true",
    "MONOLYNX_AUTOCOMMIT": "true",
    "MONOLYNX_AUTOPUSH": "true",
    "MONOLYNX_AUTOMR": "true"
  }
}

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

1. Napisz tickety

   Komenda /monolynx:ticket-create rozbija temat na tickety z kryteriami akceptacji. Szczegóły opisuje wpis Jak działa /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.

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.

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

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.

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ść.

$ git switch sprint/platnosci
$ export MONOLYNX_MR_TARGET=sprint/platnosci
$ claude
> /loop 15m /monolynx:sprint-run

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

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

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.

# 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

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, a sam dyspozytor ma swój: Jak działa /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.

Co w tym czasie robi człowiek?

Pętle nie zastępują Twoich decyzji, tylko zbierają je w kilku miejscach.

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

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.

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.

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.

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.

Pełny opis zamknięcia znajdziesz we wpisie Jak działa /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.

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.

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

Najczęstsze pytania

Słownik i następny krok

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, ticket-review, work, sprint-run, mr-queue, sprint-end i skille LLM Wiki.

Przed pierwszym sprintem przydadzą się wpisy Jak połączyć agenta AI z Monolynx, Pierwszy projekt w Monolynx i Sprint w panelu Monolynx. W trakcie sprintu pomagają Sesje w tle, Konfiguracja: która zmienna w którym pliku i Gdy coś nie działa w Monolynx. Wszystkie komendy zbiera Mapa pluginu Monolynx.