Pisanie tasków do Jiry / Lineara to jedna z tych czynności, które PM robi codziennie i w której AI może Ci w tym mocno pomóc. Problem w tym, że domyślnie – nie robi tego dobrze.
Prosisz o opis zadania, dostajesz elaborat z detalami implementacyjnymi, schematem bazy danych i pięcioma sekcjami, których nikt nie potrzebuje. Tymczasem Ty masz swój konkretny schemat – u mnie jest to np. podejście żeby zespół wiedział, jaki problem ma rozwiązać i miał przestrzeń, żeby to zrobić po swojemu. Bez technikaliów.
Upubliczniam więc mój skill do agenta AI pomagający mu przygotować opis zadania w odpowiednim formacie (używany w Cursorze i Claude, ale zadziała też w innych agentach). Możesz na jego podstawi przygotować własny skill, tworzyć lepsze opisy zadań, które potem finalnie, czy to ręcznie, czy przez serwer MCP wstawisz do Jira.
W środku znajdziesz:
- dlaczego domyślny AI pisze taski źle i co konkretnie go psuje
- jak wygląda mój styl pisania tasków – struktura, której używam
- jak zbudowałem skilla, który wymusza ten styl przy każdym zadaniu
- jak wygląda działanie na moim realnym tasku
🎦 Nagranie (6 min)
W tym video pokazuję, jak stworzyłem skilla, który zmusza asystenta AI do opisywania tasków w Jirze tak, jak ja to robię – problem-focused, bez zbędnych szczegółów technicznych – i jak jednym poleceniem wrzucić gotowy opis prosto do Jiry. Zrobiłem to w Cursorze (sprawdź mój crash course dla PMów), ale możesz równie dobrze skorzystać z Claude Code, Claude Cowork, czy Codex.
Skill możesz pobrać tutaj ⤵️
1️⃣ Mój skill do pisania tasków
Skill składa się z trzech elementów, które razem wymuszają odpowiedni styl:
Struktura taska
Każdy task ma dokładnie trzy elementy:
title: [czasownik akcji] + [co] + [gdzie/kontekst]
[2-3 zdania: jaki jest problem? dlaczego to ważne?]
Possible solution:
* [podpowiedzi kierunkowe - opcjonalne, nie prescriptywne]Zasady pisania
- tytuł zaczyna się od czasownika akcji (Add, Fix, Enable, Implement, Remove)
- najpierw problem i jego wpływ biznesowy, nie rozwiązanie
- „Possible solution” to podpowiedź dla zespołu, nie instrukcja
- całość: 3-6 linijek (bez tytułu)
- zawsze po angielsku – nawet jeśli rozmawiamy po polsku
Przykłady – dobry i zły
To, co robi największą różnicę w skilu, to konkretne przykłady tego, jak task powinien wyglądać – i jak nie powinien.
Dobry:
title: Add LLM model info to conversation view
Currently, when reviewing conversations in the panel,
we can see the prompt and LLM output but not which model
generated the response. This makes debugging harder
when we run A/B tests across models.
Possible solution:
* Show model ID as a tooltip next to the responseZły (zbyt techniczny, brak opisu problemu):
title: Implement model_id field in conversation_logs table
Add foreign key constraint on conversation_logs.model_id
referencing llm_models table. Create index for JOIN
optimization using CTE in message lookup queries.Bez przykładów AI domyśla się stylu. Z przykładami – wie dokładnie, co jest akceptowalne, a co nie.
2️⃣ Jak zbudować własnego skilla?
Nie musisz kopiować mojego skilla – możesz zbudować własny pod swój styl. Wrzuć mój jako przykład i poproś swojego agenta, by pomógł przygotować Ci Twój własny. Trzy elementy, które bedą mają na niego największy wpływ:
- Struktura – co ma być w tasku i w jakiej kolejności. Wypisz dosłownie sekcje, które chcesz widzieć.
- Zasady pisania – co jest ważne, czego unikać. „Nie opisuj implementacji, opisuj problem” to konkretna reguła, którą AI może zastosować.
- Przykłady – minimum jeden dobry i jeden zły. To najszybszy sposób na przekazanie stylu, którego słowami trudno precyzyjnie opisać.
Jeden dobrze napisany skill eliminuje konieczność poprawiania AI przy każdym kolejnym tasku.
