Praca z czatem agenta w Cursorze

Czat agenta w Cursorze daje wiarygodne zmiany w wielu plikach, gdy prompt zawiera definicję ukończenia, którą agent sam sprawdzi: zatwierdzone, na razie nieprzechodzące testy, komendy bramkujące wynik i dowody do zaraportowania. Wtedy zmianę oceniają testy i kontrola typów, a czat, który utknął, zaczyna się od nowa, zamiast się z nim spierać.

Wpisujesz agentowi Cursora „dodaj zaproszenia do organizacji”. Dwadzieścia minut później masz moduł zaproszeń z własnym formatem błędów, bez middleware uprawnień, którego używają pozostałe trasy, i z testem „naprawionym” przez zmianę asercji. Czat ma już 30 wiadomości, każda poprawka pogarsza sytuację, a bez czytania 600 linii nadal nie wiesz, czy funkcja działa.

Ta strona jest dla programistów, którzy codziennie oddają agentowi Cursora zadania wielkości funkcji. Dotyczy samego czatu: jak go zacząć, co wpisać do prompta, jak sprawdzić wynik i kiedy czat wyrzucić. Opisuje linię Cursor 3.x; aktualne wydanie na 2026-10-12 to Cursor 3.24 (2026-10-09, informacje o wydaniu Cursora). Plan Mode, Rules, Hooks, Worktrees, Subagents, Cloud Agents i /goal sprawdziliśmy w dokumentacji Cursora po raz pierwszy 28 sierpnia 2026. Pomoc i dokumentacja Cursora, sprawdzone 2026-10-12, podają, że Cmd+I (Ctrl+I w Windows i Linuksie) otwiera panel Agenta, a Shift+Tab przełącza tryby po kolei, że tryby uruchamiania to Auto-review, Allowlist i Run Everything (Settings > Agents > Approvals & Execution) oraz że Cursor nie wskazuje jednego modelu domyślnego. Skróty i tryby uruchamiania zmieniają się między wydaniami, więc potwierdź je w swoim buildzie.

Co daje dobrze prowadzony czat agenta w Cursorze

• Pętlę siedmiu kroków, która prowadzi jedno zadanie od prośby do pull requesta z własnymi dowodami.
• Pięć gotowych promptów: funkcja zaczynana od testów, rozpoznanie w Plan Mode, debugowanie ze stack trace, migracja plik po pliku i bramka przed PR.
• Komendę git, która dowodzi, że agent nie osłabił zatwierdzonych przez ciebie testów.
• Jasne sygnały, kiedy nadzorować czat, kiedy pozwolić mu działać, a kiedy przerwać i zacząć od nowa.

Jak jeden czat agenta prowadzi od prośby do sprawdzonej zmiany?

Każde zadanie na tej stronie przechodzi tę samą pętlę. Najczęściej pomijane są kroki 3 i 6, a to właśnie one sprawiają, że wynik da się udowodnić.

1. Zawęź zadanie do jednego rezultatu. Jedna funkcja, jeden błąd albo jeden krok migracji na czat. Jeśli nie umiesz jednym zdaniem powiedzieć, jak wygląda „gotowe”, zadanie jest za duże albo jeszcze niezrozumiane.
2. Zakotwicz je w swoim kodzie. Dołącz przez @ plik, który już poprawnie robi to samo, oraz pliki, których zmiana musi dotknąć. Zarządzanie kontekstem w Cursorze opisuje, co dołączać, a co zostawić wyszukiwaniu agenta.
3. Ustal definicję ukończenia. Poproś najpierw o nieprzechodzące testy, przeczytaj je i zacommituj. To one są specyfikacją; implementacją jest to, co sprawi, że przejdą.
4. Wpisz bramki do prompta. Podaj dokładne komendy, które agent uruchamia po każdej zmianie: testy, kontrola typów, lint.
5. Poproś o raport z dowodami. Zmienione pliki, wynik komend, założenia. „Gotowe” bez wyniku komend nie jest gotowe.
6. Sprawdź dowody, nie diff. Potwierdź, że zatwierdzone testy się nie zmieniły, bramki są zielone, a raport odpowiada zadaniu.
7. Zamknij czat. Zacommituj zmiany, napisz notatkę przekazania, jeśli praca trwa dalej, i zacznij kolejne zadanie w nowym czacie.

Zapisz definicję ukończenia, zanim agent napisze kod

Najskuteczniejsza zmiana w czacie z agentem to kolejność: najpierw testy, potem implementacja. Testy napisane przed kodem opisują zachowanie, o które prosisz. Testy napisane po kodzie opisują to, co agent akurat zbudował, więc przechodzą z definicji i niczego nie dowodzą.

Wyślij prompt w dwóch turach. Pierwsza kończy się na testach, żebyś mógł je przeczytać, zanim powstanie jakakolwiek implementacja.

Gotowy prompt: funkcja zaczynana od testów, tura pierwsza

Feature: organisation invites.

Acceptance criteria:
- POST /api/orgs/:orgId/invites with a valid email returns 201 and stores a
  pending invite that expires in 7 days.
- An email that is already a member returns 409 in the error format from
  @src/lib/errors.ts.
- A caller who is not an org admin returns 403 (use requireOrgRole from
  @src/middleware/auth.ts).
- POST /api/invites/:token/accept adds the user to the org and marks the
  invite accepted; an expired token returns 410.

Write ONLY the tests now, in src/routes/__tests__/invites.test.ts, following
the structure of @src/routes/__tests__/members.test.ts. One test per criterion,
plus one for the expired token. Run `npx vitest run src/routes/__tests__/invites.test.ts`
and confirm every test fails for the right reason (missing route or handler,
not a syntax or import error). Do not create any implementation file.
Report: the test names and the failure message for each.

Czytaj nazwy testów i asercje, nie kod przygotowujący. Każda asercja powinna odpowiadać jednemu kryterium. Jeśli któregoś brakuje albo jest za słabe (na przykład sprawdza kod statusu, ale nie to, że zaproszenie zostało zapisane), powiedz to teraz. Potem zacommituj same testy:

git add src/routes/__tests__/invites.test.ts
git commit -m "test: spec for organisation invites"
git tag spec-invites

Ten commit to umowa, a lokalny tag spec-invites go oznacza, żebyś mógł później porównać z nim zmiany. Druga tura implementuje funkcję zgodnie z tą umową.

Gotowy prompt: funkcja zaczynana od testów, tura druga

The tests in src/routes/__tests__/invites.test.ts are committed and approved.
Implement the feature until they pass.

Anchor: follow @src/routes/members.ts for route structure, validation and
error handling. Store invites through a new table defined next to the members
table in @src/db/schema.ts.

Rules:
- Do NOT edit, skip or delete any test. If you believe a test is wrong,
  stop and explain why instead of changing it.
- Do NOT touch files outside src/routes/, src/db/ and src/services/.

After each change run:
1. npx vitest run src/routes
2. npx tsc --noEmit
3. npm run lint
Iterate until all three pass.

Report: files changed, the last 15 lines of each command's final output,
and every assumption you made.

Pełna dyscyplina pracy od testów, łącznie z testami mutacyjnymi, które dowodzą, że testy wyłapią błąd, jest opisana w TDD w Cursorze. Format kryteriów akceptacji pochodzi z wykonywalnych kryteriów akceptacji.

Użyj Plan Mode, gdy nie umiesz jeszcze napisać testu akceptacyjnego

Niektóre zadania zaczynają się od pytania, nie od specyfikacji: „jak dodać rozliczanie za użycie?”. Jeśli nie umiesz napisać kryteriów akceptacji, nie jesteś gotów na testy, a agent nie jest gotów do edycji kodu. Plan Mode w Cursorze tworzy szczegółowy plan implementacji, zanim powstanie jakikolwiek kod (w dokumentacji: „creates detailed implementation plans before writing any code”), a gotowy plan jest dokumentem, który możesz poprawić, zanim cokolwiek zostanie zbudowane. Przed wysłaniem prompta przełącz czat w Plan Mode; jak to zrobić, pokazują tryby agenta w Cursorze.

Gotowy prompt: rozpoznanie w Plan Mode

Plan, do not implement: we need usage-based billing for API calls.

Research @src/api/ and @src/services/billing/ first. Then produce a plan with:
1. The files that change and the files that are new, with one line each on why.
2. The order of work, as steps small enough that each ends with a passing
   test run.
3. The acceptance criteria for each step, written so each one becomes a test.
4. Every open question you cannot answer from the code (pricing rules,
   rounding, what happens when metering is late). Ask them; do not guess.
5. What you will NOT change.

Poprawiaj plan, aż kryteria będą takie, pod którymi byś się podpisał. Potem buduj jeden krok na czat, używając promptów zaczynanych od testów z kryteriami danego kroku. Plan, którego nie da się przejrzeć w pięć minut, jest za duży, żeby zbudować go w jednym czacie. Tryby agenta w Cursorze porównują Plan Mode z innymi sposobami rozpoczęcia czatu.

Wpisz bramki do prompta i poproś o dowody

Prompt, który kończy się opisem funkcji, zostawia weryfikację tobie. Prompt, który kończy się komendami do uruchomienia i dowodami do zaraportowania, każe weryfikować agentowi, a twój przegląd zamienia w czytanie jego wyników. Dobierz bramkę do zadania:

Zadanie	Bramka, którą uruchamia agent	Dowód, który sprawdzasz
Nowa funkcja	Zatwierdzone testy, cały zestaw, kontrola typów, lint	Zatwierdzony plik testów bez zmian; wszystko zielone
Poprawka błędu	Nowy nieprzechodzący test odtwarzający błąd, potem cały zestaw	Test nie przechodził przed poprawką i przechodzi po niej
Refaktoryzacja	Istniejący zestaw testów bez zmian; kontrola typów	Żadnego pliku testów w diffie; publiczne eksporty bez zmian
Krok migracji	Testy jednego migrowanego pliku; cały zestaw	Zmienił się tylko wskazany plik i jego importy
Aktualizacja zależności	Cały zestaw, kontrola typów, build	Wynik buildu i pozycje z changelogu, które agent sprawdził

To, czy agent uruchamia te komendy bez pytania, zależy od trybu uruchamiania. Kontrolę terminala Cursor opisuje na stronie dokumentacji Run modes (sekcja Agent security); zostaw dozwolone komendy testów, kontroli typów i lintu, a wszystko, co wypycha zmiany, usuwa pliki albo sięga do sieci, trzymaj za zatwierdzeniem. Prywatność i bezpieczeństwo Cursora w zespole omawia to ustawienie krok po kroku.

Debuguj na podstawie dowodów z działania, nie opisu

„Webhook czasem się wywala” nie daje agentowi niczego do przetestowania. Stack trace i sposób odtworzenia dają mu ścieżki plików, numery linii i błąd, który może usunąć. Zabroń edycji kodu, dopóki nieprzechodzący test nie odtworzy błędu; wiarygodnie brzmiące wyjaśnienie złej przyczyny wygląda dokładnie tak samo jak poprawne.

Gotowy prompt: debugowanie ze stack trace

Production error from our logs:

TypeError: Cannot read properties of undefined (reading 'email')
    at processWebhook (src/api/webhooks/stripe.ts:47:28)
    at handleRequest (src/middleware/router.ts:112:5)

It happens on customer.subscription.updated events.

Phase 1, no source edits:
- Read @src/api/webhooks/stripe.ts and the event types it handles.
- List up to three candidate causes with the evidence for and against each.
- Write one failing test in src/api/webhooks/__tests__/stripe.test.ts that
  reproduces the error with a realistic event payload. Run it and show it fails
  with this TypeError.

Stop and wait for my go-ahead.

Phase 2, after I approve the test: fix the handler so the test passes, run
`npx vitest run src/api/webhooks` and `npx tsc --noEmit`, and report the
root cause in two sentences.

Gdy błąd pojawia się tylko pod obciążeniem albo przy określonym przeplocie zdarzeń, dodaj tymczasowe logowanie, odtwórz błąd samodzielnie i wklej logi do czatu, a potem każ agentowi usunąć logowanie w tym samym czacie. Polowanie na błędy z Cursorem omawia przypadki niedeterministyczne.

Migruj jeden plik naraz

„Przenieś API z Express na Hono” w jednym prompcie daje diff, którego nikt nie sprawdzi. Jeden plik na krok, każdy z własnymi testami, daje ciąg małych diffów, w którym pierwszy ustala wzorzec dla reszty.

Gotowy prompt: jeden krok migracji

We are migrating our HTTP layer from Express to Hono, one route file at a time.

This step: @src/api/health.ts only. Convert it to Hono, register it in
@src/server.ts next to the remaining Express routes, and keep the URL and the
response body identical.

Do NOT change any other route file.
Run `npx vitest run src/api` and `npx tsc --noEmit`.
Report: the diff summary (`git diff --stat`) and the test output.
Then write the conversion pattern you used as five bullet points, so the next
chat can apply it to the next file.

Commituj po każdym kroku. Kolejny plik zacznij w nowym czacie, z pięcioma punktami wzorca i zmigrowanym plikiem dołączonym jako kotwica: Convert @src/api/users.ts following the pattern in @src/api/health.ts. Duże migracje prowadzone jako program opisuje strona migracje z Cursorem.

Uruchom bramkę przed PR, nie pozwalając agentowi zmieniać testów

Zakończ zadanie jednym przebiegiem, który przygotowuje gałąź do review. Najważniejsza jest reguła o plikach testów: agent, któremu każesz „sprawić, żeby testy przeszły”, zmieni asercje, jeśli nic go nie powstrzyma.

Gotowy prompt: bramka przed PR

Prepare this branch for review against main.

1. Run `npx tsc --noEmit` and fix every type error.
2. Run `npm run lint` and fix every issue.
3. Run `npx vitest run` and fix failures in the SOURCE code only. Do not modify
   any test assertion, skip a test, or delete a test. If a test looks wrong,
   list it with your reasoning and leave it failing.
4. Remove debug logging added on this branch.
5. Run all three commands again.

Report as a table: check, final status, what you changed to get there.
Then list anything a reviewer should look at first, with file and line.

Jak sprawdzić wynik czatu bez czytania każdej linii?

Sprawdzasz cztery dowody, w tej kolejności, i czytasz kod tylko tam, gdzie któryś z nich cię kieruje.

1. Zatwierdzone testy się nie zmieniły. Ta komenda nic nie wypisuje, gdy pliki testów i konfiguracja test runnera są takie jak w zatwierdzonym commicie:

   git diff --stat spec-invites -- '*.test.ts' '*.spec.ts' 'vitest.config.*' package.json

   spec-invites to tag ustawiony na commicie ze specyfikacją; porównanie obejmuje też niezacommitowane zmiany. Każdy wynik oznacza, że agent dotknął specyfikacji albo sposobu jej uruchamiania: ten fragment przeczytaj w pierwszej kolejności. Komenda nie pokazuje nowych plików, więc uruchom też git status --short, żeby zobaczyć nowe, nieśledzone pliki.

2. Bramki są zielone na twojej maszynie. Uruchom testy, kontrolę typów i lint samodzielnie, zamiast ufać zacytowanemu wynikowi. Zajmuje to kilka sekund i wyłapuje raport skopiowany z wcześniejszego przebiegu.

3. Diff mieści się w wyznaczonych granicach. git diff --stat main powinien pokazać tylko dozwolone katalogi. Plik spoza nich to albo pominięta zależność (w porządku, jeśli raport ją wyjaśnia), albo rozrost zakresu (cofnij go).

4. Założenia z raportu są do przyjęcia. Każde wymienione założenie to decyzja, którą agent podjął za ciebie. Odrzuć te, których sam byś nie podjął.

Kto zatwierdza: ty akceptujesz testy przed implementacją, bo to one są specyfikacją. Pull request niesie potem dowody, a recenzent i automatyczny recenzent, taki jak Bugbot, sprawdzają, czy odpowiadają zadaniu. Format tych dowodów opisuje pakiet dowodów.

Kiedy nadzorować czat, a kiedy pozwolić mu działać?

Poziom nadzoru zależy od tego, jak dobrze zadanie jest wyspecyfikowane, a nie od tego, jak bardzo ufasz modelowi.

Sytuacja	Jak to prowadzić
Są zatwierdzone testy, bramki w prompcie i wyznaczony zakres	Pozwól mu działać; sprawdź dowody, gdy zaraportuje
Niejasne kryteria akceptacji	Najpierw Plan Mode, potem budowanie krok po kroku
Dotyka uwierzytelniania, płatności, usuwania danych albo migracji na wspólnych danych	Nadzoruj każdy krok; zatwierdzaj każdą komendę, która nie jest testem ani kontrolą
Długa, dobrze wyspecyfikowana praca, której nie musisz obserwować	Cloud Agent, który działa w izolowanej maszynie wirtualnej w chmurze z pełnym środowiskiem deweloperskim
Dwa zadania lub więcej naraz	Osobny Worktree na każde zadanie, żeby agenci nigdy nie dzielili jednego checkoutu
Cel ze sprawdzalnym warunkiem końca, np. „wszystkie testy w src/api przechodzą”	/goal, wciąż udostępniany stopniowo (dokumentacja Cursora, sprawdzone 2026-10-12); zobacz komendę /goal

Cursor 3.24 (2026-10-09) dodał znacznik Goal nad polem prompta. Od 2026-08-19 kolejne wiadomości sterują agentem: changelog Cursora podaje „Follow-ups wait for the next tool call instead of cutting the agent off mid-action” („kolejne wiadomości czekają na następne wywołanie narzędzia, zamiast przerywać agenta w pół akcji”).

Trzy dalsze elementy sterowania czatem z pomocy i dokumentacji Cursora (sprawdzone 2026-10-12):

• Enter ustawia wiadomość w kolejce; Send a follow-up now steruje bieżącą turą przy następnym wywołaniu narzędzia przez agenta.
• /side albo /btw uruchamia czat boczny.
• Każdy skill z poprawnym blokiem frontmatter może stać za trybem Custom Mode, który „keeps the skill in context for the whole session” („utrzymuje skill w kontekście przez całą sesję”).

Agent Cursora może też delegować pracę do subagentów, czyli wyspecjalizowanych asystentów AI, którym agent Cursora może delegować zadania (w dokumentacji: „specialized AI assistants that Cursor’s agent can delegate tasks to”). Delegowanie pomaga, gdy podzadanie, na przykład przeszukanie dużej bazy kodu, zapełniłoby główny czat materiałem, którego reszta zadania nie potrzebuje.

Kiedy przerwać czat i zacząć od nowa?

Czat to okno kontekstu. Każda nieudana próba, ślepa uliczka i nieaktualny plan zostają w nim, a agent dalej na nich rozumuje. Przerwij i zacznij od nowa, gdy zobaczysz którykolwiek z tych sygnałów:

• Agent powtarza ten sam błąd po dwóch twoich poprawkach.
• Edytuje pliki, których kazałeś mu nie ruszać.
• Zmienia test, żeby przeszedł.
• Jego odpowiedzi przestają odnosić się do twojego kodu i robią się ogólnikowe.
• Nie pamiętasz już, które jego zmiany zaakceptowałeś.

Najpierw przywróć ostatni dobry stan. Cofnij się do ostatniego commita przez git restore lub git reset albo, jeśli twoja wersja Cursora oferuje checkpointy, przywróć jeden z nich (zobacz checkpointy i gałęzie). Potem otwórz nowy czat i wpisz porażkę do prompta, żeby nowy czat jej nie powtórzył.

Gotowy prompt: restart po nieudanym czacie

Previous attempt failed: the agent wrote raw SQL instead of using the Drizzle
query builder, and changed the assertion in invites.test.ts line 42.
All database access goes through @src/db/queries.ts. The tests in
src/routes/__tests__/invites.test.ts are approved and must not change.
Continue from: FAILED_STEP

FAILED_STEP to jedno zdanie z twojego planu. Gdy praca celowo przechodzi między czatami, zamknij stary czat notatką przekazania; prompt do niej znajdziesz w zarządzaniu kontekstem w Cursorze.

Co psuje się w czatach agenta Cursora i jak to naprawić

Agent zmienił test, żeby przeszedł

Objaw: zestaw testów jest zielony, a opisana wyżej komenda git diff pokazuje plik testów. Naprawa: git checkout spec-invites -- src/routes/__tests__/invites.test.ts, a potem powiedz agentowi, że test jest przywrócony i zatwierdzony, więc ma zmienić kod źródłowy. Jeśli zdarzy się to drugi raz, zapisz tę zasadę w regule projektu, żeby każdy czat zaczynał się od niej (reguły projektu w Cursorze).

Agent krąży między dwoma błędami. Naprawia test A, psuje test B, naprawia B, psuje A. Zatrzymaj go. Taka pętla zwykle oznacza, że dwa testy kodują sprzeczne wymagania albo agent walczy z własną wcześniejszą zmianą. Wróć do ostatniego zielonego commita, zdecyduj, które wymaganie wygrywa, i zacznij od nowa z tą decyzją w prompcie.

Kod działa, ale ignoruje twoje konwencje. Brakuje kotwicy albo konwencji nie widać w kodzie. Dołącz plik-kotwicę przez @. Jeśli konwencji nie da się pokazać kodem (na przykład „nigdy nie wołaj serwisu płatności z handlera trasy”), zapisz ją w regule projektu.

Agent używa nieaktualnego API biblioteki. Dane treningowe modelu są starsze niż twoja zależność. Podaj agentowi zainstalowaną wersję (z package.json) i każ mu sprawdzić aktualną dokumentację przed pisaniem kodu albo dodaj serwer MCP z dokumentacją, taki jak Context7 (pakiet npm @upstash/context7-mcp, wersja 4.1.1 na 26 września 2026). Strona o Context7 podaje taki wpis serwera zdalnego do ~/.cursor/mcp.json; nagłówek Authorization z kluczem Context7 dodaj, jeśli potrzebujesz wyższych limitów zapytań:

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

Ogólną konfigurację opisuje konfiguracja MCP w Cursorze.

Zmiana rozlała się po całej bazie kodu. Prompt nie wyznaczył granic. Cofnij pliki spoza granic przez git restore <ścieżka> i dodaj do kolejnego prompta wyraźną linię „Do NOT touch files outside …”.

Agent uruchomił komendę, której nie chciałeś. Pozwolił mu na to tryb uruchamiania. Najpierw odwróć skutek (cofnij pliki, odtwórz lokalną bazę z migracji), potem zaostrz ustawienie tak, żeby ta komenda następnym razem wymagała zatwierdzenia.

Dokąd dalej po czatach agenta w Cursorze

• Pierwsza funkcja z pomocą AI, jeśli jeszcze nie przeprowadziłeś jednej funkcji przez Plan Mode i testy od początku do końca.
• Szablony promptów dla agenta Cursora, żeby zapisać prompty z tej strony jako komendy lub skille wspólne dla całego zespołu.
• Strategie dla dużych baz kodu, gdy agent nie mieści w kontekście wystarczającej części projektu, żeby wykonać te prompty.
• Okno Agents i Projects w Cursorze, żeby prowadzić kilka takich czatów równolegle.
• Ta sama pętla w terminalu: praca na wielu plikach w Claude Code i prompt engineering dla Codexa.