Wdrażanie nowych funkcji Cursora

Bezpieczne wdrożenie nowej funkcji Cursora polega na ocenie jej zasięgu (tylko twoja sesja, całe repozytorium, praca bez nadzoru albo code review i wydania), przetestowaniu jej w odizolowanym worktree na niedawno scalonych zadaniach, ocenie wyniku po bramkach CI i poprawkach zamiast po wrażeniach, a dopiero potem zapisaniu konfiguracji w repozytorium, skąd dostaje ją cały zespół.

Ta strona jest dla dewelopera, który czyta changelog Cursora, i dla tech leada, który decyduje, co zespół włącza. Znany scenariusz: ktoś w piątek włącza nową funkcję agenta, w poniedziałek agent przepisuje pół modułu, nikt nie umie powiedzieć, czy to pomogło, a w środę trzech inżynierów pracuje na trzech różnych konfiguracjach Cursora. Rozwiązaniem jest krótki, powtarzalny test z dowodami, dopasowany do ryzyka funkcji.

Co sprawdziliśmy i kiedy

Nazwy funkcji w pierwszej tabeli poniżej pochodzą z dokumentacji Cursora przeczytanej 2026-08-28 i zapisanej w notatkach badawczych tego serwisu. 2026-09-26 nie dało się ponownie odczytać strony Cursora; 2026-10-12 się dało, a sprawdzenie z tego dnia obejmuje funkcje z drugiej tabeli oraz starsze nazwy z datą 2026-10-12 w tabeli zmienionych nazw. Dostępność w planach zapisujemy tak, jak podają ją wpisy Cursora, więc przed testem funkcji potwierdź ją w dokumentacji Cursora. Opisane niżej funkcje należą do linii Cursor 3.x. Cursor numeruje wydania desktopowe w swoich notatkach o wydaniach, a bieżące wydanie to 3.24 (2026-10-09, sprawdzone 2026-10-12).

Co zyskasz, wdrażając funkcje Cursora w ten sposób

• Czteropoziomową tabelę zasięgu, która mówi, kto decyduje i jak długo trwa test każdej funkcji Cursora.
• Siedmiokrokowy test jednej funkcji, który zamkniesz w około dwa tygodnie, razem z dowodami, które go rozstrzygają.
• Trzy prompty do wklejenia: przegląd wpisu z changelogu, projekt testu i zamiana sprawdzonego nawyku we wspólną konfigurację repozytorium.
• Procedurę migracji dla funkcji o zmienionej nazwie lub wycofanych oraz kroki naprawcze, gdy wdrożenie idzie źle.

Które funkcje Cursora warto przetestować?

Zacznij od tego, co zmienia twoją pracę, a nie od tego, co najnowsze. Tabela grupuje funkcje Cursora, których nazwy zweryfikowaliśmy 2026-08-28, według miejsca działania. Datowaną listę zmian znajdziesz w changelogu Cursora w tym serwisie albo w changelogu Cursora.

Gdzie działa funkcja	Funkcje Cursora	Co zmienia dla ciebie
Tylko twoja sesja	Plan Mode, Worktrees, Subagents, /loop (wbudowany skill od 3.5), /goal (ogłoszony 2026-08-19; wciąż wdrażany stopniowo według dokumentacji Cursora, sprawdzone 2026-10-12)	Jak jeden agent planuje, dzieli i powtarza pracę na twoim komputerze
Repozytorium, dla wszystkich	Rules, Agent Skills, Hooks, Plugins, serwery MCP	Jakie instrukcje dostaje, co może uruchomić i do czego ma dostęp agent każdego członka zespołu
Bez nadzoru, w chmurze	Cloud Agents, Builds, Automations, Cloud Agents API, Cursor SDK (@cursor/sdk, cursor-sdk), tryb print w CLI (-p)	Praca, która startuje bez ciebie: według harmonogramu, z GitHuba, GitLaba, Slacka, Lineara, Sentry, PagerDuty albo z webhooka
Code review i wydania	Bugbot, Security Agents, PR Routing & Approval, Origin	Kto recenzuje pull request, czy bot może go zatwierdzić i gdzie żyją kod oraz pull requesty (Origin)

Funkcje z następnej tabeli Cursor dodał w dniu 2026-08-19 lub później, a każdą przeczytaliśmy w changelogu albo dokumentacji Cursora 2026-10-12. Obowiązują dla nich te same poziomy.

Gdzie działa funkcja	Funkcja Cursora dodana od 2026-08-19	Co zmienia dla ciebie
Tylko twoja sesja	Skille jako Custom Modes (dokumentacja Cursora i changelog z 2026-08-19): „Any skill with a valid frontmatter block can back a Custom Mode, which keeps the skill in context for the whole session”	Jak długo jeden skill zostaje w kontekście: przez całą sesję
Tylko twoja sesja	Remote control dla lokalnych agentów (changelog, 2026-10-06): „You can now see and reply to the local agents running on your computer from the Cursor iOS app.” Funkcja jest domyślnie włączona, z wyjątkiem organizacji Enterprise, w których włączają ją administratorzy. Cursor na iOS jest w planach Start, Pro, Pro+, Ultra, Teams i Enterprise	Skąd możesz obserwować działającego agenta i mu odpowiadać. Skoro jest domyślnie włączona, sprawdź, czy ktoś w twoim zespole już z niej korzysta
Bez nadzoru, w chmurze	Start from scratch (changelog, 2026-08-27): „Cloud Agents no longer require a connected GitHub or other third-party SCM provider to get started.” Start from scratch w wyborze repozytorium tworzy repozytorium Origin, a według dokumentacji Origin Cursora Origin jest „currently released in early beta”	Cloud Agent może wystartować bez repozytorium hostowanego gdzie indziej. Testuj to na jednorazowym projekcie, dopóki Origin jest w becie
Bez nadzoru, w chmurze	Self-hosted machines (changelog, 2026-09-02): „keep tool execution entirely in your own network” przez My Machines (jeden laptop albo VM) lub Team pools (nazwane kolejki workerów, które się skalują i mogą hibernować bezczynne maszyny). Workery startują poleceniem agent worker	Gdzie działają narzędzia agenta bez nadzoru: w twojej sieci
Bez nadzoru, w chmurze	Cursor Projects (beta) (changelog, 2026-09-10): projekt obejmuje „a feature, a migration, or a full app”. Jego agent koordynujący „doesn’t write code itself” i działa „on its own computer in the cloud”. Dostępny w każdym płatnym planie, także Enterprise (Enterprise wymaga Cursora 3.21.9 lub nowszego), niedostępny w Hobby i z Privacy Mode (Legacy)	Długotrwała praca, która zachowuje kontekst przez miesiące. Traktuj to jako poziom 3 i testuj na jednym repozytorium niskiego ryzyka
Code review i wydania	Rollouts i Security Review (changelog, 2026-09-23), oba w planach Teams i Enterprise. Rollouts podpina monitor do każdego pull requesta i raportuje każde środowisko jako „verified healthy, regression detected, or inconclusive”; „does not merge or roll back on its own today”. Security Review dodaje jeden komentarz do pull requesta o błędach, które da się wykorzystać, i pomija pull requesty w wersji roboczej (draft)	Co komentuje twoje pull requesty i co je monitoruje. Traktuj oba jako poziom 4, najpierw z okresem obserwacji

Dwie definicje z dokumentacji Cursora decydują o ocenie ryzyka. Plugins pakują reguły, skille, agentów, komendy, serwery MCP i hooki w dystrybuowalne paczki, więc jeden plugin może zmienić naraz wszystkie cztery warstwy poziomu repozytorium. PR Routing & Approval może zatwierdzać pull requesty niskiego ryzyka, gdy spełnione są twoje kryteria, więc przenosi decyzję o scaleniu z człowieka na regułę, którą piszesz.

Oceń zasięg każdej funkcji Cursora

Poziom decyduje, kto zatwierdza, jak długo trwa test i jaki dowód wystarcza. Wyższy poziom nigdy nie pomija kroków niższego.

Poziom	Przykład	Kto decyduje	Test	Dowód przed udostępnieniem zespołowi
1. Osobisty	Plan Mode na trzech najbliższych zadaniach	Ty	Kilka dni	Twoje pull requesty przechodzą te same bramki CI bez dodatkowych rund review
2. Repozytorium	Hook, który uruchamia sprawdzanie typów po edycjach agenta	Tech lead, przez CODEOWNERS na .cursor/	Do dwóch tygodni	Powtórzenie od pięciu do ośmiu scalonych zadań; bramki i poprawki nie gorsze
3. Bez nadzoru	Automation według harmonogramu, która podbija zależności	Tech lead i właściciel repozytorium	Dwa tygodnie na jednym repozytorium niskiego ryzyka	Każde uruchomienie zostawia pull request, który przechodzi CI; żadne nie pisze poza swoją gałęzią
4. Code review i wydania	PR Routing & Approval automatycznie zatwierdza zmiany tylko w dokumentacji	Tech lead i właściciel ryzyka produkcyjnego (często zespół bezpieczeństwa)	Najpierw okres obserwacji: spisz kryteria zatwierdzania, ale nie włączaj automatycznego zatwierdzania, żeby bot tylko przypisywał recenzentów; przy każdym pull requeście zapisz, czy kryteria by pasowały, i porównaj to z werdyktem człowieka	Tam, gdzie kryteria by pasowały, człowiek zatwierdził każdy pull request z okresu obserwacji

Na każdym poziomie testuj jedną funkcję naraz. Dwie funkcje testowane razem dają jeden wynik, którego nie przypiszesz żadnej z nich.

Przeprowadź test funkcji Cursora w siedmiu krokach

Test zastępuje „wydawało mi się szybciej” wynikiem, który każdy w zespole może sprawdzić ponownie. Zespołowy dyżur śledzenia wydań, który dostarcza kandydatów do testów, opisuje strona o nadążaniu zespołu za narzędziami wydawanymi co tydzień; ta sekcja to jego część specyficzna dla Cursora.

1. Przeczytaj źródło. Otwórz wpis w changelogu i stronę funkcji w dokumentacji. Zapisz wersję Cursora, której używasz, plan wymagany przez funkcję oraz to, czy dokumentacja mówi „beta” albo „rolling out”.

2. Przejrzyj wpis z agentem. Wklej go do czatu agenta razem z pierwszym promptem poniżej. Odrzuć wszystko, co nie dotyka żadnego przepływu pracy, którego używasz w tym miesiącu.

3. Zapisz hipotezę i ewaluację przed startem. Jedno zdanie: „Plan Mode zmniejsza liczbę rund review przy zadaniach API”. Potem wybierz od pięciu do ośmiu scalonych zadań z tego przepływu, o których sukcesie rozstrzygają testy. Drugi prompt poniżej przygotuje jedno i drugie.

4. Odizoluj test. Na poziomach 1 i 2 użyj worktree w Cursorze albo gałęzi. Na poziomie 3 skieruj Automation lub Cloud Agent na jedno repozytorium niskiego ryzyka. Przy MCP zacznij od serwera tylko do odczytu, takiego jak Context7 (niżej), zanim dodasz serwer, który może zapisywać.

5. Powtórz zadania. Daj agentowi oryginalny opis każdego zadania, a nie scalony diff. Nie zmieniaj modelu ani zwykłego trybu uruchamiania, żeby jedyną zmienną była testowana funkcja.

6. Oceniaj po bramkach. Porównaj wynik ze scalonymi oryginałami na podstawie dowodów z następnej sekcji. Czytasz porażki i próbkę, a nie każdą linię.

7. Zdecyduj i zapisz. Wdróż, odrzuć albo przedłuż test o tydzień. Zapisz decyzję, wymaganą wersję i jednolinijkowy rollback w pull requeście, który zmienia wspólną konfigurację. Format rekordu decyzji ze strony o śledzeniu wydań działa dla Cursora bez zmian.

Prompt do wklejenia: przegląd wpisu z changelogu Cursora

Here is a Cursor changelog entry and the docs page it links to:
<paste both>

Read this repository first: package.json, the CI workflow files, and
everything under .cursor/. Then, for each feature in the entry:
1. Say which workflow in THIS repository it would change, citing the file
   or script that runs that workflow today. If none, mark it "noise".
2. Put it in one tier: personal, repository, unattended, or review-and-release.
3. Name the plan or setting it needs, quoting the docs. If the docs do not
   say, write "not stated" instead of guessing.
4. Propose one first test on a branch that cannot affect main or CI.
Output a table. Do not enable, install or configure anything.

Prompt do wklejenia: projekt testu i ewaluacji

I want to trial Cursor's Plan Mode for API endpoint tickets in this repo.
Use git log for the last 90 days to find 5 to 8 merged pull requests that
added or changed an endpoint under src/pages/api/ and came with tests.

For each one, give: the PR number, the original task description (from the
PR body or the linked issue), and the test files that decide success.
Then write:
- a one-sentence falsifiable hypothesis;
- what counts as better, same and worse, using only CI results, number of
  review rounds, and follow-up fix commits within 14 days of merge;
- the exact files the trial may change, confirming none are shared config.
Do not start implementing anything.

Zamień Plan Mode i src/pages/api/ na funkcję i katalog, które testujesz; reszta promptu zostaje bez zmian.

Dodaj serwer MCP jako test poziomu 2

Serwer MCP w konfiguracji projektu trafia do agenta każdego członka zespołu, więc traktuj go jak zmianę w repozytorium. Zacznij od serwera dokumentacji tylko do odczytu. README Context7 podaje taką konfigurację Cursora dla zdalnego serwera (nagłówek z kluczem API jest opcjonalny i tylko podnosi limity):

{
  "mcpServers": {
    "context7": {
      "url": "https://mcp.context7.com/mcp"
    }
  }
}

Dopiero gdy ten test przejdzie, dodawaj serwery, które działają, na przykład Playwright MCP, i każdemu dawaj najwęższy potrzebny zakres. README Playwrighta podaje taki wpis do pliku konfiguracji MCP projektu (jego lokalizację podaje przewodnik po konfiguracji MCP, do którego link jest niżej):

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

Przewodnik po konfiguracji MCP w Cursorze opisuje lokalizacje plików i uwierzytelnianie, a katalog MCP porównuje serwery.

Jak udowodnić, że funkcja Cursora pomogła, bez czytania każdego diffu?

Powtórzone zadania oceniasz po sygnałach, które już istnieją w CI i w Gicie, więc werdykt nie zależy od tego, czy ktoś przeczyta każdą linię napisaną przez agenta.

Sygnał	Skąd pochodzi	Kiedy wynik jest gorszy
Bramki przy pierwszym pushu	CI: testy, sprawdzanie typów, lint	Więcej czerwonych przebiegów niż przy scalonych oryginałach
Rundy review	Historia pull requestu	Więcej rund „changes requested”
Poprawki	Commity z poprawką lub revertem w ciągu 14 dni	Każdy revert, którego oryginał nie potrzebował
Zakres	git diff --stat względem oryginału	Pliki zmienione poza obszarem zadania
Zużycie	Dane o zużyciu Cursora z okresu testu (zobacz zarządzanie tokenami w Cursorze)	Wzrost, którego nie uzasadnia zaoszczędzony czas

Dwie rzeczy czytasz ręcznie: każdą nieudaną bramkę i jedno losowo wybrane zadanie, które przeszło. Jeśli to losowe cię zaskoczy, bramki są słabsze, niż myślałeś, i to jest pierwsze znalezisko do naprawy. Przewodnik o dowodach zamiast diffów wyjaśnia, jak budować bramki, którym można tak zaufać.

Przy funkcjach z poziomów 3 i 4 dowodem są już nie zadania, lecz uruchomienia. Automation lub Cloud Agent musi zostawić pull request, który przechodzi te same wymagane sprawdzenia co pull request człowieka. Bot recenzujący zaczyna od okresu obserwacji: spisujesz jego kryteria zatwierdzania, ale nie włączasz automatycznego zatwierdzania, więc bot tylko przypisuje recenzentów. Przy każdym pull requeście zapisujesz, czy kryteria by pasowały, i porównujesz to z werdyktem człowieka, zanim pozwolisz botowi cokolwiek zatwierdzić. Oba przypadki szczegółowo opisują przewodnik po stopniowych wdrożeniach i zatwierdzaniu PR oraz przewodnik po Bugbocie.

Przenieś sprawdzoną funkcję do repozytorium

Funkcja jest wdrożona, gdy nowa osoba w zespole dostaje ją, klonując repozytorium, a nie wtedy, gdy jedna osoba ma ją włączoną. Rules, Agent Skills, Hooks, Plugins i konfiguracja MCP w Cursorze mogą żyć w systemie kontroli wersji, więc przeniesienie funkcji do zespołu to po prostu pull request.

1. Zacommituj konfigurację w .cursor/ i we wszystkich innych ścieżkach z konfiguracją agentów, których używa repozytorium, na przykład we wspólnym folderze skilli. Formaty pokazują przewodnik po regułach projektu i przewodnik po regułach i szablonach; wspólne skille opisuje strona o instalowaniu i zarządzaniu skillami.

2. Przypisz te ścieżki tech leadowi, żeby nikt nie zmieniał zachowania wszystkich agentów bez review. Dodaj wiersz dla każdej ścieżki z konfiguracją agentów w repozytorium, nie tylko dla .cursor/:

   # .github/CODEOWNERS
   /.cursor/  @your-org/tech-leads
   # po jednym wierszu na każdą inną ścieżkę z konfiguracją agentów, na przykład wspólny folder skilli

3. W opisie pull requestu podaj wymaganą wersję i rollback, na przykład „wymaga buildu Cursora z dostępnym /goal; rollback: revert tego pull requestu”.

4. Pokaż funkcję raz na najbliższej sesji review zespołu. Funkcja, której umie używać tylko jedna osoba, nie została wdrożona.

5. Ustal datę przeglądu za 90 dni i wtedy zachowaj, zmień albo usuń funkcję.

Prompt do wklejenia: zamiana nawyku we wspólną konfigurację

For the last two weeks I have started every API ticket by asking you to:
read the route's existing tests, list the edge cases, write failing tests,
then implement until the tests, type check and lint pass.

Turn this into shared repository configuration for Cursor:
1. Decide whether it belongs in a project rule, an Agent Skill, or a hook,
   and explain the choice in two sentences. Quote Cursor's docs for the
   file location; if you cannot, say so instead of inventing a path.
2. Write the file contents.
3. Write the pull request description: what it changes for every
   teammate's agent, how to verify it on one ticket, and a one-line rollback.
Do not modify CI, permissions or anything outside .cursor/.

Gdy zespół wyrasta z jednego repozytorium, plugin Cursora może spakować te same reguły, skille, hooki i serwery MCP dla wielu repozytoriów. Przegląd pluginów porównuje to podejście z konfiguracją per repozytorium.

Gdy wdrażanie funkcji Cursora idzie źle

Większość porażek to porażki procesu: za dużo funkcji naraz, konfiguracja poza repozytorium albo funkcja, która zmieniła się pod tobą.

Trzy funkcje włączone naraz, brak jasnego wyniku. Naprawa: wyłącz wszystkie trzy, zostaw funkcję poziomu 1 z najmocniejszą hipotezą i zacznij jej test od nowa. Pozostałe ustaw w kolejce.

Funkcja zmieniła nazwę albo zniknęła. Stare notatki i artykuły wciąż używają wycofanych nazw. Zmapuj je, zanim zmienisz konfigurację:

Starsza nazwa	Obecna nazwa w dokumentacji Cursora (data sprawdzenia)
Background Agents	Cloud Agents (sprawdzone 2026-10-12; pomoc Cursora: „In Cursor, we call these Cloud Agents”)
BugBot	Bugbot (sprawdzone 2026-08-28)
YOLO mode, Auto-Run	Run modes: Auto-review, Allowlist i Run Everything, w Settings > Agents > Approvals & Execution (sprawdzone 2026-10-12)
Ask Every Time, Run in Sandbox	Allowlist: w Cursorze 3.5 wycofano Ask Every Time (to samo zachowanie daje Allowlist z pustą listą), a Run in Sandbox włączono do Allowlist z włączonym sandboxem (sprawdzone 2026-10-12)
.cursorrules jako sposób konfiguracji Cursora	Rules: reguły projektu w .cursor/rules jako pliki .mdc albo AGENTS.md w katalogu głównym projektu i w podkatalogach (sprawdzone 2026-10-12). Pomoc Cursora: „The .cursorrules file in your project root is legacy and will be deprecated”

Potem przeszukaj repozytorium i dokumentację zespołu pod kątem starych nazw (rg -i "background agent|yolo|cursorrules|ask every time|run in sandbox") i popraw każde trafienie w jednym pull requeście.

Rozjazd konfiguracji między członkami zespołu. Objaw: „u mnie w Cursorze działa”. Naprawa: porównaj ustawienia użytkownika każdej osoby z tym, co jest w .cursor/, przenieś do repozytorium wszystko, od czego zależy zespół, i usuń prywatne kopie.

Uruchomienie bez nadzoru zadziałało na niezaufanych danych. Automations mogą startować z wiadomości na Slacku, webhooków i systemów zgłoszeń, do których może pisać każdy z dostępem. Naprawa: wstrzymaj Automation, przejrzyj każdy pull request, który otworzyła, i zawęź jej wyzwalacz do źródeł, do których pisze tylko twój zespół. Potem upewnij się, że ochrona gałęzi wymaga review wszystkiego, co otwiera. Nigdy nie dawaj agentowi bez nadzoru sekretu, którego nie potrzebuje do tego jednego zadania.

Bot recenzujący zatwierdził coś, czego nie powinien. Naprawa: wyłącz automatyczne zatwierdzanie, tak by tylko przypisywał recenzentów, a zatwierdzał nadal człowiek, powtórz okres obserwacji (zapisuj, czy kryteria pasowałyby do każdego pull requestu, i porównuj to z werdyktem człowieka), a gdy ponownie włączysz zatwierdzanie, ogranicz jego kryteria do ścieżek z mocnymi testami (na przykład zmian tylko w dokumentacji).

Zużycie wzrosło i nikt nie wie dlaczego. Cloud Agents i Automations działają, gdy nie patrzysz. Naprawa: porównaj dane o zużyciu z okresu testu z poprzednim okresem, ogranicz harmonogram i zajrzyj do strony o zarządzaniu tokenami w Cursorze.

Uwaga

Nie testuj nowego trybu uruchamiania, ustawienia sandboxa ani zmiany uprawnień na komputerze lub w repozytorium z produkcyjnymi danymi uwierzytelniającymi. Użyj jednorazowego worktree albo repozytorium testowego i po zakończeniu testu wróć do zwykłych ustawień.

Dokąd dalej z funkcjami Cursora

Changelog Cursora Datowana lista zmian do wklejenia w prompt przeglądu

Przewodniki po aktualizacjach Cursora Bezpieczna aktualizacja samego Cursora i rollback, gdy aktualizacja psuje MCP lub rozszerzenia

Co Claude Code potrafi, a czego jeszcze nie próbowałeś To samo pytanie o wdrażanie funkcji dla zespołów, które używają też Claude Code

Jak zespół ma nadążać za narzędziami Międzynarzędziowy dyżur śledzenia wydań i rekord decyzji, na których opiera się ten test

Cloud Agents i Automations Konfiguracja funkcji poziomu 3 z zabezpieczeniami, których wymaga ta strona

Frameworki metryk Zamień sygnały z testów w metryki zespołu, które obronią się na poziomie organizacji