Cześć!
Dzisiaj kontynuujemy Przewodnik 101 po Cursorze dla PM/PO. Jeśli przeszedł_ś pierwszą część, masz już działający projekt w Cursorze i wiesz, jak zlecać AI zadania.
Czas na następny poziom: zapisane komendy („Commands”). Przestajesz szukać i robić ciągłe copy & paste swoich najważniejszych procedur i promptów we współpracy z AI. Trzymasz je w projekcie i wywołujesz jednym wygonie jednym konkretnym znakiem: /
Zostały ostatnie 4 bilety na 10x Product Bootcamp, gdzie ćwiczymy wykorzystanie AI na konkretnym produktowym case study. Ultrakrótkie iteracje, walidacja pomysłów i decyzje oparte na dowodach z AI. Zacznij pracować w ten sposób.
1️⃣ Moja historia zarządzania promptami
2️⃣ Czym są komendy (Commands)?
3️⃣ Dwa poziomy komend - project vs user
4️⃣ Tworzenie własnej komendy w Curosorze
5️⃣ Mój konkretny use-case
6️⃣ Kiedy używać Commands, a kiedy innych mechanizmów?
7️⃣ Jak to wygląda w innych środowiskach? Przykład Claude Code
👉 Co dalej?
1. Moja historia zarządzania promptami
Kilka lat temu, gdy zaczynałem intensywnie pracować z ChatGPT, szybko natrafiłem na problem: gdzie trzymać dobre prompty? Też masz / miał_ś z tym pewnie problem.
Najpierw stworzyłem publiczną bazę najlepszych promptów dla product managerów - opisałem ją w artykule na Product Craft, gdzie przez 30 dni testowałem ChatGPT jako swojego wirtualnego asystenta. Każdy działający prompt zapisywałem, żeby móc go powtórnie użyć.
Potem baza wylądowała w Apple Notes. Wydawało się, że to spoko miejsce - z notatek dużo korzystam, niby zawsze pod ręką. Ale działało to tak: otwierasz Notes, szukasz prompta, kopiujesz, wracasz do ChatGPT, wklejasz, dodajesz kontekst, wysyłasz. Siedem kroków zamiast jednego.
Największy problem był inny - prompty były oderwane od systemu pracy. Leżały sobie w jakimś folderze w aplikacji do notatek, kompletnie niezintegrowane z tym, nad czym akurat pracujesz.
Moja praca z agentami AI - i Cursorem w szczególności - to zmieniła. Teraz konkretne komendy, w tym prompty które mi się sprawdzają, mogę zapisać wprost w projekcie i wywoływać jednym gestem. Bez szukania, bez kopiowania, bez tracenia kontekstu.
2. Czym są komendy (Commands)?
Commands to zapisane prompty lub procedury, które wywołujesz wpisując /nazwa w czacie Cursora (lub innego środowiska - takiego jak Claude Code czy Google Antigravity).
Wyobraź sobie makra w Excelu - coś, co robisz regularnie, zapisujesz raz i uruchamiasz jednym kliknięciem. Commands działają dokładnie tak, tylko dla pracy z AI.
Kilka przykładów co możesz zapisać jako komendę:
/napisz-taska - tworzy opis zadania w Twoim formacie
/podsumuj-spotkanie - przetwarza surowe notatki na czytelne podsumowanie
/weekly-brief - przechodzi przez swoja stanrdową procedurę tygodniową
/analiza-feedbacku - kategoryzuje feedback od użytkowników według priorytetów
/brief-ficzer - generuje brief dla nowej funkcji zgodnie z Twoim templatem3. Dwa poziomy komend - project vs user
Zanim stworzysz komendę, warto wiedzieć że masz dwa poziomy - i wybór zależy od tego, do czego komenda ma służyć:
Project commands - komendy przypisane do konkretnego projektu/folderu:
Zapisywane w
.cursor/commands/wewnątrz folderu projektuWidoczne tylko gdy masz ten projekt otwarty w Cursorze
Idealne gdy komenda jest specyficzna dla danego produktu, zespołu lub klienta (np. format tasków właśnie dla tego zespołu dev, styl dokumentacji pod konkretny projekt)
User commands - komendy globalne, dostępne wszędzie:
Zapisywane w
~/.cursor/commands/w folderze domowym na Twoim komputerzeDostępne w każdym projekcie, niezależnie od tego co masz otwarte
Idealne dla komend, których używasz bez względu na projekt (np.
/podsumuj-spotkanie,/napisz-maila,/analiza-feedbacku)
3. Tworzenie własnej komendy w Curosorze
Krok 1: Tworzenie Commmand
Możesz tworzyć komendy bezpośrednio z interfejsu Cursora - w ustawieniach jest dedykowana sekcja Commands, gdzie dodasz nową komendę bez wychodzenia z aplikacji (tam też wybierasz poziom: project lub user).
Możesz też stworzyć folder i plik ręcznie - efekt jest identyczny:
twoj-projekt/
└── .cursor/
└── commands/
└── napisz-taska.md ← project command
~/.cursor/
└── commands/
└── podsumuj-spotkanie.md ← user command (globalny)
Dodaj więcej pierwszą komendę - dla przykładu zrobimy sobie komendę opisującą zadanie do Jira w odpowiednim, używanym przez nas, formacie.
Krok 2: Napisz komendę jako plik Markdown
Zawartość pliku to po prostu instrukcja dla AI - opisz co ma robić, kiedy wywołasz tę komendę.
Tu przykładowa komenda:
Na podstawie poniższych informacji - napisz opis zadania
dla zespołu developerskiego na Jira.
## Format opisu
Każde zadanie powinno mieć:
- Tytuł: format User Story
- 2-3 zdania: jaki jest problem i dlaczego to ważne
- Sekcja "Possible solution" z punktorami (opcjonalna, nie techniczna)
## Zasady
- Pisz po angielsku
- Skup się na problemie biznesowym, nie na implementacji
- Jeśli brakuje informacji, zapytaj mnie
## Kontekst Produktu
Kontekst produktu znajdziesz w [nazwa pliku]Jeśli dodajesz komendę z interfejsu użytkownika w ustawieniach - po prostu wpisz tam tę powyższa komendę.
Jeśli tworzysz plik to pamiętaj, że nazwa pliku = nazwa komendy. Plik
napisz-taska.md→ to komenda/napisz-taska.
Krok 3: Wywołaj komendę
W czacie Cursora wpisz / - pojawi się lista dostępnych komend z autocomplete:
/napisz-taska opis funkcji eksportu raportów do PDF... (i tu dalszy opis)
Wszystko co napiszesz po nazwie komendy trafia jako dodatkowy input do AI. Finalnie to co dostaje AI składa się z:
PROMPT do AI = zawartość komendy + to co wpisał_ś wywołując komendę
4. Mój konkretny use-case
Jako PM w BrainBits mam swój ustalony sposób opisywania zadań do backlogu. Krótko, problem-first, bez zbędnych technicznych szczegółów (od tego jest zespół).
Problem był taki: za każdym razem gdy prosiłem AI o napisanie taska, dostawałem rozbudowany, techniczny opis z milionem szczegółów, których nie chciałem. AI nie wiedziało, na jakim opsie taska mi zależy.
Stare rozwiązanie (korzystałem z aystenta AI):
miałem więc swój prompt, który doklejał do każdego wywołania w ChatGPT. Kopiowałem go z mojego notesu.
Potem zrobiłem sobie dedykowany projekt w ChatGPT (“JIRA TASK”) - który w kontekście projektu miał moją instrukcje opisywania zadania. Teoretycznie to działało, ale problem tylko był taki, że rozkminiając jakiś temat z AI, gdy już wiedziałem jakie zadanie che stworzyć - musiałem kopiować treść, zmieniać projekt na “JIRA TASK” i tam dalej pracować nad zadaniem.
Dzięki pracy z agentem w Cursorze, w dowolnym momencie, dowolnej rozmowy używam po prostu komendy:
/jira-task [opcjonalnie dodatkowy opis taska]Jeden slash, często nawet nie musze dodawać dodatkowego opisu, bo to przecież wynika z historii rozmowy. No i AI wie dokładnie jak ma wyglądać wynik.
Mój plik komendy wygląda tak:
# jira-task
Write task descriptions that are short, problem-focused, and dev-friendly.
## Task Structure
```
title: [Action verb] + [What] + [Where/Context]
[2-3 sentences: What's the problem? Why does it matter?]
Possible solution:
* [Bullet points with implementation hints - optional, not prescriptive]
```
## Writing Rules
1. **Title**: Start with action verb (Add, Fix, Enable, Implement, Remove)
2. **Problem first**: Describe current pain point and business impact
3. **User perspective**: Use "As a [role]..." or "Currently..." or "We want to..."
4. **Solutions are hints**: Suggest direction, don't dictate implementation
5. **Keep it short**: 3-6 lines total (excluding title)
## Examples
**Good:**
```
title: Add link to specific message in Transactions view
Problem: Currently, the Transactions view shows transaction
records but lacks a direct link to the message that triggered the transaction.
As a user I need to manually search for the relevant message,
sometimes is time-consuming.
Possible solution:
* Add link to amount of money
```
**Good:**
```
title: Possibility to calculate LLM generation time
We want to review how long it takes to generate LLM response
(generation time) - it will help AI team evaluate LLM performance.
TO DO:
* save additional data in database that will make possible
to get or calculate "LLM generation time"
```
**Bad (too technical, no problem statement):**
```
title: Implement PostgreSQL trigger for message_id foreign key
Add trigger function that creates index on transactions.message_id
column and implements JOIN optimization for message lookup queries using CTE.
```
## Language
Write in English. Use simple, direct sentences.Kluczowa zaleta: jeśli zmieni mi się sposób opisywania tasków - edytuję jeden plik. Mogę o tę edycje poprosić nawet agenta - nie muszę tego robić sam. Najważniejsze, że wszystkie przyszłe wywołania /napisz-taska będą używać nowego formatu.
5. Jak to wygląda w innych środowiskach? Przykład Claude Code
Commands to nie wynalazek Cursora - to universal pattern w pracy z agentami AI. Niezależnie od narzędzia, idea jest ta sama: zapisujesz procedurę raz, wywołujesz wielokrotnie.
Jeśli już uczysz się tej filozofii w Cursorze - w Claude Code (lub innym systemie z agentami) będziesz się czuł jak w domu. Pliki komend mają tę samą strukturę Markdown, ta sama lokalizacja, ten sam sposób wywołania.
“Uczysz się raz, stosujesz wszędzie. Twoje komendy to Twoje know-how w formie kodu.”
6. Kiedy używać Commands, a kiedy innych mechanizmów?
W Cursorze są trzy sposoby na zapisanie swoich “instrukcji” dla AI. Ważne, żeby wiedzieć kiedy których używać:
Na razie skup się na Commands - to najprostszy i najszybszy sposób na zorganizowanie swoich promptów. Rules i Skills opiszę w kolejnych częściach tej serii.
✅ Zadanie dla Ciebie:
Zastanów się jakie powtarzalne akcje najczęściej wywołujesz ze swoim asystentem AI i spróbuje dla nich zrobić komendę w Cursorze.
👉 Co dalej?
Commands rozwiązują realny problem każdego PM-a pracującego z AI: gdzie trzymać dobre prompty i jak je szybko wywoływać.
Zamiast szukać po Apple Notes / Notion - wpisujesz / i wybierasz z listy. Twoje instrukcje żyją tam, gdzie pracujesz.
W kolejnym artykule z serii opiszę kolejne mechanizmy zarządzania kontekstem - Agents.md, Skills i Rules. Ale najpierw wejdź w komendy - to fundament.
