Prompty do Claude Code i Cursor: 7 promptów, które dają gotowy diff, a nie kolejną odpowiedź na pytanie 

Agent kodujący daje gotowy diff wtedy, gdy prompt zawiera trzy rzeczy: granice, wzorzec i kryterium akceptacji, które agent sam potrafi uruchomić. Bez nich Claude Code i Cursor kończą rozmowę tekstem - opisem co zrobili, propozycją albo pytaniem o wyjaśnienie. Poniżej siedem promptów, które przesuwają pracę z twojej głowy na pliki w repozytorium, plus konfiguracja, w której te instrukcje przestają być twoim problemem.

Czym różni się prompt, który kończy się diffem

Claude potrafi wywnioskować intencję, ale nie umie czytać w myślach - to sformułowanie z jego własnej dokumentacji. Prompt w rodzaju „popraw walidację” zostawia mu cztery pytania otwarte: które pliki, jaki styl, co uważasz za poprawne i kiedy skończyć. Na każde z nich odpowiada pytaniem, więc rozmowa rozkłada się na dziesięć wiadomości i ani jednego commita.

Gotowy diff pojawia się, gdy odpowiedzi na te cztery pytania są w prompcie albo w pliku konfiguracyjnym, z którego agent je czyta przy każdym starcie. Sama technika promptowania przestała być wąskim gardłem - liczy się to, czy agent ma się na czym oprzeć.

Prompt 1: najpierw zakres, potem zadanie

Najbardziej wpływowy wzorzec według testujących to agenty na produkcyjnym kodzie to zdefiniowanie zakresu przed opisaniem zadania. Pięć sekund pisania, a eliminuje najczęstszy tryb awarii: zmiany w miejscach, których nie prosiłeś.

Pracuj w: src/api/routes/orders.ts, src/api/validators/order.ts
Zadanie: dodaj walidację kodu pocztowego w formularzu zamówienia.
Trzymaj się wzorca z src/api/routes/users.ts - tam jest obsługa błędów.
Nie dotykaj żadnych innych tras ani plików.

Zdanie o wykluczeniu jest tu ważniejsze, niż się wydaje. Agent bez niego traktuje każdy task jako zaproszenie do refaktoru, a po kilku takich turach różnica między gałęzią a twoim zamiarem jest już nie do odzyskania.

Prompt 2: wskaż wzorzec, który ma zostać skopiowany

Agenty dobrze rozpoznają wzorce, więc jeden kanoniczny przykład z twojego repozytorium daje więcej niż akapit opisu. Dokumentacja Anthropic jest wprost przeciwko wklejaniu listy wszystkich edge case'ów w prompt - zamiast tego zaleca zbieranie zróżnicowanych, reprezentatywnych przykładów.

Idź dokładnie według wzorca endpointu GET /users/:id w src/api/routes/users.ts.
Ten sam sposób obsługi błędów, ten sam format odpowiedzi, ta sama kolejność middleware.

Gdy nie masz gotowego pliku do wskazania, daj szkielet z komentarzami. Nawet prymitywny szkielet komunikuje więcej niż dwa akapity słów.

Prompt 3: daj kryterium akceptacji, które agent sam uruchomi

To jest ta pojedyncza zmiana, która zmienia charakter pracy z sesji, którą obserwujesz, w przebieg, który kończy się sam. Dokumentacja Claude Code mówi o tym wprost: daj mu coś, co daje pass lub fail, i pętla zamknie się bez Ciebie.

Napisz funkcję walidującą adres e-mail.
Przypadki testowe: user@example.com -> true, invalid -> false, user@.com -> false.
Po implementacji uruchom testy.

Do tego dokładanie pięciu słów. Bez „po implementacji uruchom testy” agent napisze funkcję, pokaże Ci kod i uzna sprawę za zamkniętą - bo nikt mu nie powiedział, że ma coś uruchomić.

Blok weryfikacyjny rozbudowujesz o komendy, które faktycznie używasz w projekcie:

Po zmianach:
1. Uruchom npm test, żeby istniejące testy nadal przechodziły.
2. Dodaj testy dla ponowień w src/lib/__tests__/api-client.test.ts.
3. Uruchom nowe testy i potwierdź, że przechodzą.
4. Uruchom npm run lint i napraw zgłoszone problemy.

Drugi wariant jest mocniejszy, bo zmusza do napisania testu, który najpierw pada. Dokumentacja podaje to wprost: napisz test odtwarzający błąd, potem napraw go. Agent dostaje wtedy punkt odniesienia zamiast ogólnej prośby o poprawę. Ten sam mechanizm działa przy interfejsach - wklej zrzut projektu, popisz zaimplementuj go, zrób zrzut efektu i wypisz różnice.

I jedno zdanie, które oszczędza najwięcej czasu: poproś o dowód, nie o deklarację. Wynik testu, uruchomione polecenie, zrzut ekranu. Przeglądanie dowodu jest szybsze niż powtórna weryfikacja, i działa też przy przebiegach, których nie oglądałeś.

Prompt 4: test najpierw, kod potem

Cursor opisuje to wprost jako TDD z wyraźnym zastrzeżeniem, że agent musi wiedzieć, że to TDD - inaczej zaczyna pisać atrapy funkcji, których jeszcze nie ma.

Najpierw napisz testy na podstawie oczekiwanych par wejście/wyjście.
To jest TDD - na tym etapie nie pisz kodu implementacji.
Uruchom testy i pokaż, że padają.
Potem napisz kod, który je przechodzi. Testów nie zmieniaj.
Powtarzaj, aż wszystkie przejdą.

Zakaz modyfikowania testów jest tu nie ozdobnikiem. Bez niego agent po prostu przerabia asercje pod swoją implementację, a zielony test przestaje cokolwiek znaczyć.

Prompt 5: napisz, czego agent nie ma robić

Czasem najważniejsza część promptu to zakazy. Prompty ograniczające sprawdzają się przy refaktorach i sprzątaniu, czyli dokładnie wtedy, gdy agent ma tendencję do nadmiernej ambicji.

Nie modyfikuj plików poza src/legacy/.
Nie zmieniaj sygnatur funkcji ani eksportów.
Nie dodawaj nowych zależności bez pytania.
Zachowaj istniejące pokrycie testami.

Te cztery linie działają jak bariera: agent nie zepsuje Ci powierzchni API ani nie uruchomi kaskady zmian po całym repozytorium.

Prompt 6: każ agentowi znaleźć kod samemu

Tu dokumentacje rozchodzą się i warto zobaczyć obie strony. Claude Code mówi, żeby wskazywać pliki symbolem @, i opisuje to jako bezpieczniejsze. Cursor mówi wprost, że nie musisz oznaczać każdego pliku, a nierelewantne pliki w kontekście dezorientują agenta co do tego, co ważne - i dodaje, że sam znajduje odpowiednie pliki przez grep i wyszukiwanie semantyczne, nawet gdy w prompcie nie padnie ani jedna nazwa pliku.

Rozstrzyga to nie wybór narzędzia, a decydanie, co jest instrukcją, a co materiałem. Instrukcje stałe wchodzą do kontekstu na starcie. Materiał do wczytania lepiej zostawić agentowi.

Użyj subagentów, żeby zbadać, jak w tym repozytorium działa odświeżanie tokenów
i czy mamy już jakieś narzędzia OAuth, które powinienem wykorzystać.
Wynik zapisz do UZYTKOWNIK.md. Implementacji nie ruszaj.

Delegowanie ma policzalną cenę: jeden subagent potrafi przejrzeć dziesiątki tysięcy tokenów kodu i wrócić z 1000-2000 tokenami streszczenia. U mnie na warsztatach to najczęstszy powód, dla którego pierwsza sesja kończy się lepszym diffem niż piąta - kontekst głównej rozmowy zostaje czysty na implementację. Efekt widziałem przy pięciu projektach, które agent wygenerował i wdrożył za klienta: research osobno, implementacja osobno, zero mieszania.

Prompt 7: popraw plan, a nie follow-up

Tu zaczyna się najbardziej zaniedbywany fragment pracy z agentem. Claude Code ma tryb planu - Shift+Tab albo claude --permission-mode plan - w którym czyta pliki i odpowiada na pytania bez robienia zmian, a Ctrl+G otwiera plan w edytorze tekstu do poprawki przed startem.

Przeczytaj src/auth i zrozum, jak trzymamy sesje oraz zmienne środowiskowe.
Chcę dodać logowanie Google. Jakie pliki trzeba zmienić?
Jaki jest przepłyg sesji? Zapisz plan.

W Cursorze plany są plikami Markdown, które edytujesz wprost, a „Save to workspace” zapisuje je w katalogu .cursor/plans/ - zostaje dokumentacja dla zespołu i możliwość wznowienia przerwanego zadania.

Reguła z dokumentacji brzmi: jeśli zdasz diff jednym zdaniem, plan możesz pominąć. Cursor używa ostrożniejszej wersji - planowanie to najbardziej wpływowa zmiana, jaką możesz zrobić, ale nie każde zadanie go potrzebuje. Praktycznie: przy poprawce literówki plan to szum, przy zmianie dotykającej kilku plików plan oszczędza więcej, niż kosztuje.

Co przenieść z promptu do pliku

Jeśli piszesz tę same komendy weryfikacyjne za trzecim razem, to nie są już informacje, tylko instrukcja. Claude Code czyta CLAUDE.md na starcie każdej rozmowy, a Cursor traktuje reguły jako kontekst obecny od pierwszej wiadomości. Dokumentacja obu podaje tę samą zasadę: trzymaj plik krótkim, bo długi plik zużywa kontekst i obniża posłuszeństwo.

Plik	Po co	Limit
CLAUDE.md	komendy, styl, reguły repozytorium	poniżej 200 linii na plik
.claude/rules/	reguły warunkowe, ładowane tylko przy pasujących plikach	1000 rozwiniętych wzorców i 4 MiB na listę ścieżek
import @sciezka	łączenie plików instrukcji	4 poziomy zagnieżdżenia
auto memory	notatki pisane przez agenta z Twoich poprawek	200 linii albo 25 KB
.cursor/rules/	kontekst obecny od pierwszej wiadomości	krótko: wskazania do plików, nie ich kopie
.cursor/commands/	powtarzalne przepływy w wersji kontrolnej	brak limitu w źródłach

Pliki pilnujesz sam, ale są do tego narzędzia. /init generuje pierwszy CLAUDE.md na podstawie struktury projektu, /context potwierdza, że agent plik faktycznie wczytał, a /doctor prompt-audit szuka instrukcji napisanych pod starszy model, odwołań do nieistniejących plików i sprzeczności między plikami - raport dostajesz, a pliki zostają nietknięte, dopóki nie poprosisz o zastosowanie zmian. Jedna uwaga o akcentowaniu: jeśli agent pomija jedną instrukcję, dodaj słowo IMPORTANT w tym jednym wierszu. Wyróżnienie pięciu wierszy nie wyróżnia żadnego.

Kiedy prompt przestaje wystarczać

Instrukcje w CLAUDE.md są doradcze - model je czyta, ale nie musi się do nich stosować. Hooki są deterministyczne i wykonują się niezależnie od decyzji agenta. Dokumentacja podaje konkretne bramki: Stop hook odpala Twoją komendę i nie pozwala zakończyć tury, dopóki nie przejdzie; PreToolUse blokuje zapis w konkretnym katalogu.

Prompt: Napisz hook, który uruchamia eslint po każdej edycji pliku.
Prompt: Napisz hook, który blokuje zapis w katalogu migrations.

Cursor ma gotowy wzorzec tego samego w .cursor/hooks.json - skrypt podpięty do zdarzenia stop, z limitem 5 iteracji i komunikatem kontynuacji. Zastosowania, które podaje sam Cursor: doprowadzanie testów do przejścia, iterowanie nad wyglądem do zgodności z makietą i każde zadanie, gdzie sukces da się sprawdzić. Praktycznie to najlepszy sposób na przebieg autonomiczny, bo łączy kryterium z promptu 3 z bramką, której model nie da się przekonać.

Dwa polecenia warto znać, bo inaczej przerywanie pracy zjada więcej czasu niż samo pisanie kodu: /permissions zatwierdza narzędzia, którym ufasz, a /sandbox pozwala, by polecenia w piaskownicy leciały bez pytania. W trybie ręcznym po dziesiątej akceptacji klikasz już bez czytania - a to jest dokładnie ten sam mechanizm, który przy zasadzie mniej uprawnień przy prompt injection decyduje, ile agent może naprawdę.

Cztery prompty, które psują wynik

Antwzorce są mniej efektowne niż techniki, ale oszczędzają najwięcej. Pierwszy to prompt wszystko-na-raz: żaden agent nie zrobi tego dobrze w jednym przebiegu, duże zadania zawodzą częściej nie dlatego, że są za trudne, tylko dlatego, że błędy się kumulują - przy 20 zmienionych plikach masz 20 okazji do potknięcia. Drugi to prompt bez kontekstu: nie opisuj, co nie działa i gdzie. Trzeci to wklejanie dokumentacji biblioteki, którą agent już zna. Czwarty to setki follow-upów zamiast resetu - jeśli poprawiałeś ten sam problem więcej niż dwa razy, kontekst jest pełen nieudanych podejść i czysta sesja z lepszym promptem wygrywa prawie zawsze. W procesach, które automatyzuję, ten sam mechanizm widać z drugiej strony: pięć automatyzacji, które się nie udały, powstało prawie zawsze przy tym samym błędzie - zamiast jednej konkretnej instrukcji dostaliśmy ogólną.

Ten ostatni punkt jest jedynym miejscem, gdzie blog branżowy i dokumentacja wprost się różnią. Testujący piszą, że agent pamięta wcześniejszą rozmowę i nie trzeba się powtarzać. Claude Code mówi coś odwrotnego, o ile granicą jest liczba poprawek na tym samym temacie. Rozdzielają je dwa kryteria: rodzaj zadania i to, czy iterujesz nad tą samą funkcją, czy już przeszedłeś do następnej.

Pierwsza sesja: co ustawić raz, zanim napiszesz pierwszy prompt

Kolejność ma znaczenie, bo każdy krok zdejmuje z kolejnych prac. Najpierw /init i jedna runda /doctor prompt-audit - bez tego agent pracuje na domyślnych założeniach. Potem /context, żeby potwierdzić, że instrukcje faktycznie weszły. Dopiero wtedy jeden hook weryfikacyjny, najlepiej ten, który odpala testy. Resztę plików instrukcji dodajesz w reakcji na konkretne błędy, nie na zapas, bo reguła, której agent nigdy nie złamał, tylko zabiera mu kontekst.

Przy pierwszym realnym zadaniu trzymam się progu z jednego zdania: jeśli potrafisz opisać diff w jednym zdaniu - pisz bez planu. Jeśli nie - wchodź w tryb planu, popraw plan, dopiero wtedy uruchamiaj pracę. I jeszcze jedno: agent powinien pokazać dowód, nie deklarację. Testy, uruchomione polecenie, zrzut ekranu. Krótko mówiąc, test 10 zadań biznesowych na agentach zaczyna się od tego samego pytania co każdy dobry test: po czym poznam, że to działa.

Uwaga dla tych, którzy dopiero zaczynają: te prompty sprawdzają się dopiero na realnym repozytorium z historią i testami. Na czystym projekcie demonstracyjnym każdy z nich da ten sam efekt, bo nie ma czego poprawiać. Jak zacząć od zera, opisałem to przy pierwszym dniu bez ściągawki. Jeśli chcesz przełożyć to na swój projekt - napisz do mnie, odpowiadam zwykle tego samego dnia.