Jak działa /monolynx:ticket-create: ticket, który agent zrealizuje bez pytań

Po co osobny skill do pisania ticketów?

Ticket napisany dla człowieka zwykle nie wystarcza agentowi AI. Człowiek dopyta kolegę, w którym pliku jest logika i czego lepiej nie dotykać. Agent tego nie zrobi: weźmie to, co jest w opisie, i resztę zgadnie.

Skill ticket-create z pluginu Monolynx dla Claude Code pisze ticket tak, żeby agent mógł go podjąć i zrealizować bez dodatkowych pytań. Argumentem jest krótki opis zadania, jedno albo dwa zdania.

$ claude
> /monolynx:ticket-create Wiki: eksport strony do PDF

Bez argumentu skill prosi o opis i czeka. Nie zaczyna zbierać kontekstu, dopóki nie wie, czego dotyczy zadanie.

Osiem kroków od zdania do ticketu

Przebieg ma stałą kolejność, a dwa kroki są obowiązkowe bez wyjątku: zebranie kontekstu i akceptacja użytkownika.

1. Narzędzia

   Skill ustala projekt i kanał rozmowy z platformą: CLI albo MCP.

2. Opis zadania

   Argument wywołania jest punktem wyjścia. Gdy go brakuje, skill pyta o jedno lub dwa zdania.

3. Kontekst

   Cztery źródła naraz: wiki, graf zależności, kod oraz istniejące tickety, sprinty i etykiety.

4. Duplikaty i zależności

   Podobne tickety są dzielone na duplikaty, blokery i powiązane.

5. Propozycja

   Skill wyświetla gotowy ticket: tytuł, priorytet, story points, sprint, etykiety i opis w ośmiu sekcjach.

6. Akceptacja

   Trzy opcje: utwórz, zmień albo podziel na mniejsze. Opcjonalnie powstaje strona specyfikacji w wiki.

7. Zapis

   Jedno wywołanie tworzy ticket razem z kryteriami akceptacji i blokerami.

8. Seria

   Przy dużym zakresie skill proponuje serię ticketów w kolejności realizacji.

flowchart TD
  A[Opis zadania] --> B[Wiki]
  A --> C[Graf zależności]
  A --> D[Kod]
  A --> E[Tickety, sprinty, etykiety]
  B --> F[Duplikaty i zależności]
  C --> F
  D --> F
  E --> F
  F --> G[Propozycja ticketu]
  G -->|zmień| G
  G -->|podziel| G
  G -->|akceptuj| H[Zapis ticketu]

Skąd skill bierze kontekst?

Kontekst pochodzi z czterech źródeł, które skill odpytuje równolegle. Każde odpowiada na inne pytanie, więc żadne nie zastępuje pozostałych.

Kod czyta osobny agent, który ma tylko odczyt. Jego raport ma stały układ: istniejący kod ze ścieżką i linią, brakujące elementy, zależności, pliki do zmiany i szacowany zakres. Z tego zakresu powstają potem story points.

Co zawiera opis ticketu?

Opis ma osiem sekcji w stałej kolejności. Pierwsze trzy znasz z każdego dobrego ticketu, pięć kolejnych jest napisanych z myślą o agencie.

Przykład pokazuje, jak wygląda fragment gotowego opisu:

## Pliki dotykane

- `src/monolynx/services/wiki.py`
- `src/monolynx/dashboard/wiki.py`
- `tests/integration/test_wiki_export.py`

## Nie ruszać

- `services/reports.py` - eksport raportów ma własny szablon PDF
- format odpowiedzi `/api/v2/.../wiki/pages` - konsumuje go CLI

## Odwracalność

- Odwracalne: cały kod
- Nieodwracalne / wymaga zgody przed wykonaniem: brak

## Cel
[1-3 zdania: co ma być zrobione]

## Kontekst
[1-3 zdania: dlaczego to zadanie istnieje]

## Zakres
### 1. [Pierwszy obszar zmian]
- [konkretna zmiana, z plikiem lub modułem]

## Pliki dotykane
- `[ścieżka/względem/repo/plik.py]`

## Nie ruszać
- [plik, moduł albo zachowanie, z powodem]

## Odwracalność
- Odwracalne: [co cofnie zwykły revert]
- Nieodwracalne / wymaga zgody przed wykonaniem: [albo brak]

## Zależności
- Bloker: [KEY] [tytuł] (status) - [dlaczego blokuje start]

## Kryteria akceptacji
- [ ] [warunek konkretny i weryfikowalny]

Trzy sekcje, których nie ma w zwykłym tickecie

Sekcje "Pliki dotykane", "Nie ruszać" i "Odwracalność" czytają inne skille pluginu, więc mają sztywne zasady.

Pliki dotykane

Lista ścieżek ma format, który czyta skrypt: jedna ścieżka względem repozytorium na linię, w odwrotnych apostrofach, bez opisu i bez wzorców z gwiazdką. Nowe pliki i testy też się liczą. Na tej liście przegląd sprintu wykrywa tickety, które zmieniają te same pliki i nie powinny iść równolegle.

Nie ruszać

Granica zadania jest częścią zadania, a nie domysłem. Skill wpisuje tu sąsiedztwo z grafu, które kusi, ale nie jest potrzebne, pliki z ticketów będących w toku oraz publiczne kontrakty, takie jak format odpowiedzi API. Każda pozycja ma powód.

Odwracalność

Sekcja wymienia operacje, których nie cofnie git revert: migrację z danymi, wysyłkę maila albo webhooka, publikację pakietu, zmianę publicznego API i kasowanie danych. Z tej listy skill work buduje kontrakt autonomii, czyli spis rzeczy, przed którymi agent ma się zatrzymać i zapytać. Zadanie bez takich operacji dostaje wpis "brak", napisany wprost.

Ile story points dostaje ticket?

Story points wynikają z liczby plików, którą oszacował agent czytający kod. Skill nie zgaduje ich z tytułu.

Wynik ma znaczenie dla dalszej pracy. Tickety do 3 story points nadają się do skilla work-simple, większe prowadzi pełny work, opisany we wpisie jak działa /monolynx:work.

Duplikaty, blokery i tickety powiązane

Podobne tickety, które skill znalazł w projekcie, trafiają do jednej z trzech grup. Od grupy zależy, co skill z nimi zrobi.

Bloker jest zapisywany strukturalnie, jako relacja między ticketami, a nie w komentarzu¹. Ma to skutek praktyczny: skille work i work-simple oraz dyspozytor sprintu nie zaczną ticketu, dopóki jego bloker nie ma statusu done.

Akceptacja i zapis

Skill nigdy nie tworzy ticketu bez akceptacji. Po wyświetleniu propozycji masz trzy opcje: zaakceptować, wskazać zmiany albo poprosić o podział. Po zmianach skill pokazuje ticket ponownie i pyta jeszcze raz.

Po akceptacji pada jedno opcjonalne pytanie: czy utworzyć w wiki stronę specyfikacji powiązaną z ticketem. Domyślna odpowiedź to "nie".

Ticket powstaje jednym wywołaniem, razem z kryteriami akceptacji jako osobnymi polami do odhaczenia. Na końcu skill podaje oba identyfikatory:

Utworzono ticket MON-273 - Wiki: eksport strony do PDF
ID: 5d0c2f7e-1a34-4b8e-9c61-2f7a8e0b4d19
Blokowany przez: MON-268

Najczęstsze pytania

Pytania poniżej dotyczą sytuacji, które zdarzają się przy pierwszych ticketach pisanych skillem.

Słownik i następny krok

Pojęcia z tego wpisu, w jednym miejscu:

Story points

umowna miara wielkości zadania, tu liczona z liczby zmienianych plików

Kryterium akceptacji

warunek, o którym da się jednoznacznie powiedzieć, czy jest spełniony

Bloker

ticket, który musi mieć status done, zanim zacznie się praca nad innym ticketem

Strona specyfikacji

strona wiki z decyzjami projektowymi powiązana z ticketem

Graf zależności

mapa plików, klas i funkcji projektu oraz powiązań między nimi

Kontrakt autonomii

spis tego, co agent robi sam, i tego, przed czym się zatrzymuje

Gotowy ticket warto sprawdzić skillem /monolynx:ticket-review, a potem podjąć skillem /monolynx:work.