Cursor od kuchni: MCP, Skills, Rules i Pluginy

Większość osób, które po raz pierwszy słyszą o Cursorze, wyobraża sobie go jako „edytor kodu z czatem AI po boku”. To trochę tak, jakby nazwać samolot „samochodem, który lata”. Technicznie to prawda, ale nie oddaje istoty rozwiązania.

Cursor nie tylko podpowiada kolejną linię kodu. Potrafi przeanalizować cały projekt, otworzyć terminal, uruchomić testy, naprawić błąd, pobrać projekt z Figmy, sprawdzić zgłoszenie w systemie zarządzania zadaniami, a na końcu utworzyć Pull Request. Za tym całym „układem nerwowym” stoi kilka mechanizmów, o których większość osób nigdy nie słyszała: MCP, Rules, Commands, Skills i pluginy.

Ten artykuł omawia je konkretnie i bez zbędnych ozdobników.

Jak to naprawdę działa od kuchni

Zwykły czat AI działa jak rozmowa przez okno: wklejasz fragment kodu, otrzymujesz odpowiedź i gotowe. Nie widzi całego projektu, nie zna struktury folderów i nie wie, że podobna funkcja może już istnieć w innym pliku.

Cursor działa inaczej, ponieważ ma dwie rzeczy, których nie ma zwykły czat.

1. Indeksowanie kodu: Cursor tworzy embeddingi, czyli matematyczne „odciski palca” każdego pliku w projekcie. Dzięki temu podczas rozmowy może samodzielnie odnaleźć właściwy plik zamiast czekać, aż użytkownik go wskaże. Kod pozostaje na dysku użytkownika. Do chmury trafiają jedynie wektory.
2. Pętla agenta: Zamiast pojedynczej odpowiedzi otrzymujesz cykl działań: agent odczytuje plik, edytuje kod, uruchamia polecenie w terminalu, sprawdza rezultat, a jeśli coś się nie uda, próbuje ponownie. Robi to samodzielnie, bez konieczności ponownego kopiowania i wklejania treści.

Uwaga: Autonomia nie oznacza, że agent wykonuje dowolne działania bez pytania. Domyślnie przed uruchomieniem poleceń terminalowych prosi o zgodę. Można poluzować te ustawienia, ale należy robić to ostrożnie.

To właśnie ta pętla sprawia, że MCP, Rules, Commands i Skills mają znaczenie. Gdyby agent nie potrafił samodzielnie realizować zadań wieloetapowych, cały ten ekosystem byłby bezużyteczny.

MCP, czyli gdy agent wychodzi poza bazę kodu

MCP (Model Context Protocol) to otwarty standard, który umożliwia agentowi komunikację z narzędziami spoza projektu: systemami zadań, bazami danych, Figmą, GitHubem, przeglądarką i wieloma innymi usługami. Bez MCP agent widzi wyłącznie zawartość folderu projektu oraz to, co użytkownik wpisze na czacie. Z MCP może samodzielnie sprawdzić informacje w zewnętrznych systemach.

Najprostsza analogia: MCP jest jak port USB dla agenta AI. Nie trzeba projektować nowego kabla dla każdego urządzenia. Wspólny standard pozwala podłączyć niemal dowolny „adapter”.

Mechanizm jest prosty. Cursor działa jako klient, a każdy serwer MCP, czyli oddzielny i odizolowany proces, udostępnia konkretną usługę. Konfigurację zapisuje się w jednym pliku:

// .cursor/mcp.json
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}" }
    },
    "figma": {
      "url": "https://mcp.figma.com/mcp"
    }
  }
}

Następnie wystarczy opisać zadanie zwykłym językiem:

Pobierz zgłoszenie GitHub #42, zaimplementuj poprawkę, napisz testy i utwórz Pull Request.

W jednym przebiegu agent odczytuje zgłoszenie, analizuje kod, wprowadza zmiany, dodaje testy, wykonuje commit, wysyła zmiany i na końcu zwraca link do gotowego PR. Nie trzeba przełączać się między pięcioma aplikacjami.

Ten sam schemat działa z Figmą, gdy agent pobiera układ, kolory i odstępy, a następnie generuje komponent; z bazą danych, gdy odczytuje schemat tabeli i tworzy migrację; oraz z narzędziami testowymi, które mogą automatycznie korygować testy po nieudanym uruchomieniu.

Wskazówka: Jednocześnie pozostawiaj podłączone tylko te serwery MCP, których faktycznie używasz na co dzień, najlepiej dwa lub trzy. Przykładowo: GitHub do kodu, Figma do projektu i Jira do zadań. Pozostałe integracje mogą utrudniać agentowi wybór właściwego narzędzia.

Bezpieczeństwo: Tokeny i klucze API przechowuj w zmiennych środowiskowych. Nigdy nie zapisuj ich bezpośrednio w pliku konfiguracyjnym, ponieważ taki plik często trafia do repozytorium.

Rules, Commands i Skills: mózg oraz ręce agenta

W tym miejscu zaczyna się najciekawsza część, ponieważ te trzy pojęcia są najczęściej mylone. Różnicę można ująć w jednym zdaniu:

• Rules, czyli reguły, to wytyczne, których agent powinien zawsze przestrzegać w tle, bez dodatkowego polecenia.
• Commands, czyli komendy, to konkretne działania uruchamiane ręcznie przez użytkownika.
• Skills, czyli umiejętności, to gotowe i bardziej zaawansowane procedury, które agent może załadować i zastosować samodzielnie, gdy uzna je za przydatne.

Przykład reguły

---
description: Standardy komponentów React
globs: ["**/*.tsx"]
alwaysApply: false
---
Tylko komponenty funkcyjne, bez komponentów klasowych.
Maksymalnie 150 linii na komponent.
Logikę dłuższą niż 10 linii przenieś do własnego hooka.

Taka reguła ładuje się automatycznie tylko podczas pracy z plikiem .tsx. Nikt nie musi o niej pamiętać. Działa w tle podobnie jak ustawienia stylu w edytorze.

Przykład komendy

# .cursor/commands/review.md
Sprawdź bieżący plik pod kątem:
1. Niepotrzebnych ponownych renderowań.
2. Brakujących kluczy na listach.
3. Problemów z dostępnością (ARIA, fokus).
4. Komponentów dłuższych niż 150 linii.
Oceń każde znalezisko jako: krytyczne, ostrzeżenie lub sugestia.

Po wpisaniu /review agent od razu wie, co zrobić. Nie trzeba za każdym razem przepisywać całej listy kontrolnej.

Przejdźmy dalej

Prosta zasada: Jeżeli coś ma być przestrzegane zawsze, jest to Rule. Jeżeli uruchamiasz coś ręcznie i cyklicznie, jest to Command. Jeżeli jest to złożony, samodzielny proces, który agent może zastosować wtedy, gdy będzie potrzebny, jest to Skill.

Żaden z tych mechanizmów nie działa w pełnej izolacji. Największą wartość uzyskuje się, gdy zostaną połączone:

• Rule utrzymuje spójność kodu w tle,
• Command daje ręczny przycisk do uruchomienia działania,
• a Skill zawiera cały przepływ pracy, który agent może wykonać samodzielnie po rozpoznaniu odpowiedniej sytuacji.

.cursor/
├── rules/
│   └── react.mdc              # konwencje dla plików .tsx
├── commands/
│   └── review.md              # ręczne uruchomienie: /review
└── skills/
    └── code-review/
        └── SKILL.md            # pełny proces przeglądu kodu

W praktyce plik react.mdc zapewnia spójność komponentów bez dodatkowego działania. Komenda /review umożliwia szybkie ręczne sprawdzenie kodu. Skill code-review obejmuje dłuższą procedurę: odczyt różnic, porównanie z regułami, oznaczenie problemów i zaproponowanie poprawek. Agent może zastosować tę umiejętność samodzielnie, gdy pracuje nad czymś, co przypomina Pull Request.

Nad tym wszystkim znajduje się jeszcze plik AGENTS.md umieszczony w katalogu głównym projektu. Można traktować go jak „instrukcję obsługi projektu” dla agenta: krótki opis architektury, konwencji oraz sposobu myślenia o repozytorium jako całości. Szczegóły implementacyjne powinny pozostać w regułach.

Najczęstszy błąd: Umieszczanie w regułach ogólnych zapisów, takich jak „pisz czysty kod”. Agent je ignoruje, ponieważ nie wynikają z nich konkretne działania. Dobra reguła jest mierzalna: „maksymalnie 150 linii”, „używaj Zod do walidacji”, „testuj z użyciem Testing Library”.

Pluginy, czyli integracje bez konfiguracji

Jeżeli konfiguracja MCP w pliku JSON wydaje się zbyt czasochłonna, dobra wiadomość jest taka, że niektóre popularne narzędzia udostępniają gotowe integracje w formie pluginów z wbudowanym MCP. Wystarczy połączyć je jednym kliknięciem, zalogować się do usługi i rozpocząć pracę. Agent uzyskuje dostęp bez konieczności pisania konfiguracji.

Na tym polega różnica między „MCP jako protokołem, który można samodzielnie podłączyć” a „pluginem jako gotowym pudełkiem”, które ukrywa pod spodem ten sam wcześniej skonfigurowany mechanizm.

Wewnątrz interfejsu Cursora

Krótki przegląd interfejsu pomaga zrozumieć, gdzie w praktyce znajdują się opisane elementy ekosystemu.

Pole czatu oferuje pięć trybów wybieranych z niewielkiej listy obok pola wpisywania:

• Agent: domyślny tryb pełnej autonomii. Odczytuje pliki, edytuje je, uruchamia polecenia terminalowe i powtarza działania, aż zadanie zostanie zakończone.
• Plan: tryb planowania tylko do odczytu. Rozbija zadanie na listę kroków przed modyfikacją pierwszego pliku, dzięki czemu można wcześniej zweryfikować podejście.
• Debug: tryb przeznaczony do wyszukiwania błędów. Analizuje ślad stosu lub nieudany test, aby znaleźć źródłową przyczynę problemu.
• Multitask: umożliwia równoległe wykonywanie kilku zadań bez oczekiwania na zakończenie każdego z nich.
• Ask: tryb pytań i odpowiedzi tylko do odczytu. Nie modyfikuje plików, dlatego dobrze sprawdza się podczas bezpiecznego poznawania nieznanego kodu.

Wskazówka: Duże lub ryzykowne zmiany rozpoczynaj w trybie Plan. Gotową listę kroków podziel na mniejsze grupy zamiast wdrażać wszystko naraz. Przegląd planu przed zmianą plików jest prostszy niż porządkowanie niedokończonego refaktoryzowania.

Panel kontekstu

Każda rozmowa ma określony budżet tokenów. Panel kontekstu pokazuje, na co jest on przeznaczany: prompt systemowy, definicje narzędzi, reguły, umiejętności, podłączone narzędzia MCP, subagenci oraz sama historia rozmowy.

W długiej rozmowie to właśnie historia wymiany wiadomości zwykle pochłania największą część budżetu. Gdy wskaźnik zbliża się do limitu, odpowiedzi mogą być wolniejsze, droższe i czasami mniej precyzyjne, ponieważ model musi przeszukać dużą ilość wcześniejszego kontekstu. Służy do tego komenda /summarize: kompresuje dotychczasową rozmowę do krótkiego podsumowania, zwalnia budżet i pozwala kontynuować pracę w tym samym wątku.

Bonus: nikt nie pytał, ale warto wiedzieć

Skoro już poruszamy temat rozszerzania agenta, warto wspomnieć o kilku kwestiach, które rzadko trafiają na pierwsze strony poradników, a mimo to znacznie ułatwiają codzienną pracę.

Wybór modelu to zarządzanie budżetem

Agent może samodzielnie wybrać najbardziej efektywny model do danego zadania albo użytkownik może wskazać mocniejszy model do trudniejszego problemu. Sposób rozliczania zależy od wyboru. Zwykły model premium, taki jak Opus 4.6, zazwyczaj jest liczony jako kilka standardowych zapytań, dlatego szybciej zużywa miesięczny limit. Max Mode zmienia model rozliczeń: zamiast stałej liczby zapytań koszt zależy od tokenów, więc rośnie wraz z ilością kontekstu wejściowego i wyjściowego.

W praktyce Max Mode z cięższym modelem i bardzo dużą bazą kodu może zużyć budżet znacznie szybciej niż to samo zadanie wykonane na zwykłym modelu. Rozsądna zasada: rutynowe zadania realizuj na ustawieniach domyślnych, a tryby droższe i rozliczane tokenowo stosuj dopiero wtedy, gdy zwykły model rzeczywiście sobie nie radzi.

Agent może „widzieć” ekran

Do czatu można wkleić zrzut błędu, widok konsoli przeglądarki albo obraz makiety z Figmy. Agent przeanalizuje obraz podobnie jak tekst. Czasami pokazanie problemu jest szybsze niż jego opisywanie.

Zewnętrzna dokumentacja też trafia do kontekstu

Można dodać link do dokumentacji biblioteki, a Cursor ją zindeksuje. Dzięki temu agent korzysta z aktualnego API, a nie wyłącznie z informacji zapamiętanych podczas treningu modelu, które mogą być opóźnione o kilka wersji.

Ciekawostka: Reguły i komendy napisane po angielsku zazwyczaj wykorzystują o około 30% mniej tokenów niż ich odpowiedniki po polsku. Przy większej skali może to stanowić realną różnicę kosztową, nawet jeśli rozmowa z agentem nadal odbywa się w języku ojczystym.

Zalety i wady, bez lukrowania

Żaden opis ekosystemu nie jest kompletny bez trzeźwego spojrzenia na obszary, w których rozwiązanie realnie pomaga, oraz te, w których należy zachować ostrożność.

Zalety

• Przewagę daje szybkość. Zadanie, które wcześniej wymagało przełączania się między pięcioma aplikacjami, można opisać w jednym poleceniu.
• Raz przygotowane reguły i komendy mogą służyć całemu zespołowi, jeżeli znajdują się w repozytorium.
• Integracje MCP skracają drogę od „mam zgłoszenie” do „mam gotowy kod produkcyjny zgodny z projektem”, zamiast generować ogólny szablon bez oparcia w kontekście.

Wady

• Agent mający jednocześnie dostęp do wielu narzędzi może wybrać niewłaściwe narzędzie lub wykonać działania w nieoczekiwanej kolejności, zwłaszcza gdy podłączono zbyt wiele serwerów.
• Źle napisane reguły, zbyt długie, nieprecyzyjne lub niepodzielone według typów plików zanieczyszczają kontekst i zwiększają koszt każdej rozmowy bez realnej korzyści.
• Automatyzacja nie eliminuje potrzeby przeglądu. Agent może samodzielnie wykonać wiele kroków, ale odpowiedzialność za to, co trafia na produkcję, nadal spoczywa na użytkowniku.

Digital

Zwiększ zysk i poszerzaj grono zadowolonych klientów dzięki naszym usługom inżynierii oprogramowania, e-commerce, mobile i digital customer experience.

Oferta Digital

Podsumowanie i konfiguracja na pierwszy tydzień

Na papierze ten ekosystem może wyglądać na bardziej skomplikowany niż jest w codziennej pracy.

Jeżeli zaczynasz od zera, rozsądna kolejność wygląda następująco:

1. Jedna krótka reguła „zawsze aktywna” zawierająca podstawy stosu technologicznego, maksymalnie kilkanaście linii.
2. Jedna lub dwie reguły przypisane do konkretnych typów plików, np. komponentów lub testów.
3. Jeden serwer MCP, którego używasz codziennie, zazwyczaj związany z kontrolą wersji.
4. Jedna komenda do najbardziej powtarzalnego działania, np. przeglądu kodu lub generowania testów.
5. Pozostałe elementy dodawane stopniowo, dokładnie wtedy, gdy zauważysz, że agent ponownie popełnia ten sam błąd albo po raz trzeci przepisujesz to samo polecenie.

Trend jest dość wyraźny: mniej „programista pisze każdą linię”, więcej „programista projektuje system reguł i integracji, a agent go wykonuje”. Nie oznacza to końca zawodu. To przesunięcie akcentu z pisania na projektowanie i nadzorowanie. Biorąc pod uwagę tempo rozwoju tego ekosystemu, osoby, które już dziś nauczą się świadomie nim sterować, zyskają wyraźną przewagę, gdy rozwiązanie stanie się standardem, a nie ciekawostką.

Ciekawostka: Raport rynku pracy IT z przełomu 2025 i 2026 roku wskazywał, że 75% firm traktuje kompetencje AI/ML jako kluczowe w rekrutacji, a architekci IT byli jedyną specjalizacją, w której mediana stawek B2B na poziomie seniora przekroczyła 30 000 PLN netto. AI nie odbiera pracy programistom. Podnosi próg wejścia do zawodu.