Jak działa /monolynx:ticket-review: recenzja ticketu, zanim agent zacznie pracę

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.

> /monolynx:ticket-review MON-123
> /monolynx:ticket-review sprint

Bez argumentu skill pokazuje tablicę Kanban i pyta, który ticket zrecenzować.

Osiem kroków recenzji jednego ticketu

Recenzja ma stałą kolejność: najpierw forma, potem dwa źródła prawdy, na końcu raport i propozycje.

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.

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.

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.

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:

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.

Wynik w raporcie może wyglądać tak jak w tym przykładzie, gdzie większość założeń się potwierdziła:

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.

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.

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:

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

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

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)

Najczęstsze pytania

Pytania poniżej dotyczą sytuacji, które wracają przy pierwszych recenzjach.

Słownik i następny krok

Pojęcia z tego wpisu, w jednym miejscu:

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.