--- title: "Jak działa /monolynx:ticket-review: recenzja ticketu, zanim agent zacznie pracę" description: "Jak skill /monolynx:ticket-review sprawdza ticket przed pracą agenta: osiem kryteriów formy, zgodność z wiki i kodem, potrójna weryfikacja i blokery w sprincie." url: "https://monolynx.com/blog/jak-dziala-monolynx-ticket-review" lang: "pl" author: "Zespół Monolynx" published: "2026-10-07T19:44:42.009171+00:00" modified: "2026-10-07T19:44:41.982291+00:00" last_verified: "2026-10-07" tags: ["plugin", "claude-code", "agenci-ai", "scrum", "tickety"] translations: [] reading_time_minutes: 9 word_count: 1635 --- > [!TLDR] > - Skill sprawdza ticket pod trzema kątami: forma opisu, zgodność z wiki i zgodność z kodem. > - Status NIEZGODNE wymaga trzech niezależnych sprawdzeń. Jedno nierozstrzygnięte daje status NIEPEWNE. > - Z argumentem `sprint` skill porównuje listy plików ticketów i proponuje blokery, żeby dwa tickety nie zmieniały tego samego pliku równolegle. > - Ticket i relacje blokad zmieniają się tylko po Twojej zgodzie. ## Po co recenzować ticket przed pracą? Błąd w tickecie kosztuje najmniej, zanim ktokolwiek zacznie pisać kod. Agent AI nie zakwestionuje założenia, że "endpoint jest pod adresem X" albo że "moduł Y już to obsługuje". Przyjmie je i zbuduje na nim całą zmianę. Skill `ticket-review` z pluginu Monolynx dla Claude Code sprawdza takie założenia wcześniej. Ma dwa tryby: recenzję jednego ticketu i przegląd całego sprintu. **Dwa tryby skilla** ```console > /monolynx:ticket-review MON-123 > /monolynx:ticket-review sprint ``` Bez argumentu skill pokazuje tablicę Kanban i pyta, który ticket zrecenzować. **Statystyki** - **8** - kryteriów oceny formy ticketu - **3** - sprawdzenia wymagane, zanim założenie dostanie status NIEZGODNE - **2** - tryby: jeden ticket albo cały sprint - **0** - zmian zapisanych bez zgody człowieka ## Osiem kroków recenzji jednego ticketu Recenzja ma stałą kolejność: najpierw forma, potem dwa źródła prawdy, na końcu raport i propozycje. **Kroki** 1. **Ticket i specyfikacja** Skill pobiera ticket. Gdy ticket ma powiązaną stronę specyfikacji w wiki, staje się ona głównym kontekstem. 2. **Forma** Osiem kryteriów, każde z oceną OK, SŁABE albo BRAK. 3. **Wiki** Każde konkretne twierdzenie z ticketu jest wyszukiwane w dokumentacji projektu. 4. **Kod** Osobny agent tylko do odczytu sprawdza te same twierdzenia w kodzie i podaje plik z numerem linii. 5. **Potrójna weryfikacja** Każda wstępna niezgodność jest sprawdzana jeszcze dwa razy, innymi metodami. 6. **Raport** Dwie tabele: forma ticketu i zgodność założeń. 7. **Propozycje poprawek** Osobne pytanie dla niezgodności, elementów niepewnych, braków formy i blokerów. 8. **Komentarz** Podsumowanie recenzji zostaje na tickecie. **Recenzja jednego ticketu** Ticket przechodzi przez ocenę formy, a jego założenia są sprawdzane w wiki i w kodzie. Założenie potwierdzone dostaje status zgodne. Założenie podejrzane o niezgodność przechodzi dwie dodatkowe weryfikacje: gdy wszystkie trzy potwierdzają problem, status to niezgodne, w przeciwnym razie niepewne. Wynik trafia do raportu, a poprawki są zapisywane po zgodzie użytkownika. ```mermaid flowchart TD A[Ticket] --> B[Ocena formy] A --> C[Założenia z ticketu] C --> D[Wiki] C --> E[Kod] D --> F{Niezgodność?} E --> F F -->|nie| G[ZGODNE] F -->|tak| H[Druga i trzecia weryfikacja] H -->|wszystkie trzy potwierdzają| I[NIEZGODNE] H -->|choć jedna nierozstrzygnięta| J[NIEPEWNE] B --> K[Raport] G --> K I --> K J --> K K --> L[Poprawki po zgodzie] ``` ## Jak skill ocenia formę ticketu? Forma odpowiada na jedno pytanie: czy agent zrozumie ticket bez dopytywania. Każde z ośmiu kryteriów dostaje jedną z trzech ocen. **Porównanie** | Ocena | Znaczenie | Co dalej | | --- | --- | --- | | OK | kryterium spełnione | nic | | SŁABE | spełnione częściowo | propozycja poprawionej treści | | BRAK | kryterium niespełnione | propozycja brakującej sekcji | **Osiem kryteriów formy** | Kryterium | Pytanie | | --- | --- | | Jasność celu | Czy wiadomo, co ma być zrobione? | | Kontekst | Czy wiadomo, dlaczego zadanie istnieje? | | Kryteria akceptacji | Czy są w opisie i jako osobna lista do odhaczenia? | | Zakres zmian | Czy wiadomo, gdzie w kodzie wprowadzić zmiany, i czy jest sekcja "Pliki dotykane"? | | Nie ruszać | Czy ticket mówi, czego nie zmieniać, z powodem? | | Odwracalność | Czy wskazano operacje, których nie cofnie revert? | | Zależności | Czy blokery z opisu zgadzają się z relacjami zapisanymi na tickecie? | | Jednoznaczność | Czy opis jest wolny od sprzeczności? | Dwa kryteria sprawdzają więcej niż samą obecność sekcji. Sekcja "Zakres zmian" dostaje ocenę SŁABE także wtedy, gdy lista "Pliki dotykane" nie zgadza się z zakresem, na przykład pomija plik wymieniony wyżej. Sekcja "Odwracalność" bywa podważana przez kod: ticket twierdzi, że nie ma operacji nieodwracalnych, a agent czytający kod znajduje w zakresie migrację bazy. > [!NOTE] > Te same osiem sekcji generuje skill opisany we wpisie [jak działa /monolynx:ticket-create](https://monolynx.com/blog/jak-dziala-monolynx-ticket-create). Recenzja przydaje się najbardziej dla ticketów pisanych ręcznie albo starszych niż ten szablon. ## Dlaczego niezgodność wymaga trzech sprawdzeń? Fałszywy alarm w recenzji jest gorszy niż brak recenzji. Gdy skill błędnie uzna poprawne założenie za niezgodne i "naprawi" ticket, agent dostanie złe wskazówki z pieczątką weryfikacji. Dlatego każde założenie wstępnie oznaczone jako niezgodne przechodzi trzy sprawdzenia różnymi metodami: **Kroki** 1. **Pierwsze źródło** Wynik z wiki albo z kodu, zapisany razem z dowodem. 2. **Drugie źródło** Jeśli pierwsze było wiki, teraz kod. Jeśli kod, teraz wiki albo graf zależności. Z innymi słowami kluczowymi niż za pierwszym razem. 3. **Szersza analiza** Powiązane pliki, czyli importy, wywołania i testy, a w razie potrzeby historia zmian pliku. > Zanim oznaczysz cokolwiek jako niezgodne, musisz to zweryfikować trzy razy różnymi metodami. > -- skill ticket-review, zasada krytyczna Wynik w raporcie może wyglądać tak jak w tym przykładzie, gdzie większość założeń się potwierdziła: **Przykładowy wynik recenzji: status założeń** | Status | Liczba założeń | | --- | --- | | Zgodne | 6 | | Niepewne | 2 | | Niezgodne | 1 | > [!TIP] > Dobry ticket dostaje dobrą recenzję. Skill ma zapisaną zasadę, żeby nie szukać problemów na siłę i analizować tylko to, co faktycznie jest napisane w tickecie. ## Co skill proponuje po raporcie? Raport jest punktem wyjścia do poprawek, a każda grupa problemów ma własne pytanie. Możesz przyjąć jedną propozycję i odrzucić pozostałe. **Porównanie** | Znalezisko | Propozycja | Zapis po zgodzie | | --- | --- | --- | | Założenie niezgodne | konkretny nowy tekst z dowodem z trzech sprawdzeń | aktualizacja opisu | | Założenie niepewne | sekcja "Zwróć uwagę" na końcu opisu | aktualizacja opisu | | Brak listy kryteriów | kryteria z opisu jako pola do odhaczenia | dodanie kryteriów | | Brak sekcji granic | gotowe sekcje "Nie ruszać" i "Odwracalność" | aktualizacja opisu | | Blokery niezgodne z opisem | docelowa lista blokerów | zmiana relacji | Propozycje granic nie są domysłem. Agent czytający kod sprawdza, kto jeszcze importuje pliki z zakresu, i podaje kandydatów z plikiem i numerem linii. > [!WARNING] > Skill nigdy nie zmienia ticketu bez pytania. Zapis blokerów zastępuje całą dotychczasową listę, więc skill zawsze wysyła komplet: stare blokery razem z nowymi. ## Jak działa przegląd sprintu? Tryb `sprint` rozwiązuje inny problem niż recenzja jednego ticketu. Dwa tickety, które zmieniają ten sam plik, nie powinny iść równolegle w osobnych sesjach, bo skończą się konfliktem przy merge i dodatkową rundą CI. Skill pobiera wszystkie tickety w statusie `todo` z aktywnego sprintu i z każdego czyta sekcję "Pliki dotykane". Samych przecięć nie liczy model, tylko dołączony skrypt: ```json title="Wejście skryptu ticket_overlap.py (przykład)" {"tickets": [ {"key": "MON-1", "priority": "high", "files": ["cli/src/a.py", "tests/unit/test_a.py"], "blocked_by": ["MON-7"]}, {"key": "MON-2", "priority": "medium", "files": ["cli/src/a.py"], "blocked_by": []} ]} ``` Skrypt układa kolejność według priorytetu: critical, high, medium, low. Przy równym priorytecie wcześniejszy jest ticket z niższym numerem. Trzy tickety na tym samym pliku dają łańcuch, a nie każdy z każdym: pierwszy blokuje drugi, drugi blokuje trzeci. **Porównanie** | Grupa w wyniku | Znaczenie | Działanie | | --- | --- | --- | | Propozycje | wspólne pliki, brak relacji między ticketami | pytanie o zapis blokera | | Już powiązane | wspólne pliki, relacja już istnieje | bez zmian | | Wspólne, bez blokera | pliki zmieniane przez prawie każdy ticket | bez zmian | | Nie porównano | ticket nie ma listy plików | prośba o uzupełnienie | Trzecia grupa to pliki "zawsze wspólne", takie jak changelog albo manifest wersji. Zmienia je prawie każdy ticket, więc blokada na nich ustawiłaby cały sprint w jedną kolejkę[^wspolne]. **Fragment raportu z przeglądu sprintu (przykład)** ```console Propozycje blokerów # Bloker Blokowany Wspólne pliki 1 MON-1 (high) MON-2 (medium) cli/src/a.py Które propozycje blokerów zapisać? (wszystkie / numery, np. 1,3 / żadne) ``` > [!IMPORTANT] > Sesja w tle, w której nikt nie odpowie na pytanie, kończy przegląd na raporcie. Relacje blokad zapisuje tylko decyzja człowieka, i tylko dla propozycji, które wybrał. ## Najczęstsze pytania Pytania poniżej dotyczą sytuacji, które wracają przy pierwszych recenzjach. **FAQ** ### Czy skill sam poprawi mój ticket? Nie. Skill pokazuje propozycję i pyta. Dopiero po potwierdzeniu aktualizuje opis, kryteria albo relacje blokad. ### Co oznacza status NIEPEWNE? Wiki ani kod nie potwierdziły założenia jednoznacznie, ale też mu nie zaprzeczyły w trzech sprawdzeniach. Skill proponuje wtedy sekcję "Zwróć uwagę", żeby agent realizujący ticket sprawdził ten punkt sam. ### Co, jeśli ticket jest czysto organizacyjny? Skill informuje, że ticket nie zawiera założeń technicznych, i ocenia tylko formę. ### Dlaczego ticket trafił do grupy "Nie porównano"? Ticket nie ma sekcji "Pliki dotykane" albo ma wpis, że zmiana jest poza repozytorium. Pierwszy przypadek naprawia recenzja tego ticketu, która zaproponuje listę plików. ### Czy przegląd sprintu trzeba powtarzać? Warto po przyjęciu tylko części propozycji. Para powiązana wyłącznie przez odrzuconą propozycję wróci wtedy jako nowa propozycja. ## Słownik i następny krok Pojęcia z tego wpisu, w jednym miejscu: **Słownik** - **Założenie** - konkretne twierdzenie z ticketu, które da się sprawdzić w wiki albo w kodzie - **Potrójna weryfikacja** - trzy niezależne sprawdzenia wymagane dla statusu NIEZGODNE - **Bloker** - ticket, który musi mieć status done, zanim zacznie się praca nad innym ticketem - **Pliki dotykane** - sekcja opisu ze ścieżkami plików, które ticket zmieni albo utworzy - **Strona specyfikacji** - strona wiki z decyzjami projektowymi powiązana z ticketem - **Pliki zawsze wspólne** - pliki zmieniane przez większość ticketów, które nie tworzą blokady Zrecenzowany ticket podejmujesz skillem opisanym we wpisie [jak działa /monolynx:work](https://monolynx.com/blog/jak-dziala-monolynx-work). **Wezwanie do działania** Recenzja działa na ticketach z backlogu i sprintów w module Scrum. Zobacz tablicę, z której skill je pobiera. [Poznaj moduł Scrum w Monolynx](https://monolynx.com/features/scrum) [^wspolne]: W repozytorium pluginu Monolynx do tej grupy należą changelog, manifesty wersji, liczniki skilli i generowane kopie skilli.