Zaawansowane techniki w Cursorze: wskazówki 91-105

Poziom 5 Poradnik Zaktualizowano 2026-10-12

Zaawansowane techniki w Cursorze łączą agenta z prawdziwymi systemami przez serwery MCP, oddają długie zadania Cloud Agents i sprawiają, że każda zmiana sama się broni, zanim zobaczy ją człowiek. Piętnaście wskazówek składa MCP, Cloud Agents, hooki, skille, Bugbota i dyscyplinę modeli w jedną pętlę, w której o ukończeniu pracy decydują testy i bramki, a nie czytanie kodu linia po linii.

Ta strona jest dla dewelopera, który na co dzień korzysta z trybu agenta, reguł projektu i zawężonego kontekstu. Masz już podłączonych kilka serwerów MCP i masz za sobą pierwsze uruchomienia Cloud Agents. Mimo to wynik trafia na twoje biurko jako diff, który czujesz się w obowiązku przeczytać w całości, bo nic w konfiguracji nie dowodzi, że agent skończył zadanie. Te wskazówki to zmieniają.

Co dają wskazówki 91-105

Zacommitowany .cursor/mcp.json, który daje agentowi odczyt z GitHuba i deweloperskiej bazy danych, a zapis tylko tam, gdzie świadomie go dodasz.
Dwa prompty do skopiowania, które zamieniają zgłoszenie albo schemat bazy w testy akceptacyjne, zanim powstanie kod.
Specyfikację zadania dla Cloud Agenta, której pull request niesie własne dowody.
Hook stop, który uruchamia sprawdzanie typów, linter i testy za każdym razem, gdy agent ogłasza koniec, i odsyła go do pracy, gdy coś nie przechodzi.
Kolejność review (samokontrola, Bugbot, CI, akceptacja człowieka), w której każda warstwa sprawdza to, czego nie widzą pozostałe.
Zasadę wyboru modelu i sposób, by zobaczyć, ile kosztuje każde zadanie.

Jak podłączyć agenta Cursora do twoich systemów przez MCP?

Serwer MCP daje agentowi narzędzia wykraczające poza system plików i terminal: odczyt pull requesta, zapytanie o schemat bazy czy pobranie zgłoszenia. Każdy serwer to jednocześnie kod działający z twoimi poświadczeniami, a opisy jego narzędzi trafiają do każdego zapytania. Podstawy opisuje konfiguracja MCP w Cursorze.

Wskazówka 91: każdy serwer MCP zaczynaj w trybie tylko do odczytu

Najpierw daj agentowi odczyt, a zapis dodawaj pod konkretne zadanie, nie z przyzwyczajenia. Serwer tylko do odczytu wciąż może przenieść dane do promptu, ale nie zamknie zgłoszenia, nie zmerguje pull requesta i nie usunie tabeli dlatego, że kazał mu to prompt injection ukryty w treści issue. Zatwierdzaj narzędzia każdego serwera świadomie i trzymaj włączone tylko te serwery, których wymaga bieżące zadanie. Jak obniżyć koszt tokenów MCP pokazuje, jak zmierzyć, ile kontekstu zjada każdy z nich.

Wskazówka 92: zacommituj jeden wspólny `.cursor/mcp.json`

Zacommituj listę serwerów, żeby każdy klon dostawał te same narzędzia, a poświadczenia zostaw w środowisku każdego dewelopera:

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

GitHub to hostowany serwer GitHuba z repozytorium github/github-mcp-server. Endpoint /readonly udostępnia wyłącznie narzędzia do odczytu. Gdy chcesz, żeby agent komentował albo pushował, przełącz się w osobistej konfiguracji na https://api.githubcopilot.com/mcp/.
Postgres MCP Pro to pakiet PyPI postgres-mcp (0.3.0, sprawdzone 26 września 2026) uruchamiany przez uvx. --access-mode=restricted wykonuje transakcje tylko do odczytu z limitem czasu. Nie uruchamiaj npx postgres-mcp: pakiet npm o tej nazwie nie ma z tym serwerem nic wspólnego.
${env:NAZWA} odczytuje token ze środowiska dewelopera. DEV_DATABASE_URI kieruj na lokalną albo jednorazową bazę, nigdy na produkcję.

Starsze pakiety @modelcontextprotocol/server-github i @modelcontextprotocol/server-postgres są zarchiwizowane, więc zamień każdy wpis, który jeszcze z nich korzysta. Pełne opcje opisują strony serwer MCP GitHuba i serwery MCP dla baz danych.

Wskazówka 93: pisz migrację na podstawie prawdziwego schematu, a potem ją udowodnij

Bez serwera bazy danych agent pisze migrację pod schemat, który sobie wyobraża na podstawie plików ORM. Z serwerem najpierw czyta prawdziwą tabelę. Dowodem nie jest plik migracji, tylko czyste zastosowanie i diff schematu na bazie, którą możesz wyrzucić.

Use the postgres MCP server to read the current definition of the "users"
and "organizations" tables, including indexes and foreign keys. Do not write
to the database through MCP.

Then write a Drizzle migration that adds users.organization_id as a nullable
foreign key to organizations.id, with an index. Existing rows keep NULL.

Prove it before you stop:
1. Run the migration against the dev database with our migrate script.
2. Read the "users" table again through MCP and show the before/after diff.
3. Run the migration's down step, confirm the schema matches the original,
   then apply it again.
4. Run the repository and service tests that touch users.

Finish with a table: step, command, result. Stop and ask if any step fails.

Wskazówka 94: zamień zgłoszenie w testy, zanim agent napisze kod

Kryteria akceptacji są już w trackerze, więc niech agent je przeczyta, zamiast żebyś sam je streszczał. Linear (https://mcp.linear.app/mcp) i Atlassian (https://mcp.atlassian.com/v2/mcp, który zastępuje starsze endpointy /v1) udostępniają hostowane serwery z logowaniem OAuth; zobacz serwery MCP do zarządzania projektami. Przy pracy nad UI serwer MCP Figmy podaje dokładne odstępy i tokeny zamiast zgadywania ze zrzutu ekranu.

Read Linear issue ENG-482 through the linear MCP server, including comments.

1. List every acceptance criterion as a numbered, testable statement. If a
   criterion is ambiguous, write the question instead of guessing.
2. For each criterion, write one test in the existing test suite that fails
   today. Name each test after its criterion number.
3. Run the tests and show that each new test fails for the expected reason.

Stop there. Do not implement the feature yet. I will review the criteria
and tests, then ask you to make them pass.

Porównanie 10 nazw testów z 10 kryteriami zajmuje kilka minut. Implementacji, która sprawia, że testy przechodzą, nie musisz już czytać linia po linii.

Jak oddawać długą pracę Cloud Agents?

Cloud Agents w Cursorze (dawniej background agents) „run in isolated VMs in the cloud with full development environments”, a Automations uruchamiają je według harmonogramu albo na zdarzenia z systemu kontroli wersji, Slacka, webhooków, Lineara, Sentry i PagerDuty (dokumentacja cursor.com, sprawdzone 28 sierpnia 2026). Mechanikę opisuje strona Cloud Agents i Automations. Te wskazówki mówią, jaką pracę tam wysyłać i jak odebrać ją w stanie, który da się zweryfikować.

Wskazówka 95: wysyłaj pracę, która ma wyrocznię

Cloud Agent nie zada ci pytania w połowie zadania, więc wysyłaj mu pracę, której wynik może ocenić maszyna:

Dobre zadanie dla Cloud Agenta	Zostaw lokalnie
Podniesienie pokrycia modułu, ocenione raportem pokrycia	Decyzja projektowa bez uzgodnionej odpowiedzi
Błąd z nieprzechodzącym testem reprodukującym	Błąd, którego nikt jeszcze nie odtworzył
Podbicie zależności, ocenione pełnym zestawem testów	Praca wymagająca poświadczeń produkcyjnych
Mechaniczny refaktor z regułą lintera wykrywającą stary wzorzec	Zmiany w autoryzacji, płatnościach lub migracjach bez wskazanego recenzenta

Wskazówka 96: pisz zadanie jako specyfikację zakończoną dowodami

Umieść w prompcie kryteria akceptacji, wzorce do naśladowania, polecenia, które dowodzą sukcesu, i kształt opisu pull requesta. Wtedy to opis pull requesta niesie dowody, a review zaczyna się od wyników, a nie od diffu.

Branch from main. Add Vitest tests for every exported function in
src/services/payment.ts.

Constraints:
- Follow the structure of src/services/__tests__/user.test.ts.
- Mock the Stripe SDK and the database layer; no network calls.
- Cover, per function: a valid call, invalid input, and a failure from each
  dependency (Stripe error, database error).
- Do not change any file under src/ except to fix a bug a test exposes.
  If you find one, stop after writing the failing test and describe it.

Definition of done:
- `npm run typecheck`, `npm run lint` and `npm test` pass.
- Line coverage for src/services/payment.ts is at least 90%.

Open a pull request titled "test: payment service coverage". In the
description, include: the list of test names grouped by function, the
coverage figure before and after, the exact commands you ran with their
final lines of output, and anything you could not test and why.

Wskazówka 97: uruchamiaj rutynową pracę zdarzeniami, nie z pamięci

Gdy specyfikacja zadania działa uruchamiana ręcznie, przestań ją uruchamiać ręcznie. Automation podpięta pod zdarzenie z systemu kontroli wersji, Lineara albo Slacka za każdym razem wykona tę samą specyfikację. Zacznij od jednego zadania, które głównie czyta, na przykład nocnego audytu zależności, który otwiera pull request tylko wtedy, gdy przechodzi pełny zestaw testów. Uprawnienia trzymaj wąsko: agent bez nadzoru powinien działać w konfiguracji opisanej w uprawnieniach, sandboksach i trybach zatwierdzania. Żeby uruchamiać agentów z własnych skryptów albo CI, użyj Cursor SDK i Cloud Agents API. Porównanie agentów w tle i w chmurze zestawia rozwiązanie Cursora z Claude Code i Codexem.

Jak sprawić, żeby agent Cursora udowadniał swoją pracę?

Dotychczasowe wskazówki poszerzają zasięg agenta. Te sprawiają, że wynik da się sprawdzić bez czytania każdej linii przez człowieka.

Wskazówka 98: dodaj hook stop, który uruchamia twoje bramki

Hooki w Cursorze to skrypty, które „run before or after defined stages of the agent loop and can observe, block, or modify behavior” (dokumentacja cursor.com, sprawdzone 28 sierpnia 2026). Hook stop odpala się, gdy agent kończy turę. W kodzie agenta Cursora (@cursor/sdk 1.0.32, sprawdzone 26 września 2026) dostaje na stdin JSON ze status tury i licznikiem loop_count. Gdy wypisze followup_message, agent pracuje dalej, traktując tę wiadomość jako kolejne polecenie. loop_limit ustawiany na poziomie hooka ogranicza, ile razy może się to powtórzyć; bez niego runtime zatrzymuje pętlę po pięciu razach.

{
  "version": 1,
  "hooks": {
    "stop": [
      { "command": "node .cursor/hooks/verify-on-stop.mjs", "timeout": 600, "loop_limit": 3 }
    ]
  }
}

// Runs the project's gates when the agent says it is done.
// On failure, sends the agent back with the tail of the output.
import { execSync } from 'node:child_process';
import { readFileSync } from 'node:fs';

const input = JSON.parse(readFileSync(0, 'utf8') || '{}');
const done = (out = {}) => { process.stdout.write(JSON.stringify(out)); process.exit(0); };

if (input.status !== 'completed') done();
// Nothing changed (tracked or untracked): nothing to verify.
if (execSync('git status --porcelain', { encoding: 'utf8' }).trim() === '') done();

const gates = ['npm run typecheck', 'npm run lint', 'npm test'];
for (const cmd of gates) {
  try {
    execSync(cmd, { stdio: 'pipe', encoding: 'utf8' });
  } catch (err) {
    const tail = `${err.stdout ?? ''}${err.stderr ?? ''}`.slice(-3000);
    done({
      followup_message:
        `"${cmd}" failed after your change. Fix the cause in the source code. ` +
        `Do not delete, skip or weaken tests. Output:\n${tail}`,
    });
  }
}
done();

Sprawdzenie git status --porcelain pomija bramki, gdy drzewo robocze jest czyste. Gdy drzewo ma już niezatwierdzone zmiany, bramki uruchamia każda zakończona tura, także taka, w której agent tylko odpowiedział na pytanie. Dlatego dbaj o szybkie bramki albo porównuj zapisany skrót (hash) wyniku git diff i uruchamiaj je tylko wtedy, gdy diff się zmienił. Jeśli pełny zestaw testów trwa kilka minut, uruchamiaj tu tylko testy dotknięte zmianą, a pełny zestaw zostaw CI. Przypisz .cursor/hooks.json i .cursor/hooks/ do właściciela w CODEOWNERS, bo każdy, kto może edytować hook, może też wyłączyć bramkę. Prywatność i bezpieczeństwo w Cursorze opisuje strażnika beforeShellExecution, który dobrze uzupełnia ten hook.

Wskazówka 99: spakuj procedurę przed PR jako skill

Checklista wysłana na Slacku z czasem się rozjeżdża, skill w repozytorium nie. Agent Skill to folder z plikiem SKILL.md. Cursor ładuje skille projektu z .agents/skills/ i .cursor/skills/ oraz, „for compatibility”, z .claude/skills/ i .codex/skills/, a skille użytkownika z tych samych czterech folderów w katalogu domowym (dokumentacja Cursora, sprawdzone 2026-10-12). Ten sam format działa w Claude Code i Codexie. Współpraca zespołowa w Cursorze zawiera kompletny skill pre-pr-check do skopiowania. Niech jego ostatni krok wypełnia sekcję dowodów w opisie pull requesta w formacie pakietu dowodów, dzięki czemu każdy pull request wygląda dla recenzenta tak samo.

Wskazówka 100: przejrzyj diff w nowym czacie, zgodnie z regułami

Czat, który napisał kod, ma te same martwe pola co jego autor. Otwórz nowy czat, wskaż mu gałąź i poproś, żeby szukał powodów do odrzucenia zmiany.

Run `git diff main...HEAD` in the terminal and read the full diff. You did
not write this code. Your job is to find reasons to reject it.

Check, in this order, and cite file:line for each finding:
1. Behaviour the tests do not cover: list each changed branch or error path
   with no test that exercises it.
2. Security: injection, missing authorization checks, secrets, data returned
   to a caller that should not see it.
3. Violations of the rules in .cursor/rules/ that apply to the changed files.
4. Error handling: promises without rejection handling, swallowed errors.

For every finding in 1, write the missing test and run it. Report which new
tests fail. Do not fix the source code; list the fixes you recommend.

Liczy się lista nowych, nieprzechodzących testów. Każdy z nich to błąd znaleziony przez wykonanie kodu, a nie przez czyjąś opinię.

Wskazówka 101: niech Bugbot będzie warstwą, a nie bramką

Bugbot „reviews pull requests and identifies bugs, security issues, and code quality problems” (dokumentacja cursor.com, sprawdzone 28 sierpnia 2026). Traktuj jego komentarze jako dane wejściowe do decyzji o merge’u. Sama decyzja opiera się na CI, dowodach w pull requeście i wskazanej osobie przy ścieżkach wysokiego ryzyka. Pliki reguł i Autofix opisuje strona Bugbot: wyuczone reguły i Autofix, razem z ograniczaniem szumu i testem z celowo wprowadzonym błędem. Rollouts oraz PR Routing & Approval opisuje zatwierdzanie pull requestów niskiego ryzyka według reguł.

Jak świadomie wydawać na modele i tokeny?

Wskazówka 102: zostań przy domyślnym modelu, dopóki ewaluacje nie pokażą czegoś innego

Zasada, którą ta strona stosuje do każdego narzędzia: zacznij od domyślnego modelu, podnieś poziom rozumowania, jeśli selektor modeli na to pozwala, a model zmieniaj dopiero wtedy, gdy twoje własne testy pokażą, że inny radzi sobie lepiej z twoimi zadaniami. Lista modeli i ustawienia domyślne w Cursorze często się zmieniają, a Cursor nie wskazuje jednego modelu domyślnego (dokumentacja Cursora, sprawdzone 2026-10-12), więc sprawdź je w selektorze modeli w Cursorze i w przeglądzie modeli. Ramy decyzji opisuje wybór modelu w Cursorze. Najtańsza ewaluacja, jaką już masz, to hook stop ze wskazówki 98: policz, jak często każdy model potrzebuje dodatkowej tury, żeby przejść bramki.

Wskazówka 103: planuj w Plan Mode przed długim zadaniem

Plan Mode „creates detailed implementation plans before writing any code” (dokumentacja cursor.com, sprawdzone 28 sierpnia 2026). Używaj go przed każdym zadaniem, które dotyka więcej niż kilku plików. Zły plan kosztuje jedno czytanie, zła implementacja kosztuje revert i drugie uruchomienie.

Wskazówka 104: uruchom dwie próby w worktree i pozwól testom wybrać

Worktrees „let Agent work in isolated Git checkouts” (dokumentacja cursor.com, sprawdzone 28 sierpnia 2026). Jeśli zadanie ma mocną wyrocznię testową, uruchom tę samą specyfikację w dwóch worktree, z różnymi modelami albo różnymi podejściami, i zostaw tę wersję, która przechodzi bramki mniejszym diffem. Zwycięzcę wybierają testy, więc czytasz jeden diff, a nie dwa. Okno Agents pokazuje, jak nadzorować równoległe przebiegi.

Wskazówka 105: mierz koszt na zadanie, nie na miesiąc

Miesięczna suma zużycia mówi, że wydałeś za dużo, ale nie mówi gdzie. Zapisuj tokeny na zadanie: jeden czat na zadanie, nowy czat, gdy zadanie się zmienia, i odwołania do plików zamiast całych katalogów. Zarządzanie tokenami w Cursorze pokazuje, jak odczytać liczbę tokenów dla każdego przebiegu i logować hookiem każdą kompakcję kontekstu.

Jak zweryfikować wynik bez czytania każdej linii?

Każda z powyższych technik dodaje jedną kontrolę. Razem tworzą ścieżkę review dla zmiany agenta:

Przed kodem: kryteria akceptacji istnieją jako nieprzechodzące testy (wskazówka 94), a ty przejrzałeś nazwy testów, nie implementację.
Przy każdej turze agenta: hook stop uruchamia sprawdzanie typów, linter i testy i odsyła agenta, dopóki nie przejdą (wskazówka 98).
Przed pushem: nowy czat zamienia luki w pokryciu w nowe nieprzechodzące testy (wskazówka 100), a skill przed PR wypełnia sekcję dowodów (wskazówka 99).
Na pull requeście: CI ponownie uruchamia wszystkie bramki z konfiguracji gałęzi bazowej, a Bugbot dokłada ocenę logiki i zgodności z regułami (wskazówka 101).
Akceptacja: wskazany właściciel czyta dowody. Kod czyta tylko przy ścieżkach wysokiego ryzyka, takich jak autoryzacja, płatności i migracje. Tę decyzję opisuje czytanie dowodów zamiast kodu.

Co psuje się w zaawansowanej konfiguracji Cursora?

Hook stop kręci się w kółko na tym samym błędzie. Agent wciąż „naprawia” test, którego nie potrafi doprowadzić do zielonego stanu, a pętla kończy się na limicie z czerwonymi bramkami. Obniż loop_limit do 2 lub 3, żeby zablokowany przebieg szybciej się zatrzymał. Przeczytaj ostatnią wiadomość follow-up: jeśli błąd wynika ze środowiska, na przykład brakuje usługi albo zmiennej środowiskowej, napraw środowisko, a nie prompt.

Agent edytuje test, żeby przejść przez hook. Wiadomość follow-up tego zabrania, ale polecenie to nie egzekwowanie. Dodaj w CI krok, który oblewa pull request usuwający albo pomijający test bez etykiety test-change-approved. Katalogi z testami dopisz do CODEOWNERS, żeby zmieniona asercja wymagała akceptacji człowieka.

Serwer MCP nie startuje. Uruchom polecenie serwera z konfiguracji we własnym terminalu, z tymi samymi zmiennymi środowiskowymi. Najczęstsze przyczyny to wygasły token, zmienna, której brakuje w powłoce, z której wystartował Cursor, albo uvx lub npx poza ścieżką widoczną dla Cursora. Przy serwerach zdalnych zaloguj się ponownie w ustawieniach MCP w Cursorze. Zobacz problemy z połączeniem MCP.

Pull request od Cloud Agenta dobrze robi nie to, co trzeba. Specyfikacja zostawiła pole do interpretacji. Zamknij pull request, dopisz do specyfikacji brakujące kryterium jako nieprzechodzący test i uruchom zadanie ponownie. Nie poprawiaj pull requesta ręcznie: kolejne uruchomienie tej samej specyfikacji powtórzy błąd.

Agent bez nadzoru wykonuje polecenia ukryte w zgłoszeniu albo na stronie WWW. Treść zgłoszeń i pobrane strony to niezaufane dane wejściowe. Agentów z Automations trzymaj na serwerach MCP tylko do odczytu, nie dawaj im poświadczeń produkcyjnych i wymagaj merge’u przez człowieka dla wszystkiego, co otwierają.

Zużycie tokenów skacze po dodaniu serwerów albo reguł. Każdy włączony serwer MCP i każda reguła stosowana zawsze kosztuje kontekst w każdym zapytaniu. Wyłącz serwery, których zadanie nie używa, zawęź reguły globami i porównaj zużycie tokenów na zadanie przed zmianą i po niej.

Dokąd iść po wskazówkach 91-105

Poprzednio w serii: strategie dla dużych baz kodu.
Dalej w serii: współpraca zespołowa w Cursorze, czyli jak udostępnić te reguły, skille i serwery MCP całemu zespołowi.
Więcej o pracy bez nadzoru: Cloud Agents i Automations oraz własne serwery MCP dla Cursora.
Standard tego, czego musi dowodzić pull request: pakiet dowodów.