--- title: "Jak działa /monolynx:work: od ticketu do merge requesta" description: "Co dzieje się po wpisaniu /monolynx:work MON-123: Researcher, zespół agentów, lint i testy, krytyk z rubryką punktową i progiem 82, a na końcu ticket w in_review." url: "https://monolynx.com/blog/jak-dziala-monolynx-work" lang: "pl" author: "Zespół Monolynx" published: "2026-10-07T18:52:41.108835+00:00" modified: "2026-10-09T10:35:15.387558+00:00" last_verified: "2026-10-07" tags: ["plugin", "claude-code", "agenci-ai", "scrum", "workflow"] translations: [] reading_time_minutes: 12 word_count: 2236 --- > [!TLDR] > - Jedna komenda prowadzi ticket od `todo` do `in_review`: research, plan, kod, lint i testy, review. > - Koordynator nie pisze kodu sam. Dobiera zespół agentów i przydziela każdemu konkretne pliki. > - Osobny krytyk ocenia pracę rubryką punktową. Wynik poniżej 82/100 wraca do poprawki, najwyżej 3 razy. > - Domyślnie nic nie jest commitowane ani pushowane. O tym decydują flagi, które włączasz sam. ## Co robi jedna komenda? Skill `work` z pluginu Monolynx dla Claude Code bierze jeden ticket ze sprintu i prowadzi go do stanu, w którym człowiek może zrobić review. Argumentem jest identyfikator albo klucz ticketu. Bez argumentu skill pokazuje tickety z kolumn `todo` i `in_progress` i pyta, który podjąć. **Start pracy nad ticketem** ```console $ claude > /monolynx:work MON-123 ``` Sesja, w której wpisujesz komendę, staje się koordynatorem. Koordynator czyta ticket, sprawdza branch, zleca analizę, dobiera zespół, pilnuje lintu i testów, a na końcu oddaje pracę krytykowi. Sam nie implementuje. **Statystyki** - **82/100** - próg, od którego krytyk zalicza pracę agenta - **3** - limit poprawek na jednego agenta - **7** - agentów ról dostarczanych z pluginem - **3** - etapy przebiegu widoczne w module Pipelines Obieg pracy w jednym zdaniu: ticket trafia do agenta, agent otwiera zmianę, a wynik trafia do wiki. Stan końcowy to ticket w statusie `in_review`, z komentarzami każdego agenta, zalogowanym czasem pracy i, zależnie od flag, z commitem, pushem i merge requestem. Status `done` nie należy do tego skilla[^done]. ## Siedem kroków od ticketu do in_review Przebieg ma stałą kolejność i każdy krok zostawia ślad na tickecie. Dzięki temu pracę da się wznowić po przerwaniu sesji: skill znajduje komentarz z planem i pyta, czy kontynuować, czy zacząć od zera. **Kroki** 1. **Ticket i narzędzia** Skill ustala projekt, wybiera kanał rozmowy z platformą (CLI albo MCP) i pobiera ticket. Niezamknięty bloker zatrzymuje pracę już tutaj. 2. **Branch** Skill ustala branch bazowy i odmawia pracy bezpośrednio na nim. Gdy nazwa bieżącego brancha nie zawiera numeru ticketu, proponuje utworzenie brancha `feature--` z aktualnego brancha bazowego i podaje gotową komendę. Branch, który jest za bazą i nie ma własnych commitów, przewija sam przez fast-forward. 3. **Researcher** Osobny agent czyta kod, wiki i graf zależności, a potem pisze raport. Jego czas trafia na ticket. 4. **Start** Ticket przechodzi do `in_progress` i zostaje przypisany do Ciebie. 5. **Plan** Koordynator dobiera agentów, rozdziela pliki, spisuje kontrakt autonomii i zapisuje plan w komentarzu. 6. **Zespół, testy, krytyk** Agenci piszą kod, potem idą lint i testy, a na końcu krytyk wystawia ocenę. 7. **Zamknięcie** Komentarze, czas pracy, commit i merge request według flag, status `in_review`. **Przebieg skilla work** Ticket przechodzi przez walidację brancha, analizę Researchera i plan koordynatora. Potem zespół agentów pisze kod, a lint i testy sprawdzają wynik. Krytyk wystawia ocenę: wynik poniżej 82 punktów wraca do zespołu, wynik od 82 w górę kończy się statusem in_review. ```mermaid flowchart TD A[Ticket] --> B[Walidacja brancha] B --> C[Researcher] C --> D[Plan i przydział plików] D --> E[Zespół agentów] E --> F[Lint i testy] F -->|czerwone| E F -->|zielone| G[Krytyk] G -->|poniżej 82| E G -->|82 lub więcej| H[Komentarze i czas pracy] H --> I[Commit i MR według flag] I --> J[in_review] ``` > [!NOTE] > Lint i testy stoją przed krytykiem celowo. Krytyk ocenia kod, który się kompiluje i przechodzi testy, więc tani test odsiewa błędy przed drogim review. ## Kto pracuje nad ticketem? Zespół składa się z czterech ról, a każda ma jawnie podany model. Subagent bez wskazanego modelu dziedziczy model sesji, która go powołała, więc bez tej reguły cały ticket szedłby na najdroższym modelu. **Porównanie** | Rola | Model | Co robi | Czego nie robi | | --- | --- | --- | --- | | Koordynator | model sesji | planuje, rozdziela pliki, decyduje | nie implementuje | | Researcher | sonnet | czyta kod, wiki i graf, pisze raport | niczego nie zmienia | | Developer | z definicji agenta, domyślnie sonnet | pisze kod i testy w swoich plikach | nie robi commitów, nie wychodzi poza przydział | | Krytyk | opus | ocenia według rubryki | nie pisze kodu, nie odpala testów | Agentów koordynator szuka najpierw w projekcie, w katalogu `.claude/agents/`. Agenci z pluginu są zapasem: backend-developer, frontend-developer, database-specialist, devops-infra, qa-tester, code-reviewer i technical-writer. Skill wybiera najmniejszy zestaw, który pokrywa ticket, a przydział plików jest imienny, bez wzorców z gwiazdką. Dwie reguły porządkują pracę równoległą. Agent testowy przy podejściu TDD startuje pierwszy i sam. Agenci, którzy dotykają tych samych plików, pracują po kolei. > Krytyk to zawsze osobne powołanie, nigdy ten sam agent, który pisał oceniany kod. > -- skill work, zasady zespołu ## Jak krytyk ocenia pracę? Krytyk zaczyna od 100 punktów i odejmuje je za naruszenia z zamkniętej listy. Każde odjęcie musi wskazać plik i linię albo źródło, więc ocena nie jest wrażeniem. Próg wynosi 82: wynik 85 zalicza, wynik 80 nie. **Ile punktów kosztuje naruszenie** | Naruszenie | Odjęcie | | --- | --- | | Zapis do bazy bez commita | 30 | | Złamana reguła projektu | 25 | | Brak testu dla nowego kodu | 20 | | Test nie zabija mutanta | 20 | | Niespełnione kryterium akceptacji | 15 | | Zmiana pliku poza przydziałem | 10 | | Over-engineering | 10 | | Komentarz opisujący, co robi kod | 5 | Werdykt ma dwie wartości: `APPROVED` albo `NEEDS WORK`. Przy `NEEDS WORK` krytyk dopisuje jedno zdanie reguły, a koordynator zapisuje je w pamięci danej roli. Reguła, która wraca drugi raz, trafia na listę do retrospektywy sprintu. **Pełna rubryka krytyka** | Naruszenie | Odjęcie | | --- | --- | | Zapis do bazy bez `db.commit()` | -30 | | Naruszenie reguły z `.claude/rules/` | -25 za regułę | | Brak testu dla nowego kodu (gdy projekt ma testy) | -20 | | Test przechodzi na mutancie chronionego kodu | -20 | | Kryterium akceptacji niezrealizowane | -15 za kryterium | | Brak obsługi błędu na granicy systemu | -10 | | Zmiana pliku poza przydziałem | -10 za plik | | Naruszenie warunków zatrzymania z kontraktu | -10 | | Over-engineering | -10 | | Niezgodność z konwencją sąsiedniego pliku | -5 | | Komentarz opisujący, co robi kod | -5 | W trybie naprawy defektu dochodzą trzy wiersze: fix bez nazwanego mechanizmu błędu (-20), brak testu regresyjnego (-20) i niesprawdzona klasa błędu (-5). Jedna wada jest liczona raz, według najwyższego odjęcia, a ocena całego ticketu to najniższa z ocen agentów. > [!WARNING] > Limit wynosi 3 poprawki na agenta i jest wspólny dla czerwonego lintu, czerwonych testów i oceny poniżej progu. Czwartej poprawki skill nie zleca sam, tylko pyta Ciebie, co dalej. ## Lint i testy przed review Komendy lintu i testów pochodzą ze strony wiki `toolchain`, którą konfigurujesz raz na projekt skillem `/monolynx:project-toolchain`. Skill niczego nie zgaduje po plikach w repozytorium. Gdy strony nie ma, pyta, czy kontynuować bez lintu i testów. Praca w git worktree ma własny wariant komend. Polecenie `docker compose exec` wchodzi do kontenera, który widzi główny checkout, więc testowałoby inne drzewo plików niż to, w którym agent pisał kod. Testy z kilku worktree naraz potrafią sobie przeszkadzać, dlatego każda komenda testów idzie przez kolejkę: ```bash title="Testy przez wspólną blokadę" python3 scripts/test_lock.py --timeout 3600 -- ``` **Kolejka testów między worktree** ```console $ python3 scripts/test_lock.py -- TEST-LOCK: waiting holder=48213/MON-270 TEST-LOCK: acquired ``` Blokada jest jedna na repozytorium, wspólna dla głównego checkoutu i wszystkich worktree. Upłynięcie czasu oczekiwania kończy się kodem 75 i nie liczy się jako czerwone testy, więc nie zużywa limitu poprawek. > [!TIP] > Projekt z długim zestawem testów może ustawić na stronie `toolchain` pole `pełny przebieg: ci`. Lokalnie idzie wtedy cały lint i testy zawężone do zmienionych plików, a pełny zestaw sprawdza pipeline merge requesta. ## Commit, push i MR są wyłączone, dopóki ich nie włączysz Skill domyślnie nie commituje, nie pushuje i nie zakłada merge requesta. Zamiast tego wypisuje gotowe komendy, a Ty uruchamiasz je sam. Każdy poziom automatyzacji ma osobną flagę. **Porównanie** | Flaga | Wartość false (domyślna) | Wartość true | | --- | --- | --- | | `MONOLYNX_AUTOTEST` | skill wypisuje komendy i czeka na wklejony wynik | skill sam uruchamia lint i testy | | `MONOLYNX_AUTOCOMMIT` | skill wypisuje komendę commita | commit po zielonych testach i ocenie od 82 | | `MONOLYNX_AUTOPUSH` | skill nigdy nie pushuje | push po faktycznym commicie | | `MONOLYNX_AUTOMR` | merge request nie powstaje | merge request po faktycznym pushu | Flagi ustawiasz w pliku ustawień projektu albo w środowisku procesu: ```json title=".claude/settings.json" { "env": { "MONOLYNX_AUTOTEST": "true", "MONOLYNX_AUTOCOMMIT": "true", "MONOLYNX_AUTOPUSH": "true", "MONOLYNX_AUTOMR": "true" } } ``` Bez dodatkowych ustawień merge request idzie do domyślnego brancha repozytorium. W sprincie cel wskazuje zmienna `MONOLYNX_MR_TARGET` ustawiona na branch sprintu w środowisku dyspozytora, a nie w tym pliku. Zasady opisuje wpis [Konfiguracja: która zmienna w którym pliku](https://monolynx.com/blog/konfiguracja-monolynx-zmienne). Automatyczny commit ma dodatkowy bezpiecznik. Gdy każesz zamknąć ticket mimo czerwonych testów albo oceny poniżej progu, skill zapisuje to w komentarzu i zamiast commita podaje komendę. ## Co zostaje na tickecie po pracy? Każdy etap zostawia komentarz, więc historię ticketu da się przeczytać bez otwierania sesji. Koordynator pisze plan przed pracą i podsumowanie po niej, a w imieniu każdego agenta dodaje komentarz z wynikiem i loguje jego czas. **Pola komentarza z planem pracy** - Tryb (zwykły albo naprawa defektu) - Streszczenie raportu Researchera - Dobrani agenci i ich pliki - Kontrakt autonomii: co agent robi sam, przed czym się zatrzymuje - Baseline, czyli commit, od którego liczony jest diff - Tryb pełnego przebiegu testów - Zależności, które nie są jeszcze zmergowane - Identyfikator pipeline'u - Plan realizacji Równolegle przebieg trafia do modułu Pipelines jako pipeline typu `ticket_work` z trzema etapami: `research`, `coding` i `wrap-up`. Każdy agent ma tam swój job z logiem i oceną krytyka. Raportowanie do Pipelines nie jest bramką: błąd zapisu nigdy nie przerywa pracy nad ticketem. ## Sesja w tle Zmienna `MONOLYNX_SPRINT_RUN=1` mówi skillowi, że nikt nie odpowie na pytanie. Tak startuje sesje dyspozytor `/monolynx:sprint-run`, który przerabia sprint wieloma sesjami w osobnych worktree. W tym trybie kontrakt autonomii jest przyjmowany automatycznie, a każde miejsce, w którym skill zwykle czeka na człowieka, kończy turę. Na tickecie zostaje komentarz z powodem, etapem i warunkiem odblokowania, a ostatnia linia sesji ma stały format: **Zatrzymanie sesji w tle** ```console SPRINT-RUN STOP: czeka na merge MON-122 ``` > [!IMPORTANT] > Sesja w tle nie zgaduje odpowiedzi za człowieka i nie wybiera za niego wariantu domyślnego. Zatrzymany ticket nie przechodzi do `in_review`. ## work czy work-simple? Plugin ma dwa skille do pracy nad ticketem. Różnią się wielkością zespołu, a nie rygorem: komentarze, czas pracy, lint, testy i krytyk są w obu. **Porównanie** | Cecha | work | work-simple | | --- | --- | --- | | Rozmiar ticketu | powyżej 3 story points | do 3 story points | | Zespół | Researcher, kilku agentów, krytyk | jeden developer i krytyk | | Research | obowiązkowy | na życzenie | | Praca równoległa | tak | nie | Skill `work-simple` sam proponuje przejście na `work`, gdy zakres ticketu rozrasta się w trakcie pracy. ## Najczęstsze pytania Pytania poniżej wracają najczęściej u osób, które uruchamiają skill pierwszy raz. **FAQ** ### Czy skill sam zmerguje mój kod? Nie. Skill kończy na statusie `in_review` i, przy włączonej fladze, na otwartym merge requeście. Merge to osobny krok: robi go człowiek albo kolejka `/monolynx:mr-queue`. ### Co się stanie, gdy przerwę sesję w połowie? Stan zostaje na tickecie. Przy następnym uruchomieniu skill znajduje komentarz z planem pracy i pyta, czy wznowić, czy zacząć od zera. Wznowienie pomija analizę Researchera. ### Czy muszę mieć agentów zdefiniowanych w projekcie? Nie. Agenci z katalogu `.claude/agents/` mają pierwszeństwo, a gdy ich nie ma, skill używa siedmiu agentów dostarczanych z pluginem. ### Czy krytyk może poprawić kod, który ocenia? Nie. Krytyk tylko ocenia. Poprawkę robi developer, który dostaje pełny pierwotny prompt, uwagi z plikiem i linią oraz dosłowny diff. ### Co, jeśli projekt nie ma testów? Skill pyta, czy kontynuować bez lintu i testów. Wiersz rubryki o braku testu dla nowego kodu obowiązuje tylko w projekcie, który testy ma. ## Słownik i pierwszy krok Pojęcia z tego wpisu, w jednym miejscu: **Słownik** - **Koordynator** - sesja, która prowadzi zespół agentów nad jednym ticketem; w treści skilla nazywa się Team Manager - **Researcher** - agent tylko do odczytu, który przed pracą analizuje kod, wiki i graf zależności - **Krytyk** - osobny agent oceniający pracę według rubryki punktowej - **Kontrakt autonomii** - spis tego, co agent robi sam, i tego, przed czym się zatrzymuje - **Strona toolchain** - strona wiki projektu z komendami lintu i testów - **Worktree** - osobny katalog roboczy tego samego repozytorium git, jeden na ticket Plugin instalujesz w Claude Code dwiema komendami: ```text title="Instalacja pluginu" /plugin marketplace add https://gitlab.com/piotrkrych/monolynx.git /plugin install monolynx@monolynx ``` Połączenie z platformą, także poza Claude Code, opisuje wpis [Jak połączyć agenta AI z Monolynx](https://monolynx.com/blog/polaczenie-z-monolynx-mcp-claude-code-chatgpt). Całą drogę jednego ticketu bez sprintu i bez flag pokazuje wpis [Pierwszy ticket ręcznie: od brancha do merge](https://monolynx.com/blog/pierwszy-ticket-recznie-monolynx). Statusy, które komenda ustawia po drodze, opisuje wpis [Statusy ticketu w Monolynx](https://monolynx.com/blog/statusy-ticketu-w-monolynx). **Wezwanie do działania** Skill bierze tickety ze sprintu w module Scrum. Zobacz, jak wygląda tablica, z której agent pobiera pracę. [Poznaj moduł Scrum w Monolynx](https://monolynx.com/features/scrum) [^done]: Status `done` ustawia kolejka `/monolynx:mr-queue` po zmergowaniu merge requesta. Po merge do brancha sprintu robi to od razu, na podstawie zielonego CI samego merge requesta. Po merge do domyślnego brancha repozytorium czeka jeszcze na zielone CI tego brancha. Bez kolejki status ustawia osoba, która merguje.