Współpraca zespołowa w Cursorze

Współpraca zespołowa w Cursorze działa wtedy, gdy konfiguracja agenta mieszka w repozytorium, a nie na każdym laptopie osobno: reguły projektu w .cursor/rules/, serwery MCP w .cursor/mcp.json, a powtarzalne procedury jako skille. Każdy klon uruchamia wtedy tego samego agenta, a CI i Bugbot sprawdzają wynik, zanim poświęci mu czas człowiek.

Ta strona jest dla tech leada, który odpowiada za zespół od pięciu do 20 osób pracujących w Cursorze, i dla dewelopera, który przygotowuje wspólne pliki. Ośmiu inżynierów używa Cursora, a pull requesty wyglądają jak osiem różnych codebase’ów. Endpointy wygenerowane u jednej osoby walidują wejście i logują błędy, u drugiej połykają wyjątki, a trzecia dostaje domyślne eksporty, bo tak mówi jej osobista reguła. Code review zwalnia, bo każdy recenzent w komentarzach uczy od nowa tych samych konwencji.

Co daje zespołowi wspólna konfiguracja Cursora

• Podział na warstwy: co trafia do repozytorium, co ustawia się na poziomie zespołu, a co zostaje prywatne
• Startowy zestaw plików .cursor/rules/ i prompt, który dowodzi, że agent faktycznie je ładuje
• Zacommitowany .cursor/mcp.json, w którym lista serwerów jest wspólna, a tokeny zostają prywatne
• Procedury zespołu spakowane jako skille, które każdy wywołuje pod tą samą nazwą
• Bramkę przed code review (CI, Bugbot i samokontrola agenta), dzięki której człowiek ocenia intencję i projekt
• Checklistę onboardingu na jedno popołudnie oraz listę awarii z krokami naprawy

Jeśli zespół używa więcej niż jednego agenta, zacznij od wersji międzynarzędziowej: wspólny kontekst i reguły dla Cursora, Claude Code i Codexa. Ta strona opisuje wyłącznie stronę Cursora.

Co trafia do repozytorium, a co zostaje prywatne?

Zdecyduj o warstwie, zanim napiszesz pierwszą regułę. Najczęstsze źródło problemu „u mnie agent zachowuje się inaczej” to konwencja, która żyje w ustawieniach jednej osoby.

Warstwa	Gdzie mieszka	Jak jest współdzielona	Właściciel	Co tu umieścić
Reguły projektu	.cursor/rules/*.mdc	git, przegląd w pull requestach	zespół, przez code review	stack, granice architektury, obsługa błędów, konwencje testów
Serwery MCP	.cursor/mcp.json	git; tokeny każdy podaje sam	tech lead	narzędzia potrzebne w każdym zadaniu: GitHub, deweloperska baza danych
Skille	.cursor/skills/<nazwa>/SKILL.md	git	właściciel danej procedury	procedury wieloetapowe: nowy endpoint, kontrola przed PR, release notes
Reguły zespołowe	panel Cursora (plany biznesowe; potwierdź w cenniku Cursora)	Cursor stosuje je do członków zespołu	administrator	polityka całej organizacji, która nie może zależeć od repozytorium
Ustawienia osobiste	ustawienia Cursora każdej osoby i ~/.cursor/	niewspółdzielone	deweloper	preferencje edytora, prywatne serwery MCP, nic, co zmienia kształt kodu

Zasada praktyczna: jeśli dwie osoby pokłóciłyby się o coś w code review, to miejsce tego czegoś jest w zacommitowanym pliku, gdzie spór rozstrzyga się raz, w pull requeście.

Zacommituj reguły projektu, które ładuje cały zespół

Reguły projektu to pliki .mdc w .cursor/rules/, według strony o regułach Cursora, której 26 września 2026 nie mogliśmy ponownie pobrać; prompt listujący reguły poniżej potwierdza, co faktycznie się ładuje. Każdy zaczyna się od frontmattera, który mówi Cursorowi, kiedy go załadować: alwaysApply: true przy każdym zapytaniu, globs dla pasujących plików albo description, na podstawie którego agent sam decyduje. Reguły stosowane zawsze trzymaj krótkie, bo kosztują kontekst w każdej wiadomości.

1. Utwórz katalog w głównym katalogu repozytorium:

   mkdir -p .cursor/rules

2. Utwórz .cursor/rules/project-standards.mdc, jedyną regułę stosowaną zawsze:

   ---
   description: Core stack, boundaries and non-negotiables for this repository
   alwaysApply: true
   ---
   
   Stack: TypeScript (strict), Node 22, Fastify, PostgreSQL via Drizzle, Vitest.
   
   - No `any`. If a type is genuinely unknown, use `unknown` and narrow it.
   - Errors: throw `AppError` from src/lib/errors.ts; never return raw exceptions to clients.
   - Logging: use `logger` from src/lib/logger.ts; never `console.log`.
   - Named exports only.
   - Before creating a new file, find the closest existing example and follow it.
     API routes: src/routes/users.ts. Services: src/services/user.ts.
   - A task is done only when `pnpm typecheck`, `pnpm lint` and `pnpm test` pass.

3. Dodaj reguły o zawężonym zakresie dla tych części kodu, które mają własne konwencje. Na przykład .cursor/rules/api-layer.mdc:

   ---
   description: HTTP layer conventions for route handlers
   globs: src/routes/**/*.ts
   alwaysApply: false
   ---
   
   - Route handlers parse, validate (zod) and format responses. No business logic.
   - Business logic lives in src/services/. Services never import from src/routes/.
   - Database access goes through src/repositories/. No raw SQL in services.
   - Every new route gets a test in the matching src/routes/__tests__/ file,
     covering one success case and at least one validation failure.

4. Zacommituj reguły i przeglądaj je tak jak kod:

   git add .cursor/rules/
   git commit -m "Add shared Cursor project rules"

Używaj rozszerzenia .mdc i frontmattera jak powyżej. Plik reguły ze złym rozszerzeniem albo zepsutym frontmatterem wciąż leży w drzewie plików i wygląda poprawnie, dlatego kolejny krok jest obowiązkowy. Pełną składnię reguł i więcej szablonów znajdziesz na stronach reguły projektu w Cursorze oraz własne reguły i szablony.

Udowodnij, że reguły się ładują, zanim im zaufasz

Reguła, której agent nigdy nie widzi, i tak wygląda dobrze w drzewie plików. Uruchom ten test raz po dodaniu reguł i poproś każdą nową osobę w zespole, żeby zrobiła to pierwszego dnia:

Prompt do skopiowania: sprawdź, które reguły działają

Without changing any files: list every rule from .cursor/rules/ that is
active in this conversation, with its file name. Then tell me which rules
would apply if you edited src/routes/users.ts, and quote the one line from
each that most constrains that edit. If a rule file exists in
.cursor/rules/ but is not active, name it and say why you think it is not
loading.

Odpowiedź da się sprawdzić bez czytania kodu: nazwy plików albo zgadzają się z zawartością katalogu, albo nie. Brak reguły o zawężonym zakresie zwykle oznacza zły wzorzec globs albo złe rozszerzenie pliku.

Dodaj reguły zespołowe w panelu Cursora

W planach biznesowych Cursora administrator może też zdefiniować w panelu Cursora reguły, które obowiązują członków zespołu we wszystkich repozytoriach. @cursor/sdk 1.0.32 wymienia team jako źródło ustawień obok project, user, mdm i plugins, co jest spójne z istnieniem warstwy zespołowej.

Warstwę zespołową rezerwuj na krótką listę zasad, które nie mogą różnić się między repozytoriami: żadnych produkcyjnych danych dostępowych w promptach, żadnego wygenerowanego kodu wyłączającego kontrolę uwierzytelnienia, polityka licencji dla nowych zależności. Wszystko, co dotyczy jednego codebase’u, zostaw w regułach projektu, gdzie jest wersjonowane obok kodu, który opisuje.

Sprawdź pierwszeństwo w dokumentacji Cursora

To, która warstwa wygrywa przy konflikcie reguły zespołowej z regułą projektu, oraz to, czy administrator może zablokować wyłączanie reguły zespołowej, opisuje strona o regułach w dokumentacji Cursora. 26 września 2026 nie mogliśmy ponownie pobrać tej strony, więc zanim oprzesz na tym mechanizm zgodności, potwierdź tam obecne zachowanie. To samo dotyczy planów, które obejmują reguły w panelu: opisujemy je jako funkcję planów Teams i Enterprise, ale zanim zaplanujesz na nie budżet, potwierdź nazwy planów na stronie z cennikiem Cursora. Prompt listujący reguły i tak pokazuje, które reguły faktycznie docierają do agenta.

Politykę bezpieczeństwa pasującą do tej warstwy opisuje strona prywatność i bezpieczeństwo w Cursorze.

Współdziel serwery MCP bez współdzielenia tokenów

Zacommituj .cursor/mcp.json, żeby agent każdej osoby miał te same narzędzia, a każdy token trzymaj w środowisku jego właściciela. Plik poniżej używa hostowanego serwera MCP GitHuba i Postgres MCP Pro w trybie tylko do odczytu na bazie deweloperskiej:

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": { "Authorization": "Bearer ${env:GITHUB_PAT}" }
    },
    "postgres": {
      "command": "uvx",
      "args": ["postgres-mcp", "--access-mode=restricted"],
      "env": { "DATABASE_URI": "${env:DEV_DATABASE_URI}" }
    }
  }
}

• GitHub działa jako zdalny serwer pod https://api.githubcopilot.com/mcp/, utrzymywany w github/github-mcp-server. Jeśli domyślnie zespół ma mieć tylko odczyt, użyj https://api.githubcopilot.com/mcp/readonly.
• Postgres MCP Pro to pakiet PyPI postgres-mcp (0.3.0, sprawdzone 26 września 2026), uruchamiany przez uvx. --access-mode=restricted oznacza transakcje tylko do odczytu z limitami czasu. Nie używaj npx postgres-mcp: pakiet npm o tej nazwie to coś zupełnie innego.
• Tokeny pochodzą ze środowiska każdej osoby dzięki interpolacji ${env:NAZWA} (za dokumentacją MCP Cursora, której 26 września 2026 nie mogliśmy ponownie pobrać). Wymagane zmienne wypisz w CONTRIBUTING.md, żeby onboarding wiedział, co ustawić.

Starsze pakiety @modelcontextprotocol/server-github i @modelcontextprotocol/server-postgres są oznaczone jako deprecated i zarchiwizowane; zastąp każdy wpis, który jeszcze ich używa. Szczegóły poszczególnych serwerów: konfiguracja MCP w Cursorze, serwer MCP GitHuba i serwery MCP dla baz danych.

Spakuj procedury zespołu jako skille

Prompt, który trzy osoby wklejają ze Slacka, szybko rozjeżdża się w trzy różne prompty. Procedury, które wykonują wszyscy, zapisz jako skille w .cursor/skills/ (ścieżka według strony o skillach Cursora, której 26 września 2026 nie mogliśmy ponownie pobrać), żeby agent mógł z nich korzystać, a każda osoba uruchamiała tę samą procedurę. Skill to katalog z plikiem SKILL.md, którego frontmatter nadaje mu nazwę i mówi, kiedy go użyć.

Utwórz .cursor/skills/pre-pr-check/SKILL.md:

---
name: pre-pr-check
description: Run before opening a pull request. Runs the gates, fixes failures without weakening tests, and reports what changed.
---

1. Run `pnpm typecheck`, `pnpm lint` and `pnpm test`. Fix every failure.
   Never edit an existing test assertion to make it pass; if you believe a
   test is wrong, stop and say so.
2. Search the diff against main for `console.log`, `TODO`, hardcoded URLs,
   and anything that looks like a key or password. Remove or report each one.
3. Check every new import against package.json. Report any package that is
   not a declared dependency.
4. For each new function with branching logic, confirm a test covers at
   least one failure path. List the ones that do not.
5. Finish with a table: gate, result, what you changed.

Są jeszcze trzy miejsca, w których może żyć procedura zespołu, i każde ma swoje zastosowanie:

• .cursor/commands/ wciąż przechowuje komendy slash w wielu repozytoriach; narzędzia takie jak OpenSpec 1.13.2 zapisują zarówno .cursor/commands/, jak i .cursor/skills/. Nowe procedury pisz raczej jako skille: format SKILL.md jest wspólny z Claude Code i Codexem, choć każde narzędzie czyta własny katalog. Zespoły korzystające z kilku agentów trzymają jedną kopię i ją linkują; zobacz wspólne skille.
• Pluginy według dokumentacji Cursora (sprawdzonej 28 sierpnia 2026) pakują reguły, skille, agentów, komendy, serwery MCP i hooki w dystrybuowalne paczki. Sięgnij po plugin, gdy ta sama konfiguracja ma trafić do wielu repozytoriów. Zobacz zespołowy marketplace pluginów.
• Hooki uruchamiają skrypty przed etapami pętli agenta lub po nich i mogą zablokować akcję. Używaj ich do kontroli, która nigdy nie może zależeć od tego, czy agent pamięta o regule.

Jak pisać i testować skille, opisuje strona budowanie własnych skilli.

Przepuść wynik agenta przez bramki, zanim zobaczy go człowiek

Wspólne reguły dają spójny wynik. Nie dają poprawnego. Zespół potrzebuje kontroli, które dowodzą, że pull request jest w porządku, bez czytania każdej linii przez recenzenta, oraz jasnego podziału na to, co sprawdzają maszyny, a co zatwierdza człowiek.

1. Deweloper uruchamia w Cursorze skill kontroli przed PR. Skill uruchamia bramki typów, lintera i testów, a zmiany raportuje w tabeli.

2. CI powtarza te same bramki na pull requeście. Dowodem nie jest raport agenta, tylko wynik CI. Ustaw typecheck, lint i test jako wymagane status checki, żeby czerwony przebieg blokował merge.

3. Bugbot przegląda pull request. Według dokumentacji Cursora (sprawdzonej 28 sierpnia 2026) Bugbot przegląda pull requesty i wykrywa błędy, problemy bezpieczeństwa i jakości kodu. Nie czyta .cursor/rules/; wytyczne projektu bierze z .cursor/BUGBOT.md (według strony pomocy Cursora o Bugbocie, informacja z drugiej ręki, niepobrana ponownie 26 września 2026). Przepisz do tego pliku zasady nienegocjowalne z reguły stosowanej zawsze. Konfigurację i koszty opisuje strona o Bugbocie.

4. Deweloper prosi agenta o przegląd względem reguł promptem poniżej i naprawia każde znalezisko albo na nie odpowiada.

5. Recenzent sprawdza intencję: czy zmiana robi to, o co prosiło zgłoszenie, czy projekt jest taki, jaki zespół chce utrzymywać, i czy testy sprawdzają zachowanie, które ma znaczenie. Recenzent zatwierdza; autor odpowiada za merge.

Prompt do skopiowania: przegląd gałęzi względem reguł zespołu

Review the changes on this branch against main (run `git diff main...HEAD`).
Read every file in .cursor/rules/ first and use those rules as the standard.

Report, for each finding: file and line, the rule or risk it violates,
why it matters, and a concrete fix. Check specifically for:
1. Route handlers containing business logic or raw SQL
2. Async paths with no error handling, or errors not thrown as AppError
3. New behaviour with no test, or tests that only cover the success path
4. Imports of packages that are not in package.json
5. Unvalidated input reaching the database or a shell command
6. Anything that disables or bypasses an auth check

Do not edit files. If you find nothing in a category, say so explicitly.

„Say so explicitly” ma znaczenie: pusta kategoria w odpowiedzi mówi, że agent ją sprawdził, a brakująca kategoria, że nie. Recenzent czyta wtedy listę znalezisk i wynik CI zamiast całego diffa. Wersję tego podziału dla całego zespołu opisują strony kolejka code review, gdy pull requesty otwierają agenci i jak pomóc zespołowi przestać czytać każdy diff.

Wdróż nową osobę w jedno popołudnie

Sklonowanie repozytorium dostarcza reguły, listę serwerów MCP i skille. Zostaje komputer dewelopera i jedno zadanie wykonane w parze.

Checklista do skopiowania: onboarding w Cursorze

# Onboarding w Cursorze

## Konfiguracja (około godziny)
- [ ] Zainstaluj Cursora i zaloguj się kontem zespołowym (nie prywatnym)
- [ ] Sklonuj repozytorium i poczekaj, aż indeksowanie się zakończy
- [ ] Ustaw zmienne MCP wymienione w `CONTRIBUTING.md` (`GITHUB_PAT`, `DEV_DATABASE_URI`)
- [ ] Otwórz ustawienia MCP w Cursorze i potwierdź, że `github` i `postgres` są połączone
- [ ] Uruchom prompt „sprawdź, które reguły działają”; lista reguł musi zgadzać się z `.cursor/rules/`
- [ ] Potwierdź, że ustawienie trybu uruchamiania zgadza się z polityką zespołu z dokumentu o bezpieczeństwie

## Pierwsze zadanie (około dwóch godzin, w parze)
- [ ] Użyj Plan Mode, żeby zaplanować małą poprawkę błędu z backlogu; omów plan z partnerem
- [ ] Pozwól agentowi ją zaimplementować, potem uruchom skill `pre-pr-check`
- [ ] Uruchom prompt przeglądu gałęzi i rozwiąż każde zgłoszenie
- [ ] Otwórz pull request; obserwuj przebieg CI i Bugbota

## Pierwszy tydzień
- [ ] Dostarcz jedną funkcję od początku do końca przez te same bramki jakości
- [ ] Zaproponuj jedną zmianę w regule lub skillu na podstawie czegoś, co agent zrobił źle

Pierwsze zadanie zróbcie w parze. Obserwowanie, jak kolega pisze plan, którego agent nie może źle zrozumieć, uczy więcej niż checklista. Szczegóły przygotowania komputera znajdziesz na stronie instalacja Cursora.

Nie pozwól wspólnej konfiguracji się zestarzeć

Reguły starzeją się tak samo jak kod: reguła wskazująca przeniesiony plik dalej się ładuje, tylko teraz wprowadza w błąd. Trzy nawyki utrzymują konfigurację w aktualnym stanie:

• Poprawiaj regułę w tym samym pull requeście. Gdy recenzent wyłapie wzorzec, który agent zrobił źle, poprawka obejmuje zmianę reguły lub skilla, żeby błąd nie wrócił na komputerze kogoś innego.
• Refaktoryzuj reguły razem z kodem. Pull request, który zmienia nazwę src/lib/errors.ts, aktualizuje też każdą regułę, która się do niego odwołuje.
• Rób audyt co miesiąc. Przypisz to zadanie jednej osobie i użyj promptu poniżej.

Prompt do skopiowania: audyt wspólnych reguł Cursora

Audit .cursor/rules/ and .cursor/skills/ against the current codebase.
Do not edit anything. Report:
1. Every file path, function or package a rule or skill mentions that no
   longer exists (search for each one and show the search you ran)
2. Pairs of rules that contradict each other, quoting both lines
3. Rules marked alwaysApply: true that only matter for one directory and
   should be scoped with globs instead
4. Conventions the last 30 commits follow consistently that no rule states
   (run git log -30 --stat to see them)
Finish with a proposed diff for each rule you would change.

Wynik audytu da się sprawdzić: każde nieaktualne odwołanie przychodzi razem z wyszukiwaniem, które to udowodniło.

Kiedy wspólna konfiguracja Cursora się sypie

Dwie osoby dostają różny wynik z tego samego repozytorium. Uruchom prompt listujący reguły na obu komputerach i porównaj listy. Zwykle winny jest niezacommitowany plik reguły na jednym komputerze, osobista reguła z konwencją sprzeczną z projektem albo reguła zapisana ze złym rozszerzeniem. Przenieś konwencję do zacommitowanej reguły i usuń osobistą.

Reguła o zawężonym zakresie nigdy się nie włącza. Wzorzec globs nie pasuje do ścieżek, które edytuje agent. Zapytaj agenta, które reguły dotyczą jednego konkretnego pliku, popraw wzorzec i powtórz test.

Reguły stosowane zawsze wypychają z kontekstu samo zadanie. Każda linia reguły stosowanej zawsze kosztuje kontekst w każdej wiadomości. Reguły dotyczące jednego katalogu przenieś na globs, a długie procedury do skilli, które ładują się tylko wtedy, gdy są potrzebne.

Bugbot zgłasza to, na co reguły pozwalają, albo przepuszcza to, czego zabraniają. Bugbot nie czyta .cursor/rules/. Konwencje, które ma egzekwować, i te, których ma nie zgłaszać, wpisz do .cursor/BUGBOT.md.

Przegląd robiony przez agenta jest zbyt hałaśliwy, żeby coś z nim zrobić. Dopisz wyjątki do promptu albo skilla: „The GraphQL resolver layer uses any on purpose; do not flag it.” Przegląd, którego ludzie przestają czytać, jest gorszy niż żaden.

Serwer MCP działa u jednej osoby, a u reszty nie. Ktoś wpisał token na sztywno albo nazwa zmiennej różni się między komputerami. W zacommitowanym pliku zostaw wyłącznie odwołania ${env:NAZWA} i wypisz każdą zmienną w CONTRIBUTING.md.

Wygenerowana zmiana przeszła wszystkie bramki, a i tak była błędna. Testy nie pokrywały tego zachowania. Najpierw dodaj brakujący test, potem krok w regule lub skillu, który wymaga takiego testu, żeby następnym razem wyłapała to bramka.

Co dalej z konfiguracją zespołową w Cursorze

• Cursor w zespole i w firmie — przegląd sekcji
• Prywatność i bezpieczeństwo w Cursorze — Privacy Mode, polityka trybów uruchamiania i reguły bezpieczeństwa
• Code review w Cursorze — narzędzia przeglądu, do których podpina się ta bramka
• Zarządzanie tokenami — jak trzymać w ryzach zużycie całego zespołu
• Wspólne reguły agentów: jeden rdzeń, przetestowane adaptery — dla zespołów, które używają Cursora obok Claude Code lub Codexa