--- title: "Jak działa /monolynx:ticket-create: ticket, który agent zrealizuje bez pytań" description: "Jak skill /monolynx:ticket-create zamienia jedno zdanie w ticket dla agenta AI: cztery źródła kontekstu, osiem sekcji opisu, blokery i obowiązkowa akceptacja." url: "https://monolynx.com/blog/jak-dziala-monolynx-ticket-create" lang: "pl" author: "Zespół Monolynx" published: "2026-10-07T19:33:33.519714+00:00" modified: "2026-10-07T19:33:33.496887+00:00" last_verified: "2026-10-07" tags: ["plugin", "claude-code", "agenci-ai", "scrum", "tickety"] translations: [] reading_time_minutes: 9 word_count: 1794 --- > [!TLDR] > - Z jednego zdania opisu skill buduje ticket o stałej strukturze: osiem sekcji, od celu po kryteria akceptacji. > - Przed napisaniem opisu zbiera kontekst z czterech źródeł naraz: wiki, grafu zależności, kodu i istniejących ticketów. > - Sekcje "Pliki dotykane", "Nie ruszać" i "Odwracalność" są pisane dla agenta, który potem ticket realizuje. > - Ticket nie powstaje bez Twojej akceptacji, a duplikat zawsze zatrzymuje skill na pytaniu. ## 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. **Nowy ticket z jednego zdania** ```console $ 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. **Statystyki** - **4** - źródła kontekstu odpytywane równolegle - **8** - sekcji w opisie każdego ticketu - **3-10** - kryteriów akceptacji, każde weryfikowalne - **80** - znaków to górna granica długości tytułu > Ticket musi być zrozumiały dla agenta AI: agent musi móc go podjąć i zrealizować bez dodatkowych pytań. > -- skill ticket-create, ważne zasady ## 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. **Kroki** 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. **Przebieg skilla ticket-create** Opis zadania trafia równolegle do czterech źródeł kontekstu: wiki, grafu zależności, kodu i listy istniejących ticketów. Wyniki przechodzą przez kontrolę duplikatów, a potem skill pokazuje propozycję ticketu. Użytkownik akceptuje ją, prosi o zmianę albo o podział. Dopiero po akceptacji ticket jest zapisywany. ```mermaid 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. **Porównanie** | Źródło | Na co odpowiada | Trafia do sekcji | | --- | --- | --- | | Wiki | co już ustalono i opisano | Kontekst, strona specyfikacji | | Graf zależności | co jest powiązane z tym kodem | Zakres, Zależności, Nie ruszać | | Kod | co istnieje, a czego brakuje | Zakres, Pliki dotykane | | Tickety, sprinty, etykiety | czy ktoś już to robi | Zależności, sprint, etykiety | 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. > [!NOTE] > Graf zależności bywa niedostępny, na przykład gdy projekt nie ma jeszcze zsynchronizowanego kodu. Skill pomija wtedy to źródło i opiera się na analizie kodu. Pozostałe trzy źródła są obowiązkowe. ## 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. **Porównanie** | Sekcja | Co zawiera | Kto z niej korzysta | | --- | --- | --- | | Cel | co ma być zrobione, w 1-3 zdaniach | każdy czytelnik | | Kontekst | dlaczego zadanie istnieje | każdy czytelnik | | Zakres | obszary zmian z nazwami plików i endpointów | agent realizujący | | Pliki dotykane | ścieżki zmienianych i nowych plików | przegląd sprintu | | Nie ruszać | pliki i zachowania poza zakresem, z powodem | agent realizujący | | Odwracalność | operacje, których nie cofnie revert | kontrakt autonomii | | Zależności | blokery i tickety powiązane | dyspozytor sprintu | | Kryteria akceptacji | weryfikowalne warunki ukończenia | krytyk i człowiek | Przykład pokazuje, jak wygląda fragment gotowego opisu: ```markdown title="Fragment opisu ticketu (przykład)" ## 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 ``` **Pełny szkielet opisu ticketu** ```markdown ## 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. > [!TIP] > Usprawnienia "przy okazji", które nasuwają się podczas analizy kodu, skill wpisuje do sekcji "Nie ruszać" zamiast do zakresu. Granica zapisana jest tańsza niż granica odkryta po jej przekroczeniu. ### 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. **Story points według zakresu zmian** | Zakres | Najmniej | Najwięcej | | --- | --- | --- | | Mały (1-2 pliki) | 1 | 2 | | Średni (3-5 plików) | 3 | 5 | | Duży (6+ plików) | 8 | 13 | > [!WARNING] > Ticket powyżej 8 story points to sygnał do podziału. Skill proponuje wtedy 2-4 mniejsze tickety, każdy z pełnym opisem, i pyta o akceptację każdego z osobna. 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](https://monolynx.com/blog/jak-dziala-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. **Porównanie** | Grupa | Znaczenie | Co robi skill | | --- | --- | --- | | Duplikat | ticket o tym samym celu | zatrzymuje się i pyta, czy mimo to tworzyć nowy | | Bloker | musi być zakończony przed startem | zapisuje relację blokady | | Powiązany | ten sam moduł albo temat | wymienia tylko w opisie | Bloker jest zapisywany strukturalnie, jako relacja między ticketami, a nie w komentarzu[^blokery]. Ma to skutek praktyczny: skille `work` i `work-simple` oraz dyspozytor sprintu nie zaczną ticketu, dopóki jego bloker nie ma statusu `done`. > [!IMPORTANT] > Do relacji blokady trafiają tylko prawdziwe blokery. Wpisanie tam ticketu, który jest jedynie powiązany tematycznie, zatrzyma pracę nad nowym ticketem bez powodu. ## 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: **Potwierdzenie utworzenia ticketu** ```console 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. **FAQ** ### Czy skill utworzy ticket bez mojej zgody? Nie. Akceptacja jest obowiązkowym krokiem. Skill wyświetla propozycję i czeka na odpowiedź. ### Co, jeśli projekt nie ma grafu zależności ani wiki? Skill pomija niedostępny graf i opiera się na analizie kodu. Pusta wiki nie przeszkadza: wyszukiwanie zwraca po prostu brak wyników, a kontekst pochodzi z kodu i ticketów. ### Czy mogę poprawić propozycję przed zapisem? Tak. Wskazujesz, co zmienić, a skill poprawia ticket, pokazuje go ponownie i pyta jeszcze raz. ### Czy kryteria akceptacji trzeba dodawać osobno? Nie. Kryteria z opisu są tworzone razem z ticketem jako osobne pola do odhaczenia, w jednym wywołaniu. ### Po co lista plików, skoro agent i tak czyta kod? Lista nie jest dla agenta, który realizuje ticket, tylko dla przeglądu sprintu. Porównanie list z kilku ticketów pokazuje, które zmieniają te same pliki i wymagają ustalenia kolejności. ## Słownik i następny krok Pojęcia z tego wpisu, w jednym miejscu: **Słownik** - **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`. **Wezwanie do działania** Tickety utworzone skillem trafiają do backlogu i sprintów w module Scrum. Zobacz tablicę, na której lądują. [Poznaj moduł Scrum w Monolynx](https://monolynx.com/features/scrum) [^blokery]: Relację blokady zapisuje parametr `blocked_by_ids`, który przyjmuje identyfikatory UUID ticketów z tego samego projektu.