Jak działa /monolynx:work: od ticketu do merge requesta

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

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

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

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.

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-<numer>-<opis> 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.

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]

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.

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.

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.

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.

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

python3 scripts/test_lock.py --timeout 3600 -- <komenda testów>

$ python3 scripts/test_lock.py -- <komenda testów>
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.

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

Flagi ustawiasz w pliku ustawień projektu albo w środowisku procesu:

{
  "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.

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.

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:

SPRINT-RUN STOP: czeka na merge MON-122

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.

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.

Słownik i pierwszy krok

Pojęcia z tego wpisu, w jednym miejscu:

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:

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

Całą drogę jednego ticketu bez sprintu i bez flag pokazuje wpis Pierwszy ticket ręcznie: od brancha do merge. Statusy, które komenda ustawia po drodze, opisuje wpis Statusy ticketu w Monolynx.