Prompt do Claude: 8 promptów do dokumentów, danych i kodu — oraz czym Claude różni się od reszty przy tym samym zadaniu 

Prompt do Claude działa wtedy, kiedy dostajesz z niego konkretny wynik do sprawdzenia, a nie sam tekst do przeczytania. Dokumentacja Anthropic mówi o tym wprost: kluczowa nie jest liczba słów w poleceniu, tylko to, czy model ma szansę sprawdzić sam siebie. Poniżej osiem promptów do dokumentów, danych i kodu, których używam w pracy, plus lista rzeczy, które po ostatnich zmianach w Claude lepiej usunąć z promptu, niż dopisywać. Jeśli nie masz czasu czytać wszystkiego, sekcje z promptami to samodzielne bloki - każdy da się wkleić i użyć w swoim zadaniu.

Dlaczego Twoje stare prompty działają dziś gorzej niż rok temu

Claude Sonnet 5 wyszedł 30 czerwca 2026, Opus 5 - 24 lipca 2026, a Opus 5.5 - 22 września 2026. Zmiany są na tyle duże, że część reguł, których uczono się rok temu, działa teraz przeciwko celowi.

Najbardziej zaskakująca: na Sonnet 5 ustawienie temperature, top_p lub top_k na wartość inną niż domyślna kończy się błędem HTTP 400. Dokumentacja jest jednoznaczna - parametr należy usunąć, a ton i wariancję sterować tekstem promptu. To oznacza praktyczną rzecz: te dwa, trzy słowa o „krótszych odpowiedziach", które kiedyś dokładałeś do systemowego promptu, dziś są jedynym mechanizmem.

Po drugie, Sonnet 5 ma nowy tokenizer, który dla tego samego tekstu generuje około 30% więcej tokenów. W praktyce oznacza to, że max_tokens ustawiony za czasów Sonnet 4.6 ucina teraz odpowiedź, która wcześniej mieściła się spokojnie. Dodatkowy objaw jest podstępny i wygląda inaczej na każdym zadaniu: model najpierw wypisuje całe swoje rozumowanie, a potem odpowiedź urywa się w połowie, z stop_reason: max_tokens.

Po trzecie, Opus 5 weryfikuje sam siebie bez polecenia. Dokumentacja wprost zaleca, żeby z promptu usunąć instrukcje w rodzaju „na końcu dodaj krok weryfikacji" albo „użyj subagenta, żeby sprawdzić", bo takie instrukcje wywołują nadmierną weryfikację i marnują tokeny bez poprawy jakości. To odwrotność większości porad, które krążyły w 2024 i 2025 roku.

Zanim jednak zaczniesz zmieniać stare prompty, warto zobaczyć, dlaczego w ogóle przestało wystarczać samo przepisywanie promptów zamiast przebudowy kontekstu.

Prompt 1 do dokumentu: pozwól mu powiedzieć, że nie wie

To najprostsza technika antystymulacji odpowiedzi i jednocześnie ta, którą Anthropic opisuje jako dążącą do ograniczenia fałszywych informacji. Kluczowa część to jawna zgoda na brak odpowiedzi, wpleciona wprost w treść promptu, a nie zakaz zgadywania.

Jako nasz doradca M&A przeanalizuj ten raport dotyczący przejęcia AcmeCo przez ExampleCorp.

<raport>
{{RAPORT}}
</raport>

Skup się na prognozach finansowych, ryzykach integracji i przeszkodach regulacyjnych. Jeśli czegoś nie jesteś pewien albo raport nie zawiera potrzebnych informacji, napisz wprost: "nie mam wystarczających informacji, żeby to ocenić".

Zwróć uwagę na dwie rzeczy. Tag <raport> rozdziela materiał od instrukcji - dokumentacja Anthropic zaleca właśnie takie wyraźne sekcje, bo model nie musi zgadywać, gdzie kończy się treść zlecenia, a zaczyna polecenie. A druga sprawa jest ważniejsza: bez zdania o braku informacji model z natury preferuje odpowiedź kompletną, więc dopisuje braki jako własną wiedzę ogólną.

Sama technika nie wystarcza do dokumentów powyżej około 20 tysięcy tokenów. Tam dokumentacja zaleca prostsze testy własnych wypowiedzi, zanim rzucisz je na poważne materiały.

Prompt 2 do dokumentu: cytaty jako kotwica

Tu technika jest dwuetapowa. Najpierw każesz modelowi wyciągnąć dosłowne cytaty, potem zlecasz analizę wyłącznie na tych cytatach. Dostajesz odpowiedź, którą łatwo zweryfikować, bo każde twierdzenie wskazuje na konkretny fragment dokumentu.

Jako nasz inspektor ochrony danych, sprawdź tę zaktualizowaną politykę prywatności pod kątem zgodności z GDPR i CCPA.

<polityka>
{{POLITYKA}}
</polityka>

1. Wypisz dokładne cytaty z polityki, które najbardziej dotyczą zgodności z GDPR i CCPA. Jeśli nie znajdziesz pasujących cytatów, napisz "nie znaleziono pasujących cytatów".

2. Na podstawie tych cytatów oceń zgodność tych fragmentów, odwołując się do cytatów po numerze. Oprzyj analizę wyłącznie na wypisanych cytatach.

Ten sam mechanizm działa w drugą stronę, i to jest wersja, którą stosuję przy komunikatach i raportach. Po napisaniu dokumentu każesz modelowi przejść po własnych twierdzeniach, znaleźć dla każdego cytat wspierający i usunąć to twierdzenie, jeśli go nie znajdzie, oznaczając miejsce pustymi nawiasami kwadratowymi.

Napisz komunikat prasowy o naszym nowym produkcie bezpieczeństwa AcmeSecurity Pro, korzystając wyłącznie z tych briefów produktowych i raportów rynkowych.

<dokumenty>
{{DOKUMENTY}}
</dokumenty>

Po napisaniu przejrzyj każde twierdzenie w komunikacie. Dla każdego znajdź dosłowny cytat z dokumentów, który je potwierdza. Jeśli nie znajdziesz cytatu, usuń to twierdzenie i oznacz miejsce usunięcia pustymi nawiasami [].

Zastrzeżenie autorów dokumentacji jest uczciwe i warto je znać: te techniki istotnie ograniczają halucynacje, ale nie eliminują ich. Przy decyzjach, które mają realne skutki, waliduj wynik niezależnie.

Prompt 3 do danych: tylko z tych plików, każda liczba z etykietą

Z analizą danych jest tak samo jak z dokumentami, tylko trudniej, bo błąd wygląda jak zwykła liczba w tabeli. Dwa zabezpieczenia robią tu największą różnicę: ograniczenie źródła wiedzy i przypisanie każdej wartości do miejsca, z którego pochodzi.

Zbuduj mi arkusz rozliczeń z tych plików, korzystając wyłącznie z ich zawartości.

<pliki>
{{PLIKI}}
</pliki>

Przy każdej pozycji podaj trzy rzeczy: kwotę, nazwę dokumentu źródłowego i dokładny fragment tekstu, z którego wziąłeś kwotę. Jeśli dla któregoś pola nie ma danych w plikach, zostaw je puste i wypisz listę pól, których nie udało się uzupełnić. Nie uzupełniaj niczego z wiedzy własnej.

Instrukcja wyłącznie z ich zawartości to formalna wersja tego, co w dokumentacji nazywa się ograniczeniem do wiedzy zewnętrznej. Reszta promptu robi coś ważniejszego: zamienia niepewność w widoczną listę braków zamiast w ciche uzupełnienie. Pusta komórka z raportem braków jest dla Ciebie informacją, wypełniona komórka zmyślona wartością jest wyglądem pracy, który kosztuje potem godziny na poprawkach.

Prompt 4 do danych: daj mu czym to sprawdzić

To jest wątek, który przewija się przez całą dokumentację Anthropic o Claude Code i jest powodem, dla którego Claude potrafi zostawić Ci sesję, a nie kupić Ci kolejną godzinę pracy. Brzmi banalnie, ale działa tak: model kończy pracę, kiedy wygląda na zakończoną. Jedyny sygnał, jaki ma do dyspozycji, to ten, który mu dasz.

Przy danych takim sygnałem jest skrypt, który sam porównuje wynik ze źródłem. Nie opisuj, że ma „zweryfikować sumy" - daj mu polecenie, które kończy się wykonanym poleceniem i wypisanymi różnicami.

Pokaż mi dokładnie, jak to zweryfikujesz. Napisz skrypt, który odczyta plik źródłowy, przeliczy sumy i wypisze każdą pozycję, która się nie zgadza, z numerem wiersza.

W praktyce działa to z testami, buildem, linterem, skryptem różnicującym wyjście z wzorcem, albo ze zrzutem ekranu porównywanym z projektem. Wspólna zasada z dokumentacji brzmi: każda z tych rzeczy musi zwracać sygnał, który model potrafi przeczytać w rozmowie. Proszenie go „żeby się upewnił" nie spełnia tego warunku - nie ma niczego, co mógłby odczytać.

Jest z tym związana czwarta rzecz, o której mówi osobno: poproś o dowody zamiast o deklarację sukcesu. Niech pokaże wynik testu, komendę, którą uruchomił, i to, co zwróciła. Różnica między „zrobione" a „zrobione, a oto output" jest różnicą między debugowaniem w ciemności a czytaniem komunikatu.

Prompt 5 do kodu: kryterium akceptacji w jednym zdaniu

Claude potrafi wywnioskować intencję, ale nie odczyta myśli. Dokumentacja Claude Code podaje to wprost i pokazuje tabelę zamiany promptów - warto przepisać sobie całą, bo to najszybsza poprawa jakości, jaką znalazłem.

PRZED: "implement a function that validates email addresses"
PO:   "write a validateEmail function. example test cases: user@example.com is true,
invalid is false, user@.com is false. run the tests after implementing"

PRZED: "make the dashboard look better"
PO:   "[wklej zrzut ekranu] implement this design. take a screenshot of the result
and compare it to the original. list differences and fix them"

PRZED: "the build is failing"
PO:   "the build fails with this error: [wklej błąd]. fix it and verify the build
succeeds. address the root cause, don't suppress the error"

We wszystkich trzech przypadkach dodałem to samo: obserwowalne kryterium sukcesu. W pierwszym - konkretne przypadki testowe i instrukcja uruchomienia. W drugim - punkt odniesienia w postaci zrzutu i zdanie, żeby porównać. W trzecim - wklejony błąd oraz wymóg, żeby naprawa została zweryfikowana.

Poza samym promptem działa coś, czego nie ma w instrukcjach do czatu: agent, który czyta pliki i uruchamia komendy sam, zamiast czekać na pytanie. Jeśli dopiero wdrażasz Claude w swoim procesie, trzy tygodnie pracy z Claude Code i rzeczy, które realnie przyspieszyły pracę pokazują, co daje samo przejście z pytania na zlecenie.

Prompt 6 do kodu: code review z pełnym pokryciem

Tu działa odwrotna intuicja niż przy promptach do dokumentów. Do dokumentu wkładasz zakres, żeby uniknąć halucynacji. Do review wchodzisz z zakazem selekcji, bo model zbyt dobrze słucha i po cichu wyrzuca połowę znalezisk.

Wypisz każdy znaleziony problem, także takie, co do których nie jesteś pewien
i które uważasz za mało poważne. Na tym etapie nie filtruj ze względu na wagę
ani pewność - osobny krok weryfikacji je posegreguje. Twoim celem jest
pokrycie: lepiej pokazać znalezisko, które potem wypadnie, niż cicho pominąć
prawdziwy błąd. Dla każdego podaj poziom pewności i szacowaną wagę, żeby
kolejny filtr mógł je posortować.

Zasada „lepiej pokazać, niż pominąć" idzie w parze z zakazem konserwatyzmu. Dokumentacja ostrzega wprost: jeśli prompt review mówi „zgłaszaj tylko problemy o dużej wadze" albo „bądź ostrożny", model weźmie to dosłownie i znajdzie mniej. Odfiltrowanie ma być osobnym krokiem, a nie częścią tego samego polecenia.

Na tym samym tle warto zobaczyć, jaki model wybrać do automatyzacji, licząc koszt na tysiąc zadań - ten sam mechanizm selekcji, tylko na 1000 powtarzalnych wywołaniach zamiast kilku.

Prompt 7 do kodu: przyczyna, nie objaw

Ostatni prompt z sekcji kodowej zamyka najczęstszy tryb pracy, w którym model „naprawia" i odchodzi. Kluczowe są dwie rzeczy naraz: podanie lokalizacji oraz zdefiniowanie, co oznacza słowo „fixed".

Użytkownicy zgłaszają, że logowanie przestaje działać po wygaśnięciu sesji.
Sprawdź przepływ uwierzytelniania w src/auth/, zwłaszcza odświeżanie tokenu.
Najpierw napisz test, który odtworzy problem, potem napraw go.

Porównaj to z „fix the login bug". Różnica jest fundamentalna: w pierwszym wariancie model dostaje objaw zgłoszony przez użytkownika, wskazanie pliku do obejrzenia i kryterium, że naprawa jest przetestowana. W drugim dostaje jedno słowo i musi zgadywać resztę. Dokumentacja opisuje dokładnie ten problem na przykładzie konkurencyjnego modelu, który naprawił powierzchniowy objaw, a następnie zaraportował, że błąd usunięto - przy cichym pominięciu edge case'a, który naprawiła społeczność.

Przy okazji: na długich zadaniach Claude Code potrafi pracować naprawdę długo bez nadzoru. Partner Anthropic z Walldorf zweryfikował model na refaktorze open source, który szedł sam przez siedem godzin ze stałą wydajnością. Nie jest to powód, żeby wpuszczać agenta na produkcję bez bramki z promptu 4 - ale jest argumentem za tym, żeby planować długie zadania jako osobne sesje, a nie jako dopisek do rozmowy.

Prompt 8: zanim zaczniesz, niech Claude Cię wypyta

Ten prompt jest dla wszystkich poprzednich. Zamiast pisać specyfikację od zera, każesz modelowi ją z Tobą wypracować - a potem zapisujecie ją w pliku, który przeżywa tę rozmowę.

Chcę zbudować [krótki opis]. Przepytaj mnie dokładnie, używając narzędzia AskUserQuestion.

Pytaj o implementację techniczną, interfejs, przypadki brzegowe, ryzyka
i kompromisy. Nie zadawaj oczywistych pytań, wejdź w trudne miejsca,
o których sam nie pomyślałem.

Pytaj tak długo, aż pokryjemy wszystko, a potem zapisz pełną specyfikację
do SPEC.md.

Kluczowe są dwie instrukcje, które łatwo pominąć. Po pierwsze, nie pytaj o oczywiste rzeczy, wejdź w trudne miejsca - inaczej dostaniesz ankietę o wyborze kolorów przy okazji pytania o mechanizm odzyskiwania danych. Po drugie, specyfikacja ma być samodzielna: nazywać pliki i interfejsy, wskazywać, co jest poza zakresem, i kończyć się testem całości, który dowodzi, że funkcja działa.

Dalszą część tego samego podejścia opisuję w osobnym tekście o tym, które prompty realnie poprawiają wynik, a które tylko wyglądają dobrze.

Czego nie dopisywać do promptu

To jest lista odwrócona do wszystkich porad, które znasz, i dla mnie najbardziej użyteczna. Wszystkie pozycje poniżej są z dokumentacji Anthropic dla Sonnet 5 i Opus 5, a każda z nich wprost mówi, żeby usunąć instrukcję, która do tej pory była standardem.

• "double-check your answer" oraz "re-verify before responding" - nakazują powtarzane weryfikacje, które model i tak wykonuje, i tylko podnoszą koszt.
• "include a final verification step for any non-trivial task" i "use a subagent to verify" - na Opus 5 powodują nadmierną weryfikację. Dokumentacja zaleca ich usunięcie, twierdząc, że redukuje zmarnowane tokeny bez straty jakości.
• "After every 3 tool calls, summarize progress" - to rusztowanie zostało dodane, żeby wymusić komunikaty pośrednie. Dokumentacja Sonnet 5 mówi wprost, żeby spróbować je usunąć.
• Reguła zabraniająca myślenia - taka instrukcja w system prompcie zwiększa wyciek wewnętrznych tagów XML do odpowiedzi widocznej przez użytkownika.
• "only report high-severity issues" oraz "be conservative" - obniżają pokrycie review. Zamiast tego: raportuj wszystko, filtruj w osobnym przebiegu.
• temperature, top_p, top_k - na Sonnet 5 poza wartością domyślną zwracają błąd 400.
• Stary max_tokens - nowy tokenizer generuje około 30% więcej tokenów dla tego samego tekstu, więc stare limity ucinają odpowiedzi.

Do tego jedno zastrzeżenie, które oszczędzi Ci sporo czasu: jeśli Twój prompt mówi „nie myśl" albo „odpowiadaj od razu", to złe słowo, które kosztuje jakość. Zamiast tego myślenie włącza się parametrem effort, który ma pięć poziomów: max, xhigh, high (domyślny), medium i low. Działa to odwrotnie do intuicji - wyższy effort znaczy więcej myślenia, ale niekoniecznie dłuższą odpowiedź. Jeśli zależy Ci na długości tekstu, trzeba o nią poprosić wprost. Przy większości zadań myślenie włączone na niskim effort daje lepszy wynik niż wyłączone przy porównywalnym koszcie.

Czym Claude różni się od reszty przy tym samym zadaniu

Tutaj uczciwie ostrzegam przed własnymi badaniami. Poniższe liczby pochodzą z materiałów producentów, a producenci nie stosują tej samej metodologii, więc nie da się z nich złożyć rankingu. Sam Anthropic opisuje w komunikacie Claude 4, że wyniki modeli Claude raportuje ze wszystkich 500 zadań w SWE-bench, a wyniki modeli OpenAI z podzbioru 477. To różnica, która sama w sobie psuje porównanie.

Mimo to trzy rzeczy widać.

Pierwsza: agent, nie czat. Claude Code czyta Twoje pliki, uruchamia komendy, wprowadza zmiany i sam przechodzi przez problem, podczas gdy Ty patrzysz, korygujesz albo odchodzisz. To nie jest czat, który odpowiada na pytanie i czeka - to środowisko wykonawcze, a jakość zależy od tego, ile sygnałów zwrotnych mu dałeś. Dokładnie dlatego techniki z sekcji o weryfikacji są tak istotne i dlatego tak dobrze przenoszą się na wszystkie inne modele.

Druga: wysiłek jako osobna gałka. Parametr effort steruje objętością rozumowania, a nie długością odpowiedzi, i to jest decyzja projektowa, która przesuwa kontrolę nad kosztem w stronę wywołującego. Przy pracy z n8n czy długimi dokumentami to realna różnica w rachunku.

Trzecia: koszt blisko szczytu. Na benchmarku CursorBench 3.2 przy maksymalnym effort Opus 5 plasuje się w odległości poniżej 0,5% od szczytowego wyniku Fable 5, przy połowie kosztu na zadanie. To nie jest ranking modeli, tylko deklaracja wewnątrz jednej rodziny - ale gdyby ktoś płacił cenę Fable 5, ma sensowny argument, żeby nie płacić.

Co do konkurencji: na SWE-bench Verified Gemini 2.5 Pro deklaruje 63,8% przy własnym zestawie narzędzi, wobec 72,5% deklarowanych przez Claude Opus 4. Nie porównuj tych liczb bezpośrednio, bo różni je zarówno zestaw zadań, jak i to, co dokładnie robił agent. Warto natomiast zauważyć dwie rzeczy niepozostające w kwestii metodologii: Anthropic skorygował własny wynik Sonnet 4.6 na Humanity's Last Exam do 34,6% bez narzędzi i 46,8% z narzędziami, bo różnił się od podanego w komunikacie premierowym - oraz oferuje Qwen3 jako realną alternatywę dla sieci własnej, z licencją Apache 2.0 i oknem 128K. To druga strona tego samego porównania: najtańszy model to często ten, który postawisz u siebie, i wtedy liczy się coś zupełnie innego niż wynik benchmarku.

Szerzej o samym podejściu do testowania modeli na polskich zadaniach pisałem przy 25 zadaniach, z metodą i wynikami.

Ile to kosztuje przy realnym wolumenie

Jeśli używasz Claude przez aplikację, nie wybierasz modelu i nie widzisz rachunku za tokeny. Sytuacja zmienia się, gdy wchodzi automatyzacja, bo wtedy każde wywołanie ma cenę. Poniżej stawki z cennika Claude, podane w dolarach za milion tokenów.

Model	Wejście	Wyjście	Odczyt z cache
Haiku 4.5	$1	$5	$0.10
Sonnet 5.5	$2	$10	$0.20
Opus 5.5	$4	$20	$0.20
Opus 5	$5	$25	$0.50
Fable 5.1	$10	$50	$0.25

Żeby z liczb zrobić rachunek, potrzebuję założenia, bo one decydują o wyniku. Biorę więc zadanie, które czyta 10 tysięcy tokenów materiału i pisze 2 tysiące tokenów odpowiedzi, oraz liczę 1000 takich zadań. To daje 10 milionów tokenów wejścia i 2 miliony wyjścia.

Na Sonnet 5 to 10 x $2, czyli $20 za wejście, plus 2 x $10, czyli $20 za wyjście. Razem $40 za tysiąc zadań. To samo zadanie na Haiku 4.5 kosztuje $20, na Opus 5.5 - $80, na Opus 5 - $100, a na Fable 5.1 - $200. Trzy darmowe mechanizmy zmieniają ten wynik wyraźnie: prompt caching z odczytem w cenie $0.20 za milion zamiast $2 obcina wejście do $2, czyli całość spada do $22; batch processing daje 50% zniżki, czyli $20; a fast mode na Opus 5.5 daje do 2,5 raza większą prędkość przy dwukrotnej cenie.

Po stronie abonamentów: Free kosztuje $0, Pro $17 miesięcznie przy płatności rocznej ($200 z góry) albo $20 miesięcznie, Max startuje od $100. Przy moim założeniu Pro przestaje się opłacać powyżej około 425 zadań miesięcznie, bo $17 dzielone przez $0.04 za zadanie daje dokładnie tyle. Z prompt caching granica przesuwa się do około 770 zadań. Do tego Pro daje co najmniej 5 razy więcej użycia w pięciogodzinnym oknie niż Free, a Max 5 albo 20 razy więcej niż Pro, z resetem w pięciogodzinnym oknie i dodatkowym limitem tygodniowym na planach płatnych. Nie ma stałej liczby wiadomości - jest okno.

To wszystko są stawki publiczne. Nie sprawdzałem polskiego cennika ani faktury VAT, więc jeśli liczysz w złotówkach, przelicz sam na podstawie tabeli.

Zanim wkleisz firmowe dokumenty

To jest sekcja, którą pomijam w artykułach o promptach, a nie powinienem. Anthropic podaje w materiałach o Claude in Chrome, że ataki typu prompt injection odniosły skuteczek w 11,2% przypadków nawet po zastosowaniu zabezpieczeń. To nie jest znikomy odsetek, gdy chodzi o dokumenty z klienta.

Drugi przypadek dotyczy udostępnianych rozmów. BBC policzyła ponad 200 rozmów z indeksowanych przez wyszukiwarki, z czego część zawierała dokumentację medyczną i korporacyjną. Analiza techniczna wskazała, że reguła blokująca roboty nie pozwoliła również odczytać dyrektywy noindex. Zasada praktyczna: rozmowy, które nie mają być znalezione, nie powinny być publikowane w publicznym widoku - niezależnie od obietnic w interfejsie.

Po stronie Plusów są też zabezpieczenia, o których warto wiedzieć, bo zmieniają sposób myślenia o awariach. Flagi bezpieczeństwa w aplikacji powodują ciche podmienienie modelu na Opus 4.8, a w kwietniu 2026 pojawiło się 35 zgłoszeń odmów, których nie powinno być - to najwięcej w miesiącu według raportów dostępnych w materiałach źródłowych. Inny przykład z tych samych źródeł: użytkownik poprosił aplikację o uporządkowanie plików na komputerze żony, a skasowała wszystkie rodzinne zdjęcia. Warto wiedzieć również, że punkty przywracania śledzą tylko zmiany z edytora plików, a nie to, co agent zrobił z wierszem poleceń - to nie jest zamiennik gita.

Przy danych klientów dochodzi RODO i AI Act, a od strony modelu warto znać jedno ustawienie: na planach Free, Pro i Max trenowanie na Twoich danych jest opt-out, natomiast na Team i Enterprise wyłączone domyślnie. Jeśli dokument ma zostać w firmie na stałe, to pierwsza różnica, o którą pytam.

Bezpieczniki mają też skutek uboczny, o którym mówi osobna strona dokumentacji - atak na agenta, to realny wektor, a zasada mniejszych uprawnień działa lepiej niż każdy prompt.

Trzy rzeczy, które ustawiasz raz

Ostatnie trzy praktyki dotyczą rzeczy, których nie warto przepisywać w każdym prompcie, bo raz ustawione działają zawsze.

Plik CLAUDE.md to mechanizm trwałego kontekstu - Claude czyta go na początku każdej rozmowy i dzięki temu zna rzeczy, których nie wyłuska z samego kodu. Test na każdą linię jest prosty: czy usunięcie tej linii spowodowałoby błędy? Jeśli nie, usuwaj. Dokumentacja ostrzega wprost, że rozdęte pliki CLAUDE.md powodują, iż model ignoruje Twoje faktyczne instrukcje. Warto w nim trzymać komendy, których nie da się odgadnąć, reguły stylu odbiegające od domyślnych, sposób uruchamiania testów, konwencje gita, decyzje architektoniczne i typowe pułapki. Nie warto za to opisywać plików po kolei ani tłumaczyć, co jest oczywiste. Jeśli Claude notorycznie pomija jedną instrukcję, dodaj w jej wierszu słowo IMPORTANT - ale tylko w jednym, bo w kilku wyróżnienie przestaje działać.

Czyszczenie sesji rozwiązuje powtarzający się problem, o którym mówi dokumentacja Claude Code: sesje długie i przeładowane nieistotnym kontekstem obniżają jakość. Dwa razy poprawiony ten sam fragment to sygnał, że kontekst jest zaśmiecony nieskutecznymi podejściami. Lepsze nowe podejście w czystym kontekście niż trzecia iteracja w brudnym.

Poziom weryfikacji da się ustawić raz na cały projekt, zamiast dopisywać go do każdego zadania. Są cztery poziomy, od najtańszego do najdroższego: poprosić model o wykonanie sprawdzenia w tej samej wiadomości; ustawić sprawdzenie jako warunek zakończenia, który niezależny ewaluator sprawdza po każdej turze; skrypt weryfikujący uruchamiany jako hook blokujący zakończenie tury, dopóki test nie przejdzie; albo podagent weryfikacyjny, który próbuje obalić wynik świeżym modelem, żeby ten, który pracował, nie oceniał sam siebie.

Jeśli chcesz przejść z promptów na proces, zacznij od jednego: ustal, które z Twoich powtarzalnych zadań da się opisać jednym zdaniem z kryterium akceptacji, i policz, ile godzin tygodniowo na to marnujesz. Jeśli to jest więcej niż kilka, automatyzacja ma sens i warto ją zacząć od tego jednego miejsca, a nie od całego procesu naraz. Napisz do mnie - odpowiadam zwykle tego samego dnia.