O autorze

Jakub Stankowski – programista .NET i Angular od 2018 roku. Pracował nad projektami frontendowymi, backendowymi i fullstackowymi, przestrzegając zasad czystego kodu, DRY i stosując CQRS. Ma również doświadczenie jako trener programowania.

Od 2023 roku intensywnie pracuje z Claude AI oraz metodą Spec-Driven Development (SDD) – produkcyjnym workflow do pracy z AI opartym na zasadzie: najpierw specyfikacja, potem implementacja. Na ProgramujZAI.pl dzieli się praktyczną wiedzą o tym, jak programować z AI bez chaosu w kodzie.

Poznaj Jakuba →

Skuteczny prompt w Claude Code to nie dłuższy prompt — to prompt z trzema elementami: jasnym celem, kontekstem, którego Claude nie ma jeszcze w pamięci, i kryterium „gotowe”. Różnica między promptem, który generuje trafny kod za pierwszym razem, a takim, który uruchamia trzy rundy poprawek, rzadko leży w liczbie słów. Leży w tym, czy podałeś kontekst pliku CLAUDE.md zamiast powtarzać go w każdej wiadomości, czy poprosiłeś o plan przed implementacją, i czy określiłeś, jak wygląda „skończone”. W tym tutorialu pokazuję dokładną strukturę, której używam sam, oraz najczęstsze błędy, które sprawiają, że dobry model dostaje zły prompt i zwraca przeciętny kod.

Spis treści

• Dlaczego prompty w Claude Code rządzą się innymi zasadami niż prompty do czatu
• Kontekst najpierw: CLAUDE.md zamiast powtarzania konwencji
• Struktura skutecznego promptu: cel, kontekst, ograniczenia, format
• Stopniowanie zadania: od pytania, przez plan, do implementacji
• Custom slash commands jako reużywalne prompty
• Dobry prompt kontra zły prompt — porównanie
• Jak wdrożyć to w praktyce
• FAQ — najczęstsze pytania

Dlaczego prompty w Claude Code rządzą się innymi zasadami niż prompty do czatu

Prompt do Claude Code działa w innym środowisku niż prompt do zwykłego czatu, więc kopiowanie nawyków z ChatGPT rzadko się sprawdza. Claude Code ma dostęp do struktury projektu, historii commitów i wyników komend, więc część kontekstu, który normalnie trzeba by opisać słowami, model może po prostu odczytać z dysku.

Prompt inżynierski w tym środowisku to w praktyce zarządzanie tym, co Claude ma sam odkryć, a co musisz mu podać wprost. Jeśli konwencja nazewnictwa funkcji jest w kodzie, nie trzeba jej opisywać — wystarczy poprosić o przejrzenie istniejących plików. Jeśli konwencja jest tylko w Twojej głowie, żaden, nawet najdłuższy, opis zadania jej nie zastąpi bez jawnego zapisania.

To rozróżnienie — kontekst odkrywalny kontra kontekst niejawny — jest fundamentem dobrego promptowania i wraca w każdej kolejnej sekcji tego artykułu.

Kontekst najpierw: CLAUDE.md zamiast powtarzania konwencji

Plik CLAUDE.md eliminuje najczęstszą przyczynę słabych odpowiedzi: brak kontekstu projektu w momencie, gdy Claude zaczyna pracę. Claude Code wczytuje ten plik automatycznie na starcie sesji — zanim jeszcze wpiszesz pierwszą wiadomość — więc informacje w nim zapisane nie muszą trafiać do promptu wcale.

W praktyce chodzi o trzy poziomy tego pliku, które działają razem, od ogółu do szczegółu.

• Plik globalny (~/.claude/CLAUDE.md) — Twoje osobiste preferencje niezależne od projektu: styl wyjaśnień, ulubione narzędzia, sposób raportowania postępu.
• Plik projektowy (./CLAUDE.md w katalogu głównym repo) — konwencje konkretnego projektu: struktura katalogów, komendy testowe, zasady code review.
• Plik w podkatalogu — kontekst ograniczony do fragmentu kodu, np. osobne zasady dla katalogu /api czy /frontend.

Efekt praktyczny jest prosty do zmierzenia: prompt „dodaj endpoint do rejestracji użytkownika” w projekcie z dobrze opisanym CLAUDE.md wystarczy sam sobie, bo Claude wie już, jakiej struktury katalogów, walidacji i stylu testów oczekujesz. Bez tego pliku ten sam prompt wymaga dopisania kilku zdań kontekstu za każdym razem — a przy pracy zespołowej każdy członek zespołu musi je znać i powtarzać osobno.

Struktura skutecznego promptu: cel, kontekst, ograniczenia, format

Cztery elementy — cel, kontekst, ograniczenia i format wyniku — pojawiają się w każdym prompcie, który działa za pierwszym podejściem. Brak jednego z nich nie wywraca zadania, ale zwykle kosztuje dodatkową rundę poprawek, bo Claude musi zgadywać albo zapytać.

Cel to konkretny rezultat, nie ogólny kierunek. „Popraw wydajność” jest kierunkiem; „zmniejsz czas odpowiedzi endpointu listy zamówień poniżej 200 ms przy 10 tys. rekordów” jest celem.

Kontekst to informacje, których Claude nie odkryje sam z kodu — decyzje biznesowe, powody wcześniejszych wyborów architektonicznych, ograniczenia środowiska produkcyjnego.

Ograniczenia to granice rozwiązania: których bibliotek nie wolno dodawać, czy zmiana może dotykać schematu bazy danych, czy trzeba zachować wsteczną kompatybilność API.

Format wyniku mówi, czego oczekujesz na końcu — gotowego kodu z testami, samego planu do akceptacji, czy tylko diagnozy problemu bez zmian w plikach. To właśnie brak formatu najczęściej prowadzi do sytuacji, w której Claude od razu implementuje zmianę, choć chciałeś najpierw obejrzeć plan.

Stopniowanie zadania: od pytania, przez plan, do implementacji

Rozbicie dużego zadania na etapy daje lepsze wyniki niż jeden prompt próbujący ogarnąć wszystko naraz, bo każdy etap pozwala skorygować kierunek, zanim powstanie duża ilość kodu do poprawek. Trzy etapy, które sprawdzają się w praktyce, to: zrozumienie, plan, implementacja.

Na etapie zrozumienia proś Claude o przeanalizowanie istniejącego kodu i podsumowanie, zanim cokolwiek zmieni — to tani sposób na wyłapanie błędnych założeń po Twojej stronie, zanim staną się błędami w kodzie.

Na etapie planu poproś o listę kroków do akceptacji przed implementacją, szczególnie przy refaktorach obejmujących wiele plików. Tu przydają się słowa-klucze aktywujące rozszerzone rozumowanie — think, think hard i ultrathink — które w Claude Code zwiększają budżet tokenów przeznaczonych na analizę przed odpowiedzią. Im trudniejszy problem architektoniczny, tym bardziej opłaca się ten dodatkowy czas.

Na etapie implementacji, gdy plan jest już zaakceptowany, prompt może być krótki — sama zgoda na wykonanie wcześniej ustalonych kroków, bez powtarzania kontekstu.

Custom slash commands jako reużywalne prompty

Powtarzalny prompt zamieniony w slash command przestaje być czymś, co trzeba pamiętać i redagować za każdym razem. Jeśli codziennie prosisz Claude o to samo — przegląd kodu według standardów zespołu, sprawdzenie typów, uruchomienie testów i raport — warto zapisać ten prompt raz jako plik w katalogu .claude/commands/.

Taki plik, np. .claude/commands/review.md, zawiera pełną instrukcję, a w sesji wystarczy wpisać /review, by ją uruchomić. Zespół korzystający z tego samego repozytorium dostaje te same komendy automatycznie, co eliminuje rozjazd w jakości promptów między osobami.

To rozwiązanie działa najlepiej dla zadań powtarzalnych i dobrze zdefiniowanych — code review, checklisty przed merge’em, generowanie raportu ze zmian. Zadania jednorazowe i eksploracyjne nadal lepiej opisywać promptem ad hoc, zgodnie ze strukturą z poprzedniej sekcji.

Dobry prompt kontra zły prompt — porównanie

Jak wdrożyć to w praktyce

1. Załóż plik CLAUDE.md w katalogu głównym projektu i opisz w nim strukturę, komendy testowe i konwencje nazewnictwa — to jednorazowa inwestycja, która obniża długość każdego kolejnego promptu.
2. Przed każdym większym zadaniem zapytaj o plan, zanim poprosisz o implementację — akceptacja planu zajmuje minutę, a poprawianie złej implementacji zajmuje godziny.
3. Dodaj słowo „think” lub „think hard” przy zadaniach architektonicznych, żeby dać modelowi więcej przestrzeni na rozważenie alternatyw przed odpowiedzią.
4. Zbierz trzy najczęściej powtarzane prompty w zespole i zamień je na custom slash commands w katalogu .claude/commands/.
5. Zawsze określ format wyniku — plan do akceptacji, gotowy kod z testami, czy sama diagnoza — żeby Claude nie musiał zgadywać, gdzie się zatrzymać.

FAQ — najczęstsze pytania

Jak napisać dobry prompt do Claude Code?

Dobry prompt do Claude Code zawiera cztery elementy: konkretny cel, kontekst niedostępny z samego kodu, jasne ograniczenia oraz oczekiwany format wyniku. Im więcej z tych elementów Claude może odkryć sam dzięki plikowi CLAUDE.md, tym krótszy i skuteczniejszy może być sam prompt.

Czym jest plik CLAUDE.md i po co go stosować?

CLAUDE.md to plik wczytywany automatycznie na starcie każdej sesji Claude Code, zawierający konwencje projektu, strukturę katalogów i preferencje developera. Dzięki niemu nie trzeba powtarzać tych informacji w każdym prompcie — Claude ma je dostępne od pierwszej wiadomości.

Co oznacza „think hard” i „ultrathink” w Claude Code?

To słowa-klucze aktywujące tryb rozszerzonego rozumowania — zwiększają budżet tokenów, które Claude przeznacza na analizę problemu przed wygenerowaniem odpowiedzi. „Think” daje najmniejszy dodatkowy budżet, „ultrathink” największy, co ma znaczenie przy trudnych zadaniach architektonicznych i refaktorach.

Jak stworzyć własną komendę slash w Claude Code?

Wystarczy utworzyć plik markdown w katalogu .claude/commands/ z treścią promptu, który chcesz reużywać, np. .claude/commands/review.md. Od tego momentu wpisanie /review w sesji uruchamia całą zapisaną instrukcję bez konieczności jej przepisywania.

Dlaczego Claude Code generuje zły kod, mimo że model jest dobry?

Najczęstszą przyczyną jest brak kontekstu lub kryterium sukcesu w prompcie, a nie ograniczenia samego modelu. Więcej typowych sytuacji tego typu opisałem w artykule o najczęstszych błędach przy pracy z Claude Code.

Podsumowanie

Skuteczny prompt w Claude Code opiera się na czterech elementach — celu, kontekście, ograniczeniach i formacie wyniku — oraz na przeniesieniu stałego kontekstu projektu do pliku CLAUDE.md, żeby nie powtarzać go w każdej wiadomości. Stopniowanie zadań (analiza → plan → implementacja) i słowa-klucze rozszerzonego rozumowania dodatkowo poprawiają jakość odpowiedzi przy trudniejszych problemach, a custom slash commands pozwalają zapisać dobre prompty raz i reużywać je w całym zespole. Jeśli budujesz swój workflow od podstaw, zobacz też, jak te zasady promptowania łączą się z pełnym procesem w artykule o Claude Code + Spec Driven Development.

Więcej praktycznych przykładów promptów i konfiguracji pokazuję na kanale YouTube @jakubstankowski3439, a gotowy zestaw promptów startowych znajdziesz w bonusie standev.it/ai-workflow-bonus.