--- title: "Pierwszy ticket ręcznie: od brancha do merge" description: "Jak przeprowadzić jeden ticket z pluginem Monolynx bez sprintu i bez flag autonomii: ticket, recenzja, branch, praca agenta, commit, merge request, merge i wiki." url: "https://monolynx.com/blog/pierwszy-ticket-recznie-monolynx" lang: "pl" author: "Zespół Monolynx" published: "2026-10-09T07:15:22.136379+00:00" modified: "2026-10-09T18:11:25.782537+00:00" last_verified: "2026-10-09" tags: ["monolynx", "plugin", "ticket", "poradnik"] translations: [] reading_time_minutes: 8 word_count: 1575 --- > [!TLDR] > - Jeden ticket da się przeprowadzić ręcznie w sześciu krokach: ticket, recenzja, branch, praca agenta, commit z merge requestem i merge. > - Nie potrzebujesz sprintu, pętli ani flag autonomii. Agent pisze kod, a commit, push i merge zostają u Ciebie. > - Branch roboczy proponuje komenda `work`: nazwę `feature--` i gotowe polecenie. > - Agent kończy na statusie Review. Status Gotowe ustawiasz po merge. > - Po merge jedna komenda przenosi wiedzę z ticketu do wiki. ## Kiedy pracować ręcznie, bez sprintu? Praca ręczna to jeden ticket w jednej sesji, w której siedzisz i odpowiadasz na pytania. To najlepszy pierwszy kontakt z pluginem: widzisz każdy krok, niczego nie musisz konfigurować poza projektem i w każdej chwili możesz przerwać. **Porównanie** | Cecha | Praca ręczna | Sprint z pętlami | | --- | --- | --- | | Ile ticketów | jeden naraz | wiele równolegle | | Kto odpowiada agentowi | Ty, na bieżąco | Ty, gdy sesja czeka | | Flagi autonomii | niepotrzebne | wymagane | | Commit i push | Ty, z gotowych poleceń | agent | | Kiedy wybrać | pierwszy ticket, hotfix, zadanie z decyzjami | wiele dobrze opisanych ticketów | **Statystyki** - **6** - kroków od pomysłu do merge - **0** - flag autonomii potrzebnych do startu - **3** - punkty story points, do których wystarcza `work-simple` - **82** - próg oceny krytyka, od którego ticket trafia do review > [!NOTE] > Zakładam, że projekt jest już skonfigurowany: agent jest połączony z platformą, repozytorium zna slug projektu, a strona wiki `toolchain` ma komendy lintu i testów. Jeśli nie, zacznij od wpisu [Pierwszy projekt w Monolynx](https://monolynx.com/blog/pierwszy-projekt-w-monolynx). Konfigurację i ten obieg na jednym przykładzie łączy wpis [Od pustego repozytorium do zmergowanego ticketu](https://monolynx.com/blog/od-repozytorium-do-zmergowanego-ticketu). ## Jak wygląda cały obieg? **Jeden ticket ręcznie: od pomysłu do wiki** Najpierw powstaje ticket, potem jego recenzja. Komenda work sprawdza branch, a agenci piszą kod i testy. Krytyk ocenia wynik i ticket trafia do review. Ty wykonujesz commit, push i otwierasz merge request. Po zatwierdzeniu i merge ustawiasz status Gotowe, a komenda wiki-sync-merge przenosi wiedzę do wiki. ```mermaid flowchart TD A["ticket-create"] --> B["ticket-review"] B --> C["work: branch i plan"] C --> D["Agenci: kod i testy"] D --> E["Krytyk: ocena"] E --> F["Ticket w review"] F --> G["Ty: commit, push, merge request"] G --> H["Ty: merge i status Gotowe"] H --> I["wiki-sync-merge"] ``` **Kroki** 1. **Załóż ticket** Komenda `/monolynx:ticket-create` zbiera kontekst i pokazuje gotowy opis do akceptacji. 2. **Zrecenzuj ticket** Komenda `/monolynx:ticket-review` sprawdza, czy opis zgadza się z kodem i wiki. 3. **Uruchom pracę** Komenda `/monolynx:work` albo `/monolynx:work-simple` sprawdza branch i prowadzi agentów. 4. **Wykonaj testy, commit i push** Bez flag agent wypisuje polecenia, a Ty je uruchamiasz. 5. **Zmerguj** Otwierasz merge request, czekasz na CI i mergujesz. 6. **Zamknij ticket i zapisz wiedzę** Ustawiasz status Gotowe i uruchamiasz `/monolynx:wiki-sync-merge`. ## Krok 1 i 2: ticket i recenzja Ticket jest kontraktem dla agenta. Im dokładniej mówi, co zmienić i czego nie ruszać, tym mniej pytań w trakcie pracy. **Ticket i jego recenzja** ```console > /monolynx:ticket-create Dodaj eksport zamówień do CSV Ticket SKL-12 utworzony (3 SP, status: Backlog) > /monolynx:ticket-review SKL-12 Forma: OK | Zgodność z wiki: OK | Zgodność z kodem: 1 uwaga ``` Nowy ticket dostaje status Backlog. W pracy ręcznej nie musisz go przestawiać na Do zrobienia ani przypisywać do sprintu: komenda `work` przyjmuje klucz ticketu wprost. Szczegóły obu komend opisują wpisy [Jak działa /monolynx:ticket-create](https://monolynx.com/blog/jak-dziala-monolynx-ticket-create) i [Jak działa /monolynx:ticket-review](https://monolynx.com/blog/jak-dziala-monolynx-ticket-review). ## Krok 3: branch i praca agenta ### Którą komendę wybrać? **Porównanie** | Cecha | `work-simple` | `work` | | --- | --- | --- | | Wielkość ticketu | do 3 story points | powyżej 3 story points | | Zespół | jeden programista i krytyk | kilku agentów i krytyk | | Rozpoznanie kodu | na życzenie | zawsze | | Gdy ticket okazuje się większy | przekazuje go do `work` | nie dotyczy | ### Kto tworzy branch? Ty, ale komenda Cię prowadzi. Agent nie pracuje bezpośrednio na branchu bazowym, czyli na tym, z którego startują inni. Gdy stoisz na branchu bazowym albo nazwa Twojego brancha nie zawiera numeru ticketu, komenda proponuje nowy branch i podaje polecenie. **Branch roboczy proponowany przez komendę work** ```console > /monolynx:work-simple SKL-12 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-12-eksport-csv ``` **Jak komenda sprawdza nazwę brancha** Domyślnie nazwa brancha musi zawierać numer ticketu jako osobną część: `feature-12-eksport` pasuje do ticketu SKL-12, a `feature-112-eksport` nie. Zachowanie zmienia zmienna `MONOLYNX_BRANCH_MODE`. Wartość `sprint` dopuszcza dowolny branch poza bazowym, co przydaje się przy pracy nad kilkoma ticketami na jednym branchu. Wartość `off` wyłącza kontrolę nazwy. Zakaz pracy wprost na branchu bazowym obowiązuje zawsze. ### Co robi agent? Po ustaleniu brancha sesja staje się koordynatorem. Czyta ticket, pokazuje plan i listę decyzji, przed którymi się zatrzyma, a potem zleca pracę agentom. Ticket przechodzi wtedy na status W trakcie. > [!TIP] > Na początku komenda pokazuje kontrakt autonomii: co agent zrobi sam, a przed czym zapyta. Przeczytaj go. To najtańszy moment na zmianę zakresu. ## Krok 4: testy, commit i push Bez flag autonomii agent niczego nie uruchamia i niczego nie zapisuje w gicie. Wypisuje polecenia i czeka. **Porównanie** | Moment | Co robi agent | Co robisz Ty | | --- | --- | --- | | Lint i testy | wypisuje polecenia ze strony `toolchain` | uruchamiasz je i wklejasz wynik | | Czerwone testy | poprawia kod | uruchamiasz ponownie | | Ocena krytyka | poprawia uwagi poniżej progu | czytasz ocenę | | Commit | wypisuje gotowe polecenie z opisem | uruchamiasz je | | Push i merge request | nic | robisz to sam | > [!TIP] > Wklejanie wyników testów szybko męczy. Jedna flaga, `MONOLYNX_AUTOTEST` ustawiona na `true`, pozwala agentowi uruchamiać lint i testy samodzielnie. Commit i push nadal zostają u Ciebie. ```json title=".claude/settings.json: praca ręczna z automatycznymi testami" { "env": { "MONOLYNX_PROJECT_SLUG": "sklep", "MONOLYNX_AUTOTEST": "true" } } ``` Gdy lint i testy są zielone, a krytyk wystawi co najmniej 82 punkty na 100, ticket dostaje status Review. Na tickecie zostają komentarze: plan, raporty agentów i ocena. **Koniec pracy agenta i Twoje polecenia** ```console Ticket SKL-12: status Review, ocena krytyka 91/100 Do wykonania: git add src/eksport.py tests/test_eksport.py git commit -m "SKL-12: eksport zamówień do CSV" $ git push -u origin feature-12-eksport-csv ``` ## Krok 5 i 6: merge, status i wiki Merge request otwierasz tak jak zawsze: w interfejsie GitLaba albo GitHuba, albo poleceniem `glab mr create` lub `gh pr create`. Czekasz na zielone CI, ktoś zatwierdza zmianę i mergujesz. Po merge zostają dwie czynności. **Kroki** 1. **Ustaw status Gotowe** Zmień status na liście backlogu albo poproś agenta. Tablica pokazuje tylko aktywny sprint, więc kartę przeciągniesz na niej dopiero w sprincie. Agent nie robi tego sam, bo "gotowe" znaczy "zmergowane". 2. **Przenieś wiedzę do wiki** Przełącz się na branch główny, pobierz zmiany i uruchom `/monolynx:wiki-sync-merge SKL-12`. > [!NOTE] > Komenda `wiki-sync-merge` działa tylko w projekcie z włączoną metodą LLM Wiki i tylko z brancha, do którego trafiła zmiana. W projekcie bez tej metody pomiń ją. > [!WARNING] > Nie zostawiaj ticketu w statusie Review po merge. Ticket zależny od niego nie ruszy, bo blokadę zdejmuje dopiero status Gotowe. ## Co zrobić, gdy coś przerwie pracę? **Porównanie** | Sytuacja | Co zrobić | | --- | --- | | Zamknąłeś sesję w połowie | `/monolynx:resume SKL-12` odtwarza stan z ticketu, komentarzy i gita | | Nie wiesz, co dalej | `/monolynx:next` czyta stan i poleca następną komendę | | Mały ticket urósł | `work-simple` sam przekazuje go do `work` | | Chcesz zmienić zakres | powiedz to koordynatorowi przed akceptacją planu | | Agent pyta o decyzję | odpowiedz w tej samej sesji; praca rusza dalej | ## Najczęstsze pytania **FAQ** ### Czy muszę mieć aktywny sprint, żeby uruchomić work? Nie. Komenda przyjmuje klucz ticketu i nie wymaga, żeby ticket należał do sprintu. ### Czy agent może sam zrobić commit i push? Tak, po Twojej zgodzie wyrażonej flagami `MONOLYNX_AUTOCOMMIT` i `MONOLYNX_AUTOPUSH`. Domyślnie obie są wyłączone. ### Co się stanie, gdy krytyk oceni pracę poniżej progu? Uwagi wracają do agenta, który je poprawia. Liczba rund poprawek jest ograniczona. Po jej wyczerpaniu koordynator pokazuje Ci stan i pyta, co dalej. ### Czy mogę pracować na branchu, który już mam? Tak, jeśli nie jest branchem bazowym. Gdy jego nazwa nie zawiera numeru ticketu, komenda zapyta, czy mimo to kontynuować. ### Kiedy przejść z pracy ręcznej na sprint? Gdy masz kilka dobrze opisanych ticketów, które nie wymagają Twoich decyzji w trakcie. Wtedy pętle robią to, co tutaj robisz ręcznie. ## Słownik i następny krok **Słownik** - **Branch bazowy** - branch, z którego powstają branche robocze, zwykle główny branch repozytorium - **Branch roboczy** - branch jednego ticketu, na którym agent zapisuje zmiany - **Koordynator** - sesja prowadząca ticket: planuje, zleca pracę agentom i pilnuje jakości - **Krytyk** - agent oceniający wynik pracy w skali do 100 punktów - **Kontrakt autonomii** - lista decyzji, przed którymi agent zatrzyma się i zapyta - **Flagi autonomii** - zmienne, którymi dajesz agentowi zgodę na testy, commit, push i merge request Co znaczy każdy status i kto go zmienia, opisuje wpis [Statusy ticketu w Monolynx](https://monolynx.com/blog/statusy-ticketu-w-monolynx). Zatwierdzanie i merge, także z kolejką, opisuje wpis [Zatwierdzanie i merge: co zawsze robi człowiek](https://monolynx.com/blog/zatwierdzanie-i-merge-w-monolynx). Pełny opis komendy znajdziesz we wpisie [Jak działa /monolynx:work](https://monolynx.com/blog/jak-dziala-monolynx-work). **Wezwanie do działania** Chcesz zobaczyć, gdzie trafia ticket i jego komentarze po pracy agenta? [Zobacz moduł Scrum w Monolynx](https://monolynx.com/features/scrum)