--- title: "Od pustego repozytorium do zmergowanego ticketu: cały przebieg" description: "Jeden mały przykład od git init do zmergowanej zmiany: projekt, setup, strona toolchain, ticket, praca agenta, merge request i status Gotowe." url: "https://monolynx.com/blog/od-repozytorium-do-zmergowanego-ticketu" lang: "pl" author: "Zespół Monolynx" published: "2026-10-09T11:36:23.446999+00:00" modified: "2026-10-09T18:11:24.048698+00:00" last_verified: "2026-10-09" tags: ["plugin", "claude-code", "agenci-ai", "scrum"] translations: [] reading_time_minutes: 10 word_count: 1840 --- > [!TLDR] > - Wpis prowadzi jeden mały przykład od pustego repozytorium do zmergowanego ticketu, bez przeskoków między etapami. > - Przykład to pakiet `sklep` w Pythonie z jedną funkcją i ticket SKL-1: rabat procentowy w sumie zamówienia. > - Na każdym etapie widać trzy rzeczy: co wpisujesz, co odpowiada komenda i co po etapie zostaje. > - Praca idzie ręcznie, z jedną zgodą: agent sam uruchamia lint i testy. Commit, push i merge robisz Ty. > - Wyniki komend są przykładowe i skrócone. Polecenia, nazwy pól i stałe linie są takie jak w pluginie. ## Co dokładnie zobaczysz w tym przebiegu? Pozostałe wpisy opisują komendy pojedynczo. Tutaj idą po kolei, na jednym repozytorium i jednym tickecie, tak jak pierwszego dnia pracy z Monolynx. **Porównanie** | Etap | Kto działa | Co zostaje po etapie | | --- | --- | --- | | 1. Repozytorium i projekt | Ty | repozytorium z plikiem `.claude/settings.json`, projekt `sklep` na platformie | | 2. Konfiguracja | Ty i komenda `setup` | strona wiki `Toolchain` | | 3. Ticket | Ty i komenda `ticket-create` | ticket SKL-1 z kryteriami akceptacji | | 4. Praca agenta | komenda `work-simple` | zmiana w kodzie, komentarze na tickecie, status Review | | 5. Commit i merge request | Ty | branch w repozytorium i otwarty merge request | | 6. Merge i zamknięcie | Ty | zmiana na gałęzi głównej, status Gotowe | **Statystyki** - **6** - etapów od pustego katalogu do zmergowanej zmiany - **4** - komendy pluginu użyte po drodze - **1** - zgoda dana agentowi: uruchamianie lintu i testów - **2** - pliki zmienione przez agenta **Cały przebieg na jednej osi** Najpierw powstaje repozytorium i projekt na platformie. Komenda setup sprawdza konfigurację, a project-toolchain zapisuje stronę z komendami lintu i testów. Komenda ticket-create tworzy ticket, a work-simple prowadzi agenta do statusu Review. Commit, push, merge request i merge wykonuje człowiek, po czym ustawia status Gotowe. ```mermaid flowchart LR A["git init"] --> B["Projekt i plugin"] B --> C["setup i project-toolchain"] C --> D["ticket-create"] D --> E["work-simple"] E --> F["commit, push, merge request"] F --> G["merge"] G --> H["Gotowe"] ``` ## Etap 1: repozytorium i projekt Repozytorium jest celowo małe: jedna funkcja i jeden test. **Nowe repozytorium z jedną funkcją** ```console $ mkdir sklep && cd sklep && git init -b main $ ls -R pyproject.toml sklep/__init__.py sklep/koszyk.py tests/test_koszyk.py $ git add . && git commit -m "Start: suma zamówienia" $ git remote add origin git@gitlab.com:twoja-firma/sklep.git $ git push -u origin main ``` ```python title="sklep/koszyk.py" def suma_zamowienia(pozycje): return sum(cena * ilosc for cena, ilosc in pozycje) ``` Na platformie zakładasz projekt o nazwie `sklep`, ze slugiem `sklep` i kodem projektu `SKL`. Kod jest przedrostkiem kluczy ticketów, więc pierwszy ticket dostanie klucz SKL-1. Potem w sesji Claude Code instalujesz plugin i mówisz repozytorium, z którym projektem pracuje. ```text title="Sesja Claude Code w katalogu sklep" /plugin marketplace add https://gitlab.com/piotrkrych/monolynx.git /plugin install monolynx@monolynx ``` ```json title=".claude/settings.json" { "env": { "MONOLYNX_PROJECT_SLUG": "sklep", "MONOLYNX_AUTOTEST": "true" } } ``` Flaga `MONOLYNX_AUTOTEST` to jedyna zgoda w tym przebiegu. Pozwala agentowi samodzielnie uruchamiać lint i testy. Bez niej agent wypisywałby polecenia i czekał, aż wkleisz wynik. > [!NOTE] > Plik `.claude/settings.json` commitujesz do repozytorium. Konto, role i szczegóły instalacji opisuje wpis [Pierwszy projekt w Monolynx](https://monolynx.com/blog/pierwszy-projekt-w-monolynx). ## Etap 2: konfiguracja projektu Komenda `/monolynx:setup` pokazuje, czego brakuje. W nowym projekcie brakuje prawie wszystkiego, ale do pierwszego ticketu potrzebny jest tylko punkt 2. **Setup w nowym projekcie (przykład)** ```console > /monolynx:setup | Punkt | Stan | Skill naprawczy | | 1. Slug projektu | OK (sklep) | - | | 2. Strona wiki toolchain | BRAK | /monolynx:project-toolchain | | 3. LLM Wiki | BRAK | /monolynx:wiki-init | | 4. Graf zależności w CI | BRAK | /monolynx:create-graph-ci-script | | 5. Testy mutacyjne w CI | BRAK | /monolynx:create-mutation-ci-script | | 6. Flagi MONOLYNX_* | INFO (1 jawnie ustawiona) | - | | 7. CLI monolynx | BRAK (niezainstalowane) | - | Które punkty naprawić? ``` Wybierasz punkt 2. Komenda `project-toolchain` wykrywa stack z pliku `pyproject.toml`, pokazuje proponowane komendy i po Twoim potwierdzeniu zapisuje stronę. ```markdown title="Strona wiki Toolchain projektu sklep (fragment)" ## Lint komenda: ruff check . kto odpala: agent ## Test komenda: pytest kto odpala: agent testy istnieja: tak framework: pytest pełny przebieg: lokalnie ## Worktree lint: jak wyzej test: jak wyzej izolacja testów: tak ``` Pełny format strony i znaczenie każdego pola opisuje wpis [Strona toolchain i /monolynx:setup](https://monolynx.com/blog/strona-toolchain-i-monolynx-setup). ## Etap 3: ticket Komendzie `ticket-create` podajesz temat jednym zdaniem. Komenda czyta kod, dopytuje o szczegóły i zapisuje ticket o stałej budowie. **Tworzenie ticketu (przykład)** ```console > /monolynx:ticket-create Rabat procentowy w sumie zamówienia Ticket SKL-1 utworzony (2 SP, status: Backlog) Kryteria akceptacji: 3 ``` ```markdown title="Opis ticketu SKL-1 (skrócony)" ## Cel Funkcja suma_zamowienia przyjmuje opcjonalny rabat procentowy. ## Zakres - parametr rabat_procent w suma_zamowienia, domyślnie 0 - błąd ValueError dla rabatu poza zakresem 0-100 ## Pliki dotykane - `sklep/koszyk.py` - `tests/test_koszyk.py` ## Nie ruszac - sposób zaokrąglania kwot ## Kryteria akceptacji - suma bez rabatu nie zmienia się - rabat 10 zmniejsza sumę o 10 procent - rabat spoza zakresu 0-100 kończy się błędem ValueError ``` Sekcja "Nie ruszac" jest dla agenta równie ważna jak zakres. Mówi, czego nie poprawiać przy okazji. > [!TIP] > Przed pracą warto uruchomić `/monolynx:ticket-review SKL-1`. Komenda porównuje ticket z kodem i z wiki i wskazuje luki, zanim trafi na nie agent. ## Etap 4: praca agenta Ticket ma 2 story points, więc wystarcza `work-simple`: jeden programista i krytyk. Komenda zaczyna od brancha. **Start pracy i branch roboczy (przykład)** ```console > /monolynx:work-simple SKL-1 Jesteś na branchu main, który jest branchem bazowym. Proponuję nowy branch z aktualnego main: git checkout main && git pull origin main && git checkout -b feature-1-rabat-procentowy ``` Po utworzeniu brancha komenda pokazuje plan i kontrakt autonomii, a ticket dostaje status W trakcie. Dalej praca idzie bez Twojego udziału. **Kroki** 1. **Plan** Koordynator zapisuje plan jako komentarz na tickecie. 2. **Implementacja** Programista zmienia `sklep/koszyk.py` i dopisuje testy w `tests/test_koszyk.py`. 3. **Lint i testy** Koordynator uruchamia komendy ze strony `toolchain`: `ruff check .` i `pytest`. 4. **Ocena** Krytyk porównuje zmianę z kryteriami akceptacji i wystawia ocenę punktową. Próg zaliczenia to 82 punkty na 100. 5. **Status Review** Po zielonych testach i zaliczonej ocenie ticket przechodzi na status Review. **Koniec pracy agenta (przykład)** ```console ruff check . OK pytest 4 passed Ticket SKL-1: status Review, ocena krytyka 93/100 Do wykonania: git add sklep/koszyk.py tests/test_koszyk.py git commit -m "SKL-1: rabat procentowy w sumie zamówienia" ``` ```python title="sklep/koszyk.py po zmianie" def suma_zamowienia(pozycje, rabat_procent=0): if not 0 <= rabat_procent <= 100: raise ValueError("Rabat musi być w zakresie 0-100") suma = sum(cena * ilosc for cena, ilosc in pozycje) return suma * (100 - rabat_procent) / 100 ``` > [!IMPORTANT] > Agent kończy na statusie Review i nie robi commita. W tym przebiegu nie ustawiliśmy flag `MONOLYNX_AUTOCOMMIT` ani `MONOLYNX_AUTOPUSH`, więc komenda wypisuje gotowe polecenia i oddaje je Tobie. ## Etap 5: commit, push i merge request Commit, push i merge request wyglądają tak samo jak przy zmianie napisanej ręcznie. **Twoje polecenia po pracy agenta** ```console $ git add sklep/koszyk.py tests/test_koszyk.py $ git commit -m "SKL-1: rabat procentowy w sumie zamówienia" $ git push -u origin feature-1-rabat-procentowy $ glab mr create --fill --target-branch main ``` Merge request czytasz jak zmianę kolegi. Plan, raport programisty i ocena krytyka są w komentarzach ticketu SKL-1, więc wiesz, co i dlaczego zostało zrobione. ## Etap 6: merge i zamknięcie Po zielonym CI i zatwierdzeniu mergujesz zmianę. Zostają dwie czynności. **Kroki** 1. **Status Gotowe** Zmień status SKL-1 na liście backlogu, w polu statusu przy tickecie, albo poproś o to agenta. Tablica pokazuje tylko aktywny sprint, więc ticketu bez sprintu na niej nie ma. Agent nie ustawia tego statusu sam, bo "gotowe" znaczy "zmergowane". 2. **Powrót na gałąź główną** Wykonaj `git checkout main` i `git pull`, żeby następny ticket startował z aktualnego kodu. > [!NOTE] > W projekcie z włączoną metodą LLM Wiki dochodzi trzecia czynność: `/monolynx:wiki-sync-merge SKL-1` przenosi wiedzę z ticketu do wiki. W tym przebiegu punkt 3 z `setup` miał stan BRAK, więc ją pomijamy. ## Co zostało po całym przebiegu? Zmiana w kodzie to tylko część wyniku. Reszta jest na platformie i przyda się przy następnym tickecie. **Porównanie** | Miejsce | Co tam jest | | --- | --- | | Repozytorium | commit ze zmianą na gałęzi głównej, plik `.claude/settings.json` | | Ticket SKL-1 | plan, raport programisty, ocena krytyka, zalogowany czas, status Gotowe | | Wiki projektu | strona `Toolchain`, z której skorzysta każdy następny ticket | | Moduł Pipelines | przebieg pracy nad SKL-1 z logami agentów | ### Co mogło pójść inaczej? Przebieg powyżej jest prosty, bo nic go nie przerwało. Poniżej najczęstsze odchylenia i to, co wtedy się dzieje. **Porównanie** | Sytuacja | Co się dzieje | | --- | --- | | Brak strony `toolchain` | komenda pyta przed lintem i testami, czy kontynuować bez nich, i odsyła do `/monolynx:project-toolchain`; sesja w tle kończy turę | | Czerwone testy | programista poprawia kod i testy idą ponownie, w ramach limitu poprawek | | Ocena krytyka poniżej progu | programista dostaje uwagi i poprawia, w ramach tego samego limitu poprawek | | Ticket okazuje się większy | `work-simple` przekazuje go do komendy `work` z zespołem agentów | | Sesja przerwana w połowie | `/monolynx:resume SKL-1` odtwarza stan z komentarzy ticketu | Objawy i naprawy zbiera wpis [Gdy coś nie działa](https://monolynx.com/blog/gdy-cos-nie-dziala-w-monolynx). ## Najczęstsze pytania **FAQ** ### Czy ten sam przebieg zadziała w istniejącym, dużym repozytorium? Tak. Etap 1 skraca się wtedy do instalacji pluginu i pliku `.claude/settings.json`. Reszta jest taka sama, a strona `toolchain` zwykle ma dłuższe komendy. ### Czy agent może zrobić także etap 5? Tak, po Twojej zgodzie. Flagi `MONOLYNX_AUTOCOMMIT`, `MONOLYNX_AUTOPUSH` i `MONOLYNX_AUTOMR` pozwalają mu kolejno na commit, push i otwarcie merge requesta. Zatwierdzenie i merge zostają u Ciebie. ### Ile trwa taki przebieg? To zależy od projektu i ticketu, więc wpis nie podaje czasów. Etapy 1 i 2 wykonujesz raz na projekt. Kolejne tickety zaczynają się od etapu 3. ### Czy muszę mieć sprint, żeby przejść ten przebieg? Nie. Komendy `work` i `work-simple` przyjmują klucz ticketu wprost. Sprint przydaje się dopiero wtedy, gdy ticketów jest kilka i mają iść równolegle. ### Co dalej po pierwszym tickecie? Następny ticket przejdź w ten sam sposób. Gdy ticketów zbierze się kilka, zaplanuj sprint i oddaj pracę pętlom. ## Słownik i następny krok **Słownik** - **Slug projektu** - krótka nazwa projektu w adresach i w komendach, tutaj `sklep` - **Klucz ticketu** - prefiks projektu i numer, tutaj SKL-1 - **Toolchain** - strona wiki z komendami lintu i testów projektu - **Koordynator** - sesja, która prowadzi agentów nad jednym ticketem - **Krytyk** - osobny agent oceniający zmianę według kryteriów akceptacji - **Kontrakt autonomii** - spis tego, co agent robi sam, i tego, przed czym się zatrzymuje Każdy krok pracy ręcznej z wariantami opisuje wpis [Pierwszy ticket ręcznie](https://monolynx.com/blog/pierwszy-ticket-recznie-monolynx). Znaczenie statusów wyjaśnia wpis [Statusy ticketu w Monolynx](https://monolynx.com/blog/statusy-ticketu-w-monolynx). Pracę wielu ticketów naraz prowadzi [Sprint z Monolynx krok po kroku](https://monolynx.com/blog/sprint-z-monolynx-krok-po-kroku). **Wezwanie do działania** Chcesz zobaczyć tablicę, na której SKL-1 przeszedł od Backlog do Gotowe? [Zobacz moduł Scrum w Monolynx](https://monolynx.com/features/scrum)