Współpraca zespołowa: Wskazówki 106-112

Współpraca zespołowa w Cursorze oznacza commitowanie reguł projektu, konfiguracji MCP i szablonów promptów do kontroli wersji, aby rozmowy każdego programisty z agentem korzystały z tych samych ograniczeń zamiast pięciu stylów kodu. Siedem wskazówek obejmuje wspólny katalog reguł, listę kontrolną onboardingu produktywną w jeden dzień, proces recenzji wspomaganej przez AI, wielokrotnie używane szablony promptów oraz politykę bezpieczeństwa równoważącą produktywność ze zgodnością.

Twój zespół ma pięciu programistów używających Cursora. Każdy ma różne reguły globalne, różne preferencje modelu, różne style promptowania. Agent jednego programisty generuje kod ze średnikami; innego generuje kod bez. Jeden używa wszędzie typów any; inny pisze ścisły TypeScript. Kod generowany przez AI wygląda, jakby został napisany przez pięć różnych osób — ponieważ został skonfigurowany przez pięć różnych osób. Te 7 wskazówek przekształca indywidualne konfiguracje Cursora w skoordynowany przepływ pracy zespołowej.

Co daje skoordynowana konfiguracja zespołu w Cursorze

• Zacommitowany katalog .cursor/rules/, który sprawia, że kod generowany przez AI jest spójny w całym zespole
• Listę kontrolną onboardingu, która sprawia, że nowi członkowie zespołu są produktywni z Cursorem w jeden dzień
• Proces recenzji kodu wspomaganej przez AI, który wychwytuje problemy, zanim recenzenci-ludzie poświęcą na nie czas
• Wspólne szablony promptów, które kodują najlepsze praktyki zespołu w wielokrotnie używane pliki
• Politykę bezpieczeństwa, która równoważy produktywność z wymogami zgodności

Wspólna konfiguracja

Wskazówka 106: Zacommituj swoje reguły Cursora do kontroli wersji

To najważniejsza wskazówka zespołowa. Reguły projektu należą do kontroli wersji, a nie do indywidualnych ustawień programistów. Gdy reguły są zacommitowane, każdy programista i każda konwersacja agenta używa tych samych ograniczeń.

Utwórz katalog reguł i zacommituj go:

mkdir -p .cursor/rules

Jako minimum utwórz te pliki:

.cursor/rules/code-style.md

## Styl kodu

- TypeScript strict mode. Bez typów 'any' z wyjątkiem miejsc, gdzie jest to wyraźnie udokumentowane.
- Tylko named exports. Bez default exports.
- Komponenty funkcyjne z hookami dla React.
- camelCase dla zmiennych i funkcji. PascalCase dla typów, interfejsów i komponentów.
- Używaj async/await. Nigdy nie używaj łańcuchów .then().
- Wszystkie funkcje async muszą mieć obsługę błędów try-catch.
- Preferuj fetch zamiast axios do żądań HTTP.
- Używaj pnpm do wszystkich poleceń menedżera pakietów.

.cursor/rules/testing.md

## Konwencje testowania

- Używaj vitest do wszystkich testów jednostkowych i integracyjnych.
- Pliki testowe znajdują się obok kodu, który testują: src/services/__tests__/user.test.ts
- Używaj opisowych nazw testów, które wyjaśniają scenariusz: "should return 404 when user does not exist"
- Mockuj zależności zewnętrzne (baza danych, API), ale nie moduły wewnętrzne.
- Cel to 80% pokrycia kodu dla nowego kodu.
- Zawsze testuj przypadki błędów, nie tylko happy paths.

.cursor/rules/architecture.md

## Zasady architektury

- Trasy API w src/api/ obsługują tylko kwestie HTTP (parsowanie, walidacja, formatowanie odpowiedzi).
- Logika biznesowa trafia do src/services/. Serwisy nigdy nie importują z src/api/.
- Operacje bazodanowe trafiają do src/repositories/. Serwisy używają repozytoriów, nigdy surowych zapytań.
- Współdzielone typy trafiają do src/types/. Typy to jedyna rzecz, którą każda warstwa może importować.
- Nie twórz zależności cyklicznych. Jeśli serwis A potrzebuje serwisu B, wstrzyknij go jako parametr.

Skopiuj-wklej commit git dla początkowych reguł

git add .cursor/rules/
git commit -m "Dodaj reguły projektu Cursora dla spójnego zachowania AI

Dodaje reguły stylu kodu, testowania i architektury, które stosują się do
całego kodu generowanego przez AI. Zapewniają spójność w zespole."

Wskazówka 107: Standaryzuj konfigurację serwerów MCP

Jeśli Twój zespół używa serwerów MCP (baza danych, GitHub, Jira), zacommituj konfigurację, aby każdy programista miał to samo ustawienie. Używaj utrzymywanych serwerów — stare pakiety npm @modelcontextprotocol/server-github i @modelcontextprotocol/server-postgres są oba przestarzałe (“no longer supported”). Firmowy serwer GitHuba jest teraz dostarczany jako zdalny endpoint, a referencyjny serwer Postgres trafił do archiwum, więc skieruj zespół na aktywnie utrzymywane zamienniki:

.cursor/mcp.json

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": { "Authorization": "Bearer ${GITHUB_TOKEN}" }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@henkey/postgres-mcp-server", "--connection-string", "${DATABASE_URL}"]
    }
  }
}

Wpis GitHub używa hostowanego github/github-mcp-server (https://api.githubcopilot.com/mcp/); dla zespołu w środowisku odizolowanym lub self-hosted zamień go na build Docker stdio z tego samego repozytorium. Dla Postgres @henkey/postgres-mcp-server (lub postgres-mcp od crystaldba) jest utrzymywany i świadomy operacji odczytu. Udokumentuj wymagane zmienne środowiskowe w README projektu lub przewodniku onboardingu. Każdy programista ustawia własne tokeny, ale konfiguracja serwera MCP jest współdzielona.

Wskazówka 108: Utwórz wspólne szablony promptów

Zapisz często używane prompty jako pliki w repozytorium, aby każdy członek zespołu mógł się do nich odwoływać:

mkdir -p .cursor/prompts

.cursor/prompts/new-endpoint.md

Utwórz nowy endpoint API zgodnie z tymi konwencjami projektu:

1. Handler trasy w src/api/[resource]/route.ts używając wzorca z @src/api/users/route.ts
2. Warstwa serwisowa w src/services/[resource].ts używając wzorca z @src/services/user.ts
3. Definicje typów w src/types/[resource].ts
4. Testy Vitest w src/services/__tests__/[resource].test.ts
5. Schemat walidacji Zod dla body żądania
6. Odpowiednia obsługa błędów używając naszej klasy AppError z @src/lib/errors.ts

Uruchom pnpm test po implementacji, aby zweryfikować, że wszystko przechodzi.

.cursor/prompts/pre-pr.md

Przejrzyj i napraw wszystkie problemy przed gotowością tego PR:

1. pnpm run typecheck -- napraw błędy TypeScript
2. pnpm run lint -- napraw problemy lintingu
3. pnpm run test -- napraw nieudane testy (nie modyfikuj asercji)
4. Usuń wszystkie instrukcje console.log/debug
5. Zweryfikuj, że wszystkie nowe eksporty są dodane do plików index
6. Sprawdź, że żadne wrażliwe dane (klucze API, hasła) nie są zacommitowane

Podsumuj wszystkie dokonane zmiany.

Członkowie zespołu odwołują się do nich za pomocą @.cursor/prompts/new-endpoint.md w dowolnej konwersacji agenta. Prompty kodują najlepsze praktyki zespołu, dzięki czemu nawet najnowszy członek zespołu produkuje spójny output.

Onboarding i szkolenie

Wskazówka 109: Utwórz listę kontrolną onboardingu Cursora dla nowych członków zespołu

Gdy nowy programista dołącza do zespołu, powinien być produktywny z Cursorem w ciągu dnia. Utwórz dokument onboardingu:

Skopiuj-wklej listę kontrolną onboardingu

# Lista kontrolna onboardingu Cursora

## Konfiguracja dnia 1 (2 godziny)

1. Zainstaluj Cursora: `brew install --cask cursor`
2. Zaimportuj ustawienia VS Code: Cmd+Shift+P > "Import VS Code Settings"
3. Zainstaluj polecenia powłoki: Cmd+Shift+P > "Install cursor command in PATH"
4. Skonfiguruj Auto-Run: Settings > Cursor Settings > Agents > Auto-Run. Wybierz Run in Sandbox (zalecane) lub Ask Every Time i dodaj zespołową Command Allowlist z tego dokumentu. Nie włączaj Run Everything.
5. Ustaw domyślny model na Claude Sonnet 5
6. Sklonuj repozytorium i zweryfikuj zakończenie indeksowania (powinno zająć mniej niż 5 minut)
7. Zweryfikuj załadowanie reguł projektu: otwórz agenta, zapytaj "Jakie reguły dotyczą tego projektu?"
8. Skonfiguruj wymagane zmienne środowiskowe dla serwerów MCP

## Praktyka dnia 1 (2 godziny)

1. Użyj Cmd+K, aby dodać obsługę błędów do dowolnej funkcji w kodzie
2. Użyj trybu agenta, aby zaimplementować małą poprawkę błędu z backlogu
3. Użyj @.cursor/prompts/pre-pr.md, aby uruchomić listę kontrolną przed-PR
4. Wypróbuj przepływ uzupełniania Tab: napisz dwa przypadki testowe ręcznie, pozwól Tab wygenerować trzeci
5. Wygeneruj wiadomość commit używając ikony gwiazdki w Source Control

## Pierwszy tydzień

1. Ukończ jedną funkcję używając przepływu pracy agenta test-driven (Wskazówka 61)
2. Użyj trybu Ask, aby zrozumieć jeden nieznany moduł
3. Wypróbuj agenta w tle do generowania pokrycia testami dla modułu
4. Przejrzyj i popraw jedną regułę projektu na podstawie swojego doświadczenia

Wskazówka 110: Przeprowadzaj cotygodniowe “Wskazówki Cursora” podczas standupu

Poświęć 5 minut jednego cotygodniowego standupu na wskazówki dotyczące Cursora. Co tydzień jeden członek zespołu dzieli się:

• Promptem, który działał szczególnie dobrze
• Przepływem pracy, który odkrył
• Problemem, którego nie mógł rozwiązać za pomocą Cursora (zespół może mieć rozwiązanie)
• Sugestią nowej reguły projektu

To tworzy pętlę zwrotną, w której zespół nieustannie poprawia swoje użycie Cursora. Najlepsze prompty i przepływy pracy są dodawane do .cursor/prompts/ dla wszystkich.

Recenzja kodu i jakość

Wskazówka 111: Wdróż przed-recenzję wspomaganą przez AI

Przed poproszeniem o recenzję kodu przez człowieka każdy członek zespołu przeprowadza recenzję AI:

1. Programista kończy swoją funkcję
2. Programista uruchamia @.cursor/prompts/pre-pr.md, aby naprawić linting, typy i testy
3. Programista uruchamia Bugbot na gałęzi/PR (automatyczne wykrywanie błędów w Cursorze — zobacz cursor.com/docs/bugbot)
4. Programista uruchamia prompt recenzji kodu AI poniżej
5. Programista naprawia problemy znalezione w krokach 2-4
6. Programista otwiera PR do recenzji przez człowieka

Skopiuj-wklej prompt zespołowej recenzji kodu

@git diff main

Zrecenzuj ten PR jako starszy inżynier w tym zespole. Odnieś się do naszych reguł projektu w @.cursor/rules/ dla standardów.

Sprawdź pod kątem:

1. Naruszeń architektury (bezpośredni dostęp do bazy danych z tras, zależności cykliczne)
2. Braku obsługi błędów w operacjach async
3. Problemów z bezpieczeństwem typów (typy any, brakujące sprawdzenia null)
4. Luk w pokryciu testami dla nowej funkcjonalności
5. Niespójności nazewnictwa z istniejącym kodem
6. Problemów bezpieczeństwa (niezwalidowane dane wejściowe, ujawnione dane uwierzytelniające, SQL injection)

Dla każdego znalezionego problemu wyjaśnij, dlaczego to ma znaczenie i zasugeruj konkretną poprawkę.

Ta przed-recenzja wychwytuje 60-70% problemów, które recenzent-człowiek by oznaczył. Recenzenci-ludzie mogą wtedy skupić się na decyzjach architektonicznych, poprawności logiki biznesowej i kompromisach projektowych — rzeczach, w których AI jest najgorszy.

Bezpieczeństwo i zgodność

Wskazówka 112: Ustanów zespołową politykę bezpieczeństwa dla narzędzi AI

Utwórz politykę bezpieczeństwa, która równoważy produktywność z zgodnością:

.cursor/rules/security.md

## Polityka bezpieczeństwa AI

### Do czego AI może mieć dostęp
- Cały kod źródłowy w repozytorium
- Bazy danych deweloperskie i stagingowe przez MCP (nigdy produkcyjne)
- Publiczna dokumentacja i API
- Logi CI/CD i artefakty build

### Czego AI nie może robić
- Dostęp do baz danych lub serwerów produkcyjnych
- Commitowanie lub pushowanie kodu bez recenzji przez człowieka
- Przechowywanie kluczy API, haseł lub sekretów w kodzie
- Wyłączanie middleware bezpieczeństwa lub kontroli uwierzytelniania
- Modyfikowanie plików .env lub konfiguracji wdrożenia

### Wymagania prywatności
- Włącz tryb prywatności dla całego kodu własnościowego
- Nie wklejaj danych klientów do konwersacji agenta
- Nie odwołuj się do wewnętrznych dokumentów firmowych przez URL
- Przejrzyj cały kod generowany przez AI pod kątem przypadkowo ujawnionych danych uwierzytelniających

### Ograniczenia Auto-Run
- Ustaw tryb Auto-Run na Run in Sandbox lub Ask Every Time. Nigdy nie włączaj Run Everything.
- Ogranicz Command Allowlist wyłącznie do poleceń testowych, build, lintingu i tworzenia plików.
- Trzymaj git push, deploy, npm publish i wszelkie polecenia dotykające danych uwierzytelniających poza allowlistą, aby zawsze wymagały zatwierdzenia.
- Nie polegaj na denyliście. Cursor wycofał denylistę poleceń w 1.3 (była trywialnie obchodzona); sandbox plus ścisła allowlista to wspierany model bezpieczeństwa.

Zacommituj to do swojego repozytorium i przejrzyj podczas onboardingu. Aktualizuj w miarę ewolucji wymagań bezpieczeństwa zespołu.

Gdy zespołowe konwencje Cursora zawodzą

Członkowie zespołu nadpisują reguły projektu osobistymi ustawieniami: Globalne reguły użytkownika mają pierwszeństwo przed regułami projektu dla niektórych ustawień. Upewnij się, że dokument reguł projektu nie koliduje z powszechnymi osobistymi preferencjami. Jeśli pojawiają się konflikty, przeprowadź dyskusję zespołową, aby standaryzować konwencję i zaktualizować reguły projektu.

Lista kontrolna onboardingu staje się przestarzała: Przypisz jednemu członkowi zespołu aktualizację listy kontrolnej onboardingu, gdy Cursor wypuści znaczącą aktualizację lub zespół zmieni przepływ pracy. Przeglądaj ją co najmniej kwartalnie.

Recenzja kodu AI jest zbyt hałaśliwa: Jeśli prompt recenzji AI generuje zbyt wiele fałszywych alarmów, dopracuj go. Dodaj wyjątki dla znanych wzorców: “Nasz projekt celowo używa typów ‘any’ w warstwie resolverów GraphQL — nie oznaczaj ich.” Im bardziej konkretny prompt, tym mniej fałszywych alarmów.

Tokeny serwera MCP wygasają: Ustaw przypomnienia kalendarzowe dla odnowienia tokenów. Udokumentuj proces rotacji tokenów w przewodniku onboardingu. Rozważ użycie krótkotrwałych tokenów z systemu zarządzania sekretami organizacji.

Dokąd pójść po pełnej kolekcji 112 wskazówek

Ukończyłeś pełną kolekcję 112 wskazówek. Twój indywidualny przepływ pracy jest zoptymalizowany, Twój zespół jest skonfigurowany dla spójności i masz zaawansowane techniki do radzenia sobie z każdym wyzwaniem programistycznym.

Aby kontynuować rozwój:

• Przeglądaj sekcję Zaawansowane techniki Cursora dla dogłębnych analiz trybów agenta, punktów kontrolnych i przepływów pracy automatyzacji
• Eksploruj Wzorce produktywności dla skrótów klawiszowych, przepływów pracy debugowania i strategii testowania
• Sprawdź Zarządzanie wersjami, aby być na bieżąco z najnowszymi funkcjami Cursora
• Wróć do tego Indeksu kolekcji wskazówek, gdy potrzebujesz przypomnienia konkretnych technik