Podpowiedzi Claude Code: 25 gotowych do skopiowania podpowiedzi oraz instrukcja tworzenia własnych

Klienci korzystający z kuponu, którego ważność wygasła, otrzymują błąd 500 podczas finalizacji zamówienia. Przejrzyj plik @src/checkout/coupons.ts oraz związane z nim testy. Oczekiwanym zachowaniem jest wyświetlenie komunikatu o nieprawidłowym kuponie bez tworzenia zamówienia. Napisz test, który kończy się niepowodzeniem i odtwarza ten błąd, a następnie napraw go bez zmiany zachowania w przypadku ważnego kuponu. Uruchom [komendę testowania procesu realizacji zamówienia] i pokaż wyniki przed i po zmianie. Jeśli nie możesz odtworzyć błędu, opisz, co sprawdziłeś, zanim zmieniłeś implementację.

Dodaj selektor daty do [ścieżka formularza rezerwacji]. Postępuj zgodnie z konwencjami dotyczącymi komponentów i walidacji zawartymi w pliku @src/components/TimeSelect.tsx. Użytkownicy muszą mieć możliwość wyboru [dopuszczalnych dat], podczas gdy [daty niedostępne] pozostają nieaktywne. Nie dodawaj bibliotek. Uruchom [komendę testowania komponentu] oraz [komendę sprawdzania typów] i zgłoś wszelkie kryteria, których te sprawdzania nie obejmują.

Podziel plik @src/reports/export.py na mniejsze funkcje, zachowując dane wejściowe, format wyjściowy oraz zachowanie w przypadku błędów. Przed edycją uruchom [komendę testową eksportu] i zgłoś wszelkie istniejące błędy. Po refaktoryzacji ponownie uruchom testy i przedstaw oba wyniki. Nie zmieniaj interfejsu publicznego ani plików niezwiązanych z zadaniem.

„Claude testuje każdą zmianę, którą wprowadzam w serwisie claude.ai/code za pomocą rozszerzenia Claude dla przeglądarki Chrome. Otwiera przeglądarkę, testuje interfejs użytkownika i powtarza tę czynność, aż kod zacznie działać, a doświadczenie użytkownika będzie zadowalające. ”

Zapoznaj się z plikiem README, konfiguracją projektu oraz strukturą katalogów najwyższego poziomu w tym repozytorium. Korzystaj z materiałów referencyjnych tylko w zakresie niezbędnym do wyjaśnienia: Czego służy aplikacja, jakie są jej główne punkty wejścia i najważniejsze komponenty, gdzie znajdują się testy oraz jakie komendy definiuje repozytorium do ich uruchamiania. Podaj ścieżki do plików zapewniające wsparcie dla Twoich wyjaśnień. Odróżnij udokumentowane zachowanie od własnych wniosków i zaznacz wszystko, czego nie jesteś w stanie ustalić. Nie odczytuj plików zawierających poufne informacje ani plików środowiskowych, nie sprawdzaj zainstalowanych zależności ani nie zmieniaj żadnych plików. Na koniec wskaż trzy pliki, z którymi powinienem zapoznać się w pierwszej kolejności, oraz uzasadnij swój wybór.

Przejrzyj historię Git [pliku, funkcji lub klasy], skupiając się na [zachowaniu lub kwestii projektowej]. Zidentyfikuj commity, które wprowadziły lub znacząco zmieniły to zachowanie. Dla każdego istotnego commitu podaj jego hash, podsumuj zmianę i wyjaśnij wszelkie uzasadnienia udokumentowane w komunikacie commitu lub połączonej dyskusji, do której masz dostęp. Oznacz wnioskowane przyczyny jako „wnioski”. Jeśli historia nie wyjaśnia danej decyzji, zaznacz to. Nie modyfikuj plików ani historii Git.

Prześledź, co dzieje się po [działaniu użytkownika lub zdarzeniu systemowym], zaczynając od [znanej ścieżki, procedury obsługi lub folderu]. Śledź odpowiednie wywołania poprzez walidację, logikę biznesową oraz wszelkie zapisy do bazy danych lub żądania zewnętrzne. Przygotuj listę plików i funkcji w kolejności wykonywania, podając numery linii, jeśli są dostępne. Wyjaśnij główne ścieżki awarii i zidentyfikuj istniejące testy obejmujące ten przepływ. Oznacz wszelkie połączenia, których nie możesz potwierdzić na podstawie kodu. Nie uruchamiaj tego przepływu, nie wywołuj usług zewnętrznych ani nie edytuj plików.

Zaplanuj sposób wdrożenia [funkcji] w [obszarze repozytorium]. Oczekiwane zachowanie to [wymagania], a następujące obszary muszą pozostać niezmienione: [ograniczenia]. Przejrzyj odpowiedni kod i istniejące testy. Zidentyfikuj pliki, które wymagają zmian, kolejność wdrażania oraz wszelkie ryzyka związane z kompatybilnością lub migracją danych. Przypisz każde wymaganie do proponowanego testu lub innego kroku weryfikacji. Osobno wymień nierozstrzygnięte kwestie i założenia na liście. Nie wdrażaj jeszcze tej funkcji. Prześlij plan do mojej weryfikacji.

Chcę stworzyć [krótki opis] dla [użytkowników i scenariusza użycia]. Najpierw zapoznaj się z [odpowiednimi plikami lub wymaganiami], a następnie skorzystaj z funkcji AskUserQuestion, aby wyjaśnić decyzje, które mogłyby mieć istotny wpływ na implementację. Skoncentruj się na przypadkach skrajnych, przetwarzaniu danych, uprawnieniach, oczekiwanym zachowaniu interfejsu użytkownika oraz kompromisach. Nie zadawaj pytań, na które odpowiedź znajduje się już w podanym kontekście. Po podjęciu kluczowych decyzji sporządź projekt specyfikacji obejmujący wymagania, kryteria akceptacji, ograniczenia oraz elementy wykraczające poza zakres. Zaznacz wszelkie pozostałe założenia. Pokaż mi specyfikację przed zapisaniem jej w [ścieżka do specyfikacji] i nie nadpisuj istniejącego pliku bez zgody.

Oceń wpływ zmiany [funkcji, komponentu lub interfejsu] z [obecnego zachowania] na [proponowane zachowanie]. Przeszukaj [repozytorium lub zakres katalogu] w poszukiwaniu jego definicji, bezpośrednich wywołań, importów i powiązanych testów. Przygotuj listę plików, które prawdopodobnie będą wymagały zmian, i wyjaśnij, jak każda z nich może wpłynąć na te pliki, podając odniesienia do plików i wierszy, jeśli są dostępne. Oznacz wywołania rozstrzygane dynamicznie, zewnętrznych odbiorców lub inne zależności, których nie możesz zweryfikować. Zidentyfikuj wszelkie kwestie dotyczące kompatybilności, które wymagają odpowiedzi przed wdrożeniem. Nie wprowadzaj zmian w plikach; prześlij ocenę wpływu i poczekaj na moją weryfikację.

Dodaj [funkcję] do [pliku lub strony] o następującym zachowaniu: [kryteria akceptacji]. Sprawdź [istniejącą implementację] i stosuj się do jej konwencji dotyczących pobierania danych, obsługi błędów oraz organizacji komponentów. Korzystaj wyłącznie z bibliotek już zainstalowanych w projekcie. Ogranicz zmiany do [zakresu] i zachowaj [istniejące zachowanie lub interfejs publiczny]. Dodaj lub zaktualizuj testy dla kryteriów akceptacji. Uruchom [komendę testową] oraz [komendę sprawdzającą typy lub lint], a następnie zgłoś zmienione pliki, wyniki oraz wszelkie sprawdzania, których nie udało się zakończyć. Jeśli istniejący wzorzec jest sprzeczny z wymogiem, wyjaśnij tę sprzeczność przed kontynuowaniem.

Zaimplementuj [nazwa funkcji] w pliku [plik], aby spełnić [wymagania]. Uwzględnij [przypadek normalny], [przypadek skrajny] oraz [zachowanie przy nieprawidłowych danych wejściowych]. Najpierw uruchom [odpowiednią komendę testową] i zgłoś wszelkie istniejące błędy. Napisz testy dla wymaganego zachowania, a następnie uruchom je przed implementacją. Upewnij się, że nowe testy kończą się niepowodzeniem z oczekiwanych przyczyn. Zaimplementuj funkcję i ponownie uruchom testy. Nie osłabiaj asercji, nie pomijaj testów ani nie zmieniaj oczekiwanego zachowania, aby testy zakończyły się powodzeniem. Jeśli wymagania są sprzeczne z istniejącymi testami, zatrzymaj się i wyjaśnij tę sprzeczność. Pokaż wyniki przed i po zmianie.

Zaimplementuj załączony projekt w [komponencie lub stronie], korzystając z istniejących komponentów i stylów projektu. Zachowaj [wymagane zachowanie] i unikaj zmian wykraczających poza [zakres]. Użyj [skonfigurowanej przeglądarki lub narzędzia do tworzenia zrzutów ekranu], aby uchwycić [lokalną trasę] przy [wymiarach okna wyświetlania] z [danymi testowymi i stanem interfejsu użytkownika]. Jeśli narzędzie lub aplikacja są niedostępne, zgłoś, co jest potrzebne, zamiast twierdzić, że przeprowadzono kontrolę wizualną. Porównaj zrzut ekranu z obrazem referencyjnym, skupiając się na [układzie, odstępach, typografii lub innych kryteriach akceptacji]. Dokonaj maksymalnie [liczba] rund poprawek, a następnie zgłoś pozostałe różnice. Nie zmieniaj obrazu referencyjnego. Uruchom [odpowiednie testy komponentów] oraz [komendę sprawdzania typu lub kompilacji]. Do podsumowania dołącz zrzut ekranu oraz rzeczywiste wyniki sprawdzenia.

Użytkownicy napotykają [objaw] w sytuacji [wyzwalacz lub dane wejściowe]. Oczekiwanym zachowaniem jest [oczekiwany wynik]. Zacznij od sprawdzenia [folderu, funkcji lub przepływu] oraz powiązanych testów. Utwórz test, który kończy się niepowodzeniem i odtwarza zgłoszone zachowanie. Jeśli nie możesz go odtworzyć, wyjaśnij, co sprawdziłeś i jakich informacji brakuje, zanim zmienisz implementację. Po odtworzeniu problemu usuń przyczynę bez zmiany [zachowania, które musi pozostać niezmienione]. Uruchom nowy test oraz [powiązana komenda testowa]. Pokaż niepowodzenie przed naprawą, wyniki po niej oraz wszelkie pozostałe niepowodzenia.

[Komenda kompilacji] kończy się niepowodzeniem w [środowisku lokalnym lub CI] z następującym wynikiem: [oczyszczony dziennik błędów]. Przejrzyj odpowiedni kod i konfigurację, aby zidentyfikować przyczynę. Jeśli błąd nie powtarza się lokalnie, sprawdź, czy nie występują różnice w środowisku lub zależnościach. Wprowadź najmniejszą zmianę, która usunie przyczynę. Nie wyłączaj kontroli, nie tłumi błędów, nie pomijaj testów ani nie rozluźniaj ustawień kompilatora tylko po to, by kompilacja zakończyła się powodzeniem. Po wprowadzeniu zmiany uruchom kompilację ponownie. Jeśli nadal kończy się niepowodzeniem po [liczba] próbach naprawy, zatrzymaj się i zgłoś, co próbowałeś, jaki jest aktualny błąd oraz jaki jest następny krok diagnostyczny. Podsumuj przyczynę i dołącz rzeczywisty wynik kompilacji.

Pomóż mi zawęzić zakres błędu przed zaproponowaniem poprawki. Obserwowane zachowanie: [co się dzieje] Oczekiwane zachowanie: [co powinno się dziać] Kiedy występuje: [warunki lub częstotliwość] Co już próbowałem: [kroki i wyniki] Zadawaj po jednym pytaniu na raz, wybierając to, które najlepiej pozwoli odróżnić prawdopodobne przyczyny. Nie powtarzaj pytań, na które udzielone informacje już odpowiadają. Gdy zgromadzisz wystarczającą ilość dowodów, podsumuj najbardziej prawdopodobne wyjaśnienie, to, co pozostaje niepewne, oraz najmniejszy test, który mógłby to potwierdzić lub wykluczyć. Nie edytuj jeszcze plików.

Wykorzystaj podagenta do porównania [różnic lub branch w stosunku do wersji bazowej] z [zatwierdzonym planem lub plikiem wymagań]. Jeśli wymagania są niekompletne lub niejednoznaczne, zgłoś to przed oceną kompletności. Sprawdź, czy każde wymaganie zostało zaimplementowane, czy odpowiednie przypadki graniczne mają testy oraz czy jakiekolwiek zmiany wykraczają poza uzgodniony zakres. W razie potrzeby przejrzyj otaczający kod, aby zrozumieć różnice. Zgłaszaj problemy z poprawnością i niespełnione wymagania, podając odniesienia do plików i wierszy, ich wpływ oraz dowody wspierające każde ustalenie. Oddziel potwierdzone problemy od nierozwiązanych kwestii. Nie wymyślaj ustaleń, aby wypełnić limit, ani nie uwzględniaj niepowiązanych preferencji stylistycznych. Nie edytuj plików.

Przejrzyj [pliki lub różnice] pod kątem ryzyka ataków typu injection, brakujących kontroli autoryzacji, ujawnionych danych poufnych oraz niebezpiecznej obsługi danych wprowadzanych przez użytkownika. Przed raportowaniem ustalenia sprawdź odpowiednie elementy wyzwalające oraz logikę walidacji. Dla każdego problemu określ plik i wiersze, których dotyczy, warunki niezbędne do jego wywołania, prawdopodobny wpływ oraz sugerowaną poprawkę. Odróżnij potwierdzoną ścieżkę podatności od kwestii wymagającej dalszego testowania. Nie podawaj wartości poufnych w raporcie, nie modyfikuj plików ani nie przeprowadzaj testów na działających usługach. Wskaż, które obszary zostały sprawdzone, a co pozostaje poza zakresem.

Podsumuj, w jaki sposób zweryfikowałeś zakończoną zmianę pod kątem [kryteriów akceptacji]. Dla każdego kryterium wymień przeprowadzoną kontrolę, dokładną komendę (jeśli dotyczy) oraz zaobserwowany wynik. Dołącz odpowiednie dane wyjściowe, z usuniętymi informacjami poufnymi i danymi wrażliwymi. Osobno wskaż wszelkie istniejące wcześniej błędy. Wyraźnie rozróżnij kontrole, które zakończyły się powodzeniem, te, które zakończyły się niepowodzeniem, oraz te, które nie zostały uruchomione. Wyjaśnij wszelkie pominięte kontrole lub limity w zakresie pokrycia. Nie opisuj całej zmiany jako zweryfikowanej, jeśli niektóre kryteria pozostały niesprawdzone.

Przeprojektuj [plik lub moduł] w celu osiągnięcia [określonego celu, np. podzielenia dużej funkcji lub usunięcia zagnieżdżonych wywołań zwrotnych]. Zachowaj jego interfejs publiczny, wartości zwracane, zachowanie w przypadku błędów oraz efekty uboczne. Przed edycją uruchom [odpowiednią komendę testową], aby ustalić stan początkowy. Jeśli test zakończy się niepowodzeniem, zgłoś błędy przed kontynuowaniem. Zidentyfikuj wszelkie zachowania, których istniejące testy nie obejmują, i w razie potrzeby dodaj ukierunkowane testy. Przeprowadź refaktoryzację bez wprowadzania niepowiązanych zmian ani nowych zależności. Nie osłabiaj istniejących asercji, aby dostosować je do implementacji. Uruchom ponownie testy oraz [komenda sprawdzająca typy lub lint]. Pokaż wyniki przed i po zmianach, podsumuj zmiany strukturalne i zaznacz wszelkie zachowania, których nie udało się zweryfikować.

Znajdź miejsca użycia [starego API lub biblioteki] w [zakresie katalogu], z wyłączeniem plików wygenerowanych i dostarczonych przez dostawców. Przygotuj listę plików, których to dotyczy, oraz wszelkie wspólne konfiguracje lub zależności, na które migracja może mieć wpływ. Zaproponuj trzy reprezentatywne pliki do pilotażowej migracji do [nowego API lub wersji], korzystając z [przewodnika migracji lub istniejącego przykładu]. Wyjaśnij, dlaczego je wybrałeś, i zaznacz wszelkie wymagane zmiany w zachowaniu. Przed wprowadzeniem zmian poczekaj na moją zgodę. Po zatwierdzeniu przeprowadź migrację wyłącznie plików pilotażowych oraz wszelkich wyraźnie zatwierdzonych wspólnych zależności. Uruchom [odpowiednie testy] oraz [komendę kompilacji lub sprawdzania typów]. Nie rozszerzaj migracji na inne pliki. Przedstaw różnice, wyniki testów, problemy z kompatybilnością oraz wszelkie zmiany wymagane w podejściu do migracji. Zatrzymaj się w celu przeglądu przed kontynuowaniem pracy nad pozostałymi plikami.

Sprawdź bieżącą branch, status Git oraz różnice (diff) dla [funkcji lub poprawki]. Zidentyfikuj pliki należące do tej zmiany i osobno przygotuj listę niezwiązanych lub nieśledzonych plików. Przygotuj wstępną treść komunikatu commit zgodnie z formatem ostatnich 10 commitów. Przygotuj opis pull requestu obejmujący to, co się zmieniło, dlaczego, jakie testy faktycznie przeprowadzono oraz wszelkie pozostałe ograniczenia. Przed umieszczeniem w stagingu lub opublikowaniem czegokolwiek pokaż proponowaną listę plików, komunikat zatwierdzenia oraz opis pull requestu. Poczekaj na moją zgodę. Po zatwierdzeniu umieść w stagingu wyłącznie uzgodnione pliki, zatwierdź zmiany w [gałęzi funkcji], prześlij do [serwera zdalnego] i otwórz pull request względem [gałęzi bazowej]. Nie modyfikuj istniejących zatwierdzeń, nie wykonuj wymuszonego przesłania ani nie scalaj. Prześlij hash zatwierdzenia oraz link do pull requestu.

Przygotuj sekcję README dla [modułu], skierowaną do [odbiorcy, np. inżyniera backendu dołączającego do projektu]. Uwzględnij wymagania wstępne, ustawienia, trzy najczęściej używane komendy oraz typowe błędy opisane w kodzie lub istniejącej dokumentacji. Sprawdź nazwy komend i opcje w oparciu o [skrypty pakietu, plik Makefile, pomoc CLI lub konfigurację CI]. Zaznacz wszystko, czego nie możesz potwierdzić. Przetestuj bezpieczne komendy lokalne w [środowisku testowym], jeśli jest dostępne. Przed uruchomieniem komend, które instalują zależności, usuwają pliki, migrują dane, wdrażają lub uzyskują dostęp do usług zewnętrznych, wyjaśnij ich skutki i poproś o zgodę. Wyraźnie odróżnij komendy, które uruchomiłeś z powodzeniem, od komend sprawdzonych jedynie pod kątem zgodności z konfiguracją lub dokumentacją. Pokaż proponowaną sekcję README przed edycją [ścieżki dokumentacji] i zachowaj zawartość niezwiązaną z tematem.

Przejrzyj plik [ścieżka do CLAUDE.md] pod kątem aktualnej struktury repozytorium, skryptów i konwencji. Nie edytuj jeszcze tego pliku. Zidentyfikuj nieaktualne instrukcje, duplikaty, sprzeczności oraz reguły, które można wiarygodnie wywnioskować z kodu. Wyjaśnij każdą proponowaną zmianę, zamiast usuwać instrukcje wyłącznie w celu skrócenia pliku. Sugeruj brakujące komendy kompilacji lub testowania tylko wtedy, gdy możesz je zweryfikować w skryptach projektu, pliku Makefile, konfiguracji CI lub istniejącej dokumentacji. Podaj źródło każdego dodanego elementu. Prześlij proponowaną różnicę (diff), która zachowuje istotne ograniczenia projektu. Oznacz instrukcje dotyczące konkretnych zadań, które lepiej pasowałyby do reguły o zasięgu umiejętności lub ścieżki, i poczekaj na zatwierdzenie przed wprowadzeniem zmian.

Zaproponuj hak komendy Claude Code, który uruchamia [istniejącą komendę formatującą] po wprowadzeniu zmian typu „Edit” lub „Write” w [wzorach plików]. Najpierw sprawdź istniejące ustawienia w pliku claude/settings.json oraz ustawienia formatującego. Użyj odpowiedniej konfiguracji PostToolUse dla zainstalowanej wersji Claude Code. Formatuj tylko plik, którego dotyczy zmiana, bezpiecznie obsługuj ścieżki i wyklucz [pliki wygenerowane lub inne wykluczone ścieżki]. Nie instaluj zależności ani nie zastępuj istniejących hooków. Pokaż różnice w proponowanych ustawieniach i wyjaśnij, w jaki sposób będą zgłaszane błędy formatowania. Przed wdrożeniem poczekaj na zatwierdzenie. Po zatwierdzeniu przetestuj to na pliku tymczasowym w projekcie i zgłoś wynik. Wskaż, które ścieżki edycji obejmuje, a które nie, w tym zmiany wprowadzone za pomocą komend powłoki.

Sprawdź [narzędzie] –help oraz pomoc dotyczącą podpoleceń związanych z [zadaniem]. Nie instaluj narzędzia, jeśli go brakuje; zamiast tego zgłoś ten warunek wstępny. Zaproponuj dokładne komendy potrzebne do zakończenia zadania. Wyjaśnij ich dane wejściowe, wyjściowe oraz to, czy zapisują pliki, zmieniają zasoby zdalne lub wykorzystują dane uwierzytelniające. Uwzględnij opcję symulacji, jeśli narzędzie ją dokumentuje. Zaznacz brakującą konfigurację lub uprawnienia i poproś o wyjaśnienie, zamiast zgadywać nazwy zasobów lub miejsca docelowe. Poczekaj na zatwierdzenie przed uruchomieniem komend zadania. Po zatwierdzeniu uruchom tylko uzgodnione komendy i zgłoś ich rzeczywiste wyniki, w tym wszelkie błędy lub niekompletne kroki.

Porównaj pliki [invoices.csv] i [payments.csv] na podstawie [ID faktury lub klucza dopasowującego]. Nie modyfikuj plików źródłowych. Stosuj następujące zasady: [waluta i tolerancja zaokrąglenia], [alokacja płatności częściowych] oraz [obsługa zwrotów, not kredytowych i nadpłat]. Jeśli brakuje zasady lub dopasowanie jest niejednoznaczne, oznacz to zamiast automatycznie przypisywać płatność. Zachowaj ID wierszy źródłowych. Dla każdej faktury pokaż kwotę z faktury, przypisane płatności oraz pozostałe saldo. Zgłaszaj zduplikowane ID, niezgodne faktury, niezgodne płatności oraz salda wykraczające poza tolerancję. Uzgadniaj sumy faktur i płatności oddzielnie. Uwzględnij każdy wiersz źródłowy bez podwójnego liczenia; jeśli płatność jest rozdzielona na kilka faktur, pokaż każdą alokację i upewnij się, że alokacje nie przekraczają kwoty płatności. Zapisz wyniki w [nowych ścieżkach wyjściowych] i podsumuj wyjątki wymagające weryfikacji.

Napisz skrypt, który podsumuje plik [export.csv] dla okresu od [data rozpoczęcia i godzina, włącznie] do [data końcowa, wyłącznie], wykorzystując [strefę czasową] i [kolumnę daty]. Pogrupuj rekordy według [reguł kategorii] i oblicz [wymagane wskaźniki]. Postępuj z zduplikowanymi ID i brakującymi wartościami zgodnie z [regułami]. Nie modyfikuj pliku wejściowego. Uruchom skrypt na [dokładnym pliku wejściowym]. Podaj liczbę wierszy uwzględnionych i wykluczonych, sumy kategorii oraz rekordy, których nie udało się sklasyfikować. Porównaj wyniki dla [trzech kategorii] z niezależnie zweryfikowanymi liczbami w [pliku referencyjnym]. Jeśli te liczby są niedostępne, zaznacz, że niezależna weryfikacja pozostaje do wykonania. Wskaż rozbieżności i zapisz raport w [nowej ścieżce wyjściowej].

Przejrzyj [określone pliki lub folder] i przygotuj [rodzaj i długość dokumentu] dla [odbiorców], obejmujący [pytania lub tematy]. Każde twierdzenie oparte na faktach uzyska wsparcie w postaci nazwy pliku oraz odniesienia do strony, sekcji lub wiersza, jeśli jest to możliwe. Odróżniaj cytaty bezpośrednie od parafraz i nie traktuj propozycji ani nieaktualnego dokumentu jako potwierdzonej, aktualnej decyzji. Zaznacz sprzeczne źródła, brakujące informacje oraz twierdzenia, których nie możesz zweryfikować. Nie uzupełniaj braków za pomocą przypuszczeń ani nie edytuj plików źródłowych. Przekaż recenzentowi projekt wraz z odniesieniami oraz krótką listą nierozstrzygniętych kwestii.

Aby dostosować szablon, zastąp w nim symbole zastępcze danymi z Twojego projektu i przed wprowadzeniem zmian zdecyduj, co ma zrobić Claude. Skorzystaj z poniższych kroków, aby przygotować zapytanie i sprawdzić wynik.

W przypadku niewielkiej, jasno zdefiniowanej zmiany możesz poprosić Claude'a o jej bezpośrednie wdrożenie. W przypadku nieznanego kodu, zmian obejmujących kilka plików lub nierozstrzygniętych wymagań zacznij od opracowania planu.

Naciśnij klawisze Shift+Tab, aż pojawi się tryb Planowania, lub uruchom Claude Code za pomocą polecenia claude --permission-mode plan. W tym trybie Claude może przeglądać pliki i wykonywać komendy tylko do odczytu bez edytowania kodu źródłowego. Przejrzyj proponowane pliki, zależności i testy przed zatwierdzeniem implementacji. Naciśnij klawisze Ctrl+G, aby otworzyć proponowany plan w redaktorze.

Przekaż Claude'owi informacje niezbędne do zrozumienia zadania: odnośnik do pliku, oczyszczony dziennik błędów, zrzut ekranu lub dokument zawierający wymagania. Użyj znaku @, po którym podaj ścieżkę do pliku, aby dołączyć jego zawartość.

Wybierz najmniejszy użyteczny zestaw źródeł. Dołączenie całego dziennika lub katalogu może spowodować dodanie nieistotnych treści i nadmierne obciążenie kontekstu. Przed udostępnianiem dzienników usuń dane uwierzytelniające i dane wrażliwe oraz sprawdź, czy Claude dysponuje narzędziami niezbędnymi do pobrania podanych przez Ciebie adresów URL dokumentacji.

Na przykład polecenie `cat błąd.log | claude -p "Explain this błąd"` przesyła dziennik w ramach żądania nieinteraktywnego. Należy z niego korzystać dopiero po sprawdzeniu zawartości pliku. Na tym polega praktyczna wartość kontekstowej AI: dostarczanie modelowi informacji istotnych dla danego zadania.

Dodając nową funkcję, zidentyfikuj podobny komponent lub funkcję w repozytorium. Poinformuj Claude'a, jakich konwencji ma przestrzegać, np. dotyczących klienta API, logiki walidacji, obsługi błędów lub struktury testów.

„Zobacz, jak plik @src/widgets/Weather.tsx pobiera i buforuje dane” stanowi dla Claude’a konkretny punkt odniesienia. Wskaż również wszelkie różnice wymagane przez nową funkcję, aby nie kopiowała ona zachowań, które już nie są aktualne. Konwencje te powinny odzwierciedlać cykl pracy tworzonego oprogramowania w Twoim zespole.

W przypadku zmian w kodzie należy określić odpowiednią komendę testową, kompilacyjną lub lintującą oraz zachowanie, które ma zostać sprawdzone. W przypadku badań należy poprosić o odniesienia do plików lub ID commitów. W przypadku prac nad interfejsem użytkownika należy dostarczyć obraz referencyjny oraz skonfigurowany sposób uchwycenia implementacji w tym samym oknie wyświetlania.

Poproś Claude'a o raportowanie tego, co faktycznie sprawdził, w tym błędów i pominiętych kontroli. Sprawdź, czy dowody potwierdzają spełnienie wymagań; pomyślna kompilacja nie gwarantuje, że każde wymagane zachowanie działa poprawnie.

W przypadku dłuższych zadań Claude Code oferuje również warunek /goal oraz haki Stop. Moduł oceny celu analizuje informacje ujawnione w rozmowie, zamiast samodzielnie sprawdzać pliki lub uruchamiać testy. Skonfigurowany hak Stop może zablokować zakończenie zadania, ale ma ograniczenia dotyczące wielokrotnego blokowania. Żadne z tych rozwiązań nie zastępuje odpowiednich testów ani przeglądu przeprowadzanego przez człowieka.

Jeśli powtarzające się poprawki nie rozwiązują problemu, zatrzymaj się i ustal, co w pierwotnym zgłoszeniu pozostało niejasne. Zapisz przydatne ustalenia, aktualny status w Git oraz pozostałe zadania przed wyczyszczeniem historii rozmowy.

Przewodnik po najlepszych praktykach firmy Anthropic zaleca rozpoczęcie od nowa po dwóch nieudanych próbach poprawienia tego samego problemu. Użyj polecenia /clear, a następnie podaj poprawioną podpowiedź uwzględniającą zdobyte informacje. Wyczyścicie rozmowy nie cofa zmian w plikach.

Naciśnij klawisz Esc, aby przerwać wykonywanie odpowiedzi. Gdy podpowiedź jest pusta, naciśnij dwukrotnie klawisz Esc, aby otworzyć menu cofania i wybrać element do przywrócenia. Cofanie nie cofa wszystkich efektów zewnętrznych, dlatego w przypadku zmian w bazach danych lub usługach zdalnych należy korzystać z punktów kontrolnych Git oraz oddzielnych procedur przywracania.

Zapisz wytyczne dotyczące całego projektu w pliku CLAUDE.md, powtarzalne procedury w sekcji „skills” oraz instrukcje dotyczące konkretnych plików w regułach o zasięgu ścieżki. Wykorzystaj haki do działań powiązanych z konkretnymi wydarzeniami, takimi jak uruchomienie formatownika po edycji.

Wybierz w zależności od tego, kiedy instrukcja ma mieć zastosowanie:

Wymagania dotyczące danej funkcji zazwyczaj powinny znajdować się w opisie zadania lub specyfikacji, a nie w pliku CLAUDE.md. Dodawanie tymczasowych instrukcji do pliku obejmującego cały projekt utrudnia odróżnienie ich od konwencji, które powinny obowiązywać w całym repozytorium.

Na przykład umieść komendę testową projektu w pliku CLAUDE.md, umieść konwencje dotyczące poszczególnych komponentów w regule o zasięgu ścieżki oraz zapisz powtarzającą się procedurę przeglądu jako umiejętność. Przeglądaj te pliki w przypadku zmian komend lub konwencji, tak samo jak w przypadku pozostałej dokumentacji projektu.

Podpowiedzi, plik CLAUDE.md oraz przewodnik po umiejętnościach kierują zachowaniem Claude’a; nie gwarantują one jednak, że instrukcja zostanie wykonana. Haki mogą przeprowadzać kontrole przy określonych wydarzeniach, ale ich niezawodność zależy od typu haka i sposobu jego implementacji.

Hook komend uruchamia skrypt. Hook podpowiedzi lub agenta opiera się na ocenie modelu. Jak wyjaśnia przewodnik najlepszych praktyk firmy Anthropic: „Hook podpowiedzi lub agenta prosi inny model o podjęcie decyzji, więc również nie jest deterministyczny”. W przypadku reguły, która musi być egzekwowana, należy zastosować odpowiednie mechanizmy kontroli uprawnień i przetestować odpowiedni hook komend lub HTTP, w tym sposób, w jaki radzi sobie on z błędami.

Niestandardowe podagenty to kolejny sposób na organizację powtarzających się zadań. Zdefiniuj specjalistę w katalogu `claude/agents/`, gdy potrzebna jest odrębna rola recenzenta lub zakres narzędzi, zamiast dodawać każdą instrukcję dla specjalisty do głównej sesji. Dodatkowe informacje znajdziesz w tych przewodnikach dotyczących najlepszego modelu Claude do pracy oraz rodzajów agentów AI.

Jeśli Twój zespół zarządza podpowiedziami w ramach kilku produktów opartych na sztucznej inteligencji, zapoznaj się z tymi narzędziami do inżynierii podpowiedzi, które umożliwiają zarządzanie bibliotekami wykraczającymi poza Claude Code.

Gdy sesja daje niekompletny lub nieodpowiedni wynik, sprawdź, czy w żądaniu pozostawiono ważne decyzje nierozstrzygnięte. Te pięć błędów może utrudnić diagnozowanie i przeglądanie kodu.

Polecenie „Zbadaj repozytorium” nie daje Claude’owi zbyt wielu wskazówek dotyczących tego, które pliki są istotne ani kiedy należy zakończyć analizę. Możesz otrzymać ogólne podsumowanie bez odpowiedzi na problem, który stał się przyczyną wysłania zapytania.

Określ zachowanie lub decyzję, którą musisz zrozumieć, wskaż lokalizację początkową i zdefiniuj oczekiwany wynik. Na przykład: „Prześledź, w jaki sposób ten punkt końcowy sprawdza uprawnienia, i wskaż odpowiednie funkcje”. Jeśli korzystasz z podagentów, zadaj każdemu z nich konkretne pytanie, zamiast zlecać im to samo nieograniczone wyszukiwanie.

Przełączanie się między funkcją, niepowiązanym błędem a prośbą o uzupełnienie dokumentacji powoduje, że w rozmowie pozostaje kontekst, który może nie mieć zastosowania do bieżącego zadania. Odniesienia takie jak „ten plik” lub „poprzednie podejście” stają się niejednoznaczne.

Do niepowiązanych zadań używaj oddzielnych sesji. Jeśli wiele sesji będzie edytować repozytorium, używaj oddzielnych drzew roboczych Git, aby nie modyfikowały tego samego katalogu roboczego. Na marginesie: komenda /btw w Claude Code pozwala zachować wymianę wiadomości poza główną historią rozmowy.

Kompilacja może zakończyć się powodzeniem, mimo że dana funkcja działa nieprawidłowo. Zestaw testów może zakończyć się powodzeniem, ponieważ nigdy nie przetestowano w nim nieprawidłowych danych wejściowych. Poproszenie Claude’a o „uruchomienie testów” nie pozwala ustalić, które wymagania te testy weryfikują.

Przyporządkuj kryteria akceptacji do konkretnych testów. W przypadku naprawy błędu poproś o dowód, że test odtworzenia zakończył się niepowodzeniem przed wprowadzeniem zmiany, a po jej wprowadzeniu zakończył się powodzeniem. Nie traktuj pojedynczego pomyślnego polecenia jako weryfikacji całej zmiany, lecz zapewnij widoczność kryteriów, które nie zostały jeszcze przetestowane.

Rozbudowujący się plik CLAUDE.md może zawierać nieaktualne komendy, zduplikowane reguły oraz instrukcje sprzeczne z wymaganiami konkretnych zadań. Dodanie bardziej stanowczych sformułowań nie rozwiązuje tych konfliktów.

Porównaj plik z aktualnym repozytorium. Usuń nieaktualne wytyczne, wyjaśnij sprzeczne reguły i przenieś instrukcje o wąskim zakresie zastosowania do reguł lub umiejętności o zasięgu ścieżki. Jeśli wymagane jest egzekwowanie danego wymogu, skonfiguruj i przetestuj odpowiednie mechanizmy kontrolne zamiast polegać na powtarzających się przypomnieniach.

W wyniku przeglądu mogą zostać wykryte zarówno rzeczywiste błędy, jak i niejasne wątpliwości oraz opcjonalne sugestie dotyczące refaktoryzacji. Zastosowanie każdej sugestii może spowodować rozszerzenie zakresu zmian bez poprawy pożądanego zachowania.

Zapytaj o dowody i skutki każdego ustalenia. Nadaj priorytet problemom związanym z poprawnością i niespełnionymi wymaganiami, zbadaj niejasne twierdzenia i nie uwzględniaj w bieżącej różnicy zmian niezwiązanych z tematem ulepszeń. Recenzent powinien być w stanie zgłosić brak ustaleń wymagających podjęcia działań, jeśli dowody zapewniają wsparcie dla takiego wniosku.

Aby dostosować szablon, zastąp w nim symbole zastępcze danymi z Twojego projektu i przed wprowadzeniem zmian zdecyduj, co ma zrobić Claude. Skorzystaj z poniższych kroków, aby przygotować zapytanie i sprawdzić wynik.

W przypadku niewielkiej, jasno zdefiniowanej zmiany możesz poprosić Claude'a o jej bezpośrednie wdrożenie. W przypadku nieznanego kodu, zmian obejmujących kilka plików lub nierozstrzygniętych wymagań zacznij od opracowania planu.

Naciśnij klawisze Shift+Tab, aż pojawi się tryb Planowania, lub uruchom Claude Code za pomocą polecenia claude --permission-mode plan. W tym trybie Claude może przeglądać pliki i wykonywać komendy tylko do odczytu bez edytowania kodu źródłowego. Przejrzyj proponowane pliki, zależności i testy przed zatwierdzeniem implementacji. Naciśnij klawisze Ctrl+G, aby otworzyć proponowany plan w redaktorze.

Przekaż Claude'owi informacje niezbędne do zrozumienia zadania: odnośnik do pliku, oczyszczony dziennik błędów, zrzut ekranu lub dokument zawierający wymagania. Użyj znaku @, po którym podaj ścieżkę do pliku, aby dołączyć jego zawartość.

Wybierz najmniejszy użyteczny zestaw źródeł. Dołączenie całego dziennika lub katalogu może spowodować dodanie nieistotnych treści i nadmierne obciążenie kontekstu. Przed udostępnianiem dzienników usuń dane uwierzytelniające i dane wrażliwe oraz sprawdź, czy Claude dysponuje narzędziami niezbędnymi do pobrania podanych przez Ciebie adresów URL dokumentacji.

Na przykład polecenie `cat błąd.log | claude -p "Explain this błąd"` przesyła dziennik w ramach żądania nieinteraktywnego. Należy z niego korzystać dopiero po sprawdzeniu zawartości pliku. Na tym polega praktyczna wartość kontekstowej sztucznej inteligencji: dostarczanie modelowi informacji istotnych dla danego zadania.

Dodając nową funkcję, zidentyfikuj podobny komponent lub funkcję w repozytorium. Poinformuj Claude'a, jakich konwencji ma przestrzegać, np. dotyczących klienta API, logiki walidacji, obsługi błędów lub struktury testów.

„Zobacz, jak plik @src/widgets/Weather.tsx pobiera i buforuje dane” stanowi dla Claude’a konkretny punkt odniesienia. Wskaż również wszelkie różnice wymagane przez nową funkcję, aby nie kopiowała ona zachowań, które już nie są aktualne. Konwencje te powinny odzwierciedlać cykl pracy Twojego zespołu.

W przypadku zmian w kodzie należy określić odpowiednią komendę testową, kompilacyjną lub lintującą oraz zachowanie, które ma zostać sprawdzone. W przypadku badań należy poprosić o odniesienia do plików lub ID commitów. W przypadku prac nad interfejsem użytkownika należy dostarczyć obraz referencyjny oraz skonfigurowany sposób uchwycenia implementacji w tym samym oknie wyświetlania.

Poproś Claude'a o raportowanie tego, co faktycznie sprawdził, w tym błędów i pominiętych kontroli. Sprawdź, czy dowody potwierdzają spełnienie wymagań; pomyślna kompilacja nie gwarantuje, że każde wymagane zachowanie działa poprawnie.

W przypadku dłuższych zadań Claude Code oferuje również warunek /goal oraz haki Stop. Moduł oceny celu analizuje informacje ujawnione w rozmowie, zamiast samodzielnie sprawdzać pliki lub uruchamiać testy. Skonfigurowany hak Stop może zablokować zakończenie zadania, ale ma limity dotyczące wielokrotnego blokowania. Żadne z tych rozwiązań nie zastępuje odpowiednich testów ani przeglądu przeprowadzanego przez człowieka.

Jeśli powtarzające się poprawki nie rozwiązują problemu, zatrzymaj się i ustal, co w pierwotnym zgłoszeniu pozostało niejasne. Zapisz przydatne ustalenia, aktualny status w Git oraz pozostałe zadania przed wyczyszczeniem rozmowy.

Przewodnik po najlepszych praktykach firmy Anthropic zaleca rozpoczęcie od nowa po dwóch nieudanych próbach poprawienia tego samego problemu. Użyj polecenia /clear, a następnie podaj poprawioną podpowiedź uwzględniającą zdobyte informacje. Wyczyścicie rozmowy nie cofa zmian w plikach.

Naciśnij klawisz Esc, aby przerwać wykonywanie odpowiedzi. Gdy podpowiedź jest pusta, naciśnij dwukrotnie klawisz Esc, aby otworzyć menu cofania i wybrać element do przywrócenia. Cofanie nie cofa wszystkich efektów zewnętrznych, dlatego w przypadku zmian w bazach danych lub usługach zdalnych należy korzystać z punktów kontrolnych Git oraz oddzielnych procedur przywracania.

Zapisz wytyczne dotyczące całego projektu w pliku CLAUDE.md, powtarzalne procedury w sekcji „skills” oraz instrukcje dotyczące konkretnych plików w regułach o zasięgu ścieżki. Wykorzystaj haki do działań powiązanych z konkretnymi wydarzeniami, takimi jak uruchomienie formatownika po edycji.

Wybierz w zależności od tego, kiedy instrukcja ma mieć zastosowanie:

Wymagania dotyczące danej funkcji zazwyczaj powinny znajdować się w opisie zadania lub specyfikacji, a nie w pliku CLAUDE.md. Dodawanie tymczasowych instrukcji do pliku obejmującego cały projekt utrudnia odróżnienie ich od konwencji, które powinny obowiązywać w całym repozytorium.

Na przykład: umieść komendę testową projektu w pliku CLAUDE.md, umieść konwencje dotyczące poszczególnych komponentów w regule o zasięgu ścieżki oraz zapisz powtarzającą się procedurę przeglądu jako umiejętność. Przeglądaj te pliki w przypadku zmian komend lub konwencji, tak samo jak w przypadku pozostałej dokumentacji projektu.

Podpowiedzi, plik CLAUDE.md oraz przewodnik po umiejętnościach kierują zachowaniem Claude’a; nie gwarantują one jednak, że instrukcja zostanie wykonana. Haki mogą przeprowadzać kontrole przy określonych wydarzeniach, ale ich niezawodność zależy od typu haka i sposobu jego implementacji.

Hook komend uruchamia skrypt. Hook podpowiedzi lub agenta opiera się na ocenie modelu. Jak wyjaśnia przewodnik najlepszych praktyk firmy Anthropic: „Hook podpowiedzi lub agenta prosi inny model o podjęcie decyzji, więc również nie jest deterministyczny”. W przypadku reguły, która musi być egzekwowana, należy zastosować odpowiednie mechanizmy kontroli uprawnień i przetestować odpowiedni hook komend lub HTTP, w tym sposób, w jaki radzi sobie on z błędami.

Niestandardowe podagenty to kolejny sposób na organizację powtarzających się zadań. Zdefiniuj specjalistę w katalogu `claude/agents/`, gdy potrzebna jest odrębna rola recenzenta lub zakres narzędzi, zamiast dodawać każdą instrukcję dla specjalisty do głównej sesji. Dodatkowe informacje znajdziesz w tych przewodnikach dotyczących najlepszego modelu Claude do pracy oraz rodzajów agentów AI.

Jeśli Twój zespół zarządza podpowiedziami w ramach kilku produktów opartych na AI, zapoznaj się z tymi narzędziami do inżynierii podpowiedzi, które umożliwiają zarządzanie bibliotekami wykraczającymi poza Claude Code.

Gdy sesja daje niekompletny lub nieodpowiedni wynik, sprawdź, czy w żądaniu pozostawiono ważne decyzje nierozstrzygnięte. Te pięć błędów może utrudnić diagnozowanie i przeglądanie kodu.

Polecenie „Zbadaj repozytorium” nie daje Claude’owi zbyt wielu wskazówek dotyczących tego, które pliki są istotne ani kiedy należy zakończyć analizę. Możesz otrzymać ogólne podsumowanie bez odpowiedzi na problem, który stał się przyczyną wysłania zapytania.

Określ zachowanie lub decyzję, którą musisz zrozumieć, wskaż lokalizację początkową i zdefiniuj oczekiwany wynik. Na przykład: „Prześledź, w jaki sposób ten punkt końcowy sprawdza uprawnienia, i wskaż odpowiednie funkcje”. Jeśli korzystasz z podagentów, zadaj każdemu z nich konkretne pytanie, zamiast zlecać im to samo nieograniczone wyszukiwanie.

Przełączanie się między funkcją, niepowiązanym błędem a prośbą o uzupełnienie dokumentacji powoduje, że w rozmowie pozostaje kontekst, który może nie mieć zastosowania do bieżącego zadania. Odniesienia takie jak „ten plik” lub „poprzednie podejście” stają się niejednoznaczne.

Do niepowiązanych zadań używaj oddzielnych sesji. Jeśli wiele sesji będzie edytować repozytorium, używaj oddzielnych drzew roboczych Git, aby nie modyfikowały tego samego katalogu roboczego. Krótka uwaga na marginesie: komenda /btw w Claude Code pozwala zachować wymianę wiadomości poza główną historią rozmowy.

Kompilacja może zakończyć się powodzeniem, mimo że dana funkcja działa nieprawidłowo. Zestaw testów może zakończyć się powodzeniem, ponieważ nigdy nie przetestowano w nim nieprawidłowych danych wejściowych. Poproszenie Claude’a o „uruchomienie testów” nie pozwala ustalić, które wymagania te testy weryfikują.

Przyporządkuj kryteria akceptacji do konkretnych testów. W przypadku naprawy błędu poproś o dowód, że test odtworzenia zakończył się niepowodzeniem przed wprowadzeniem zmiany, a po jej wprowadzeniu zakończył się powodzeniem. Nie traktuj pojedynczego pomyślnego polecenia jako weryfikacji całej zmiany, lecz zapewnij widoczność kryteriów, które nie zostały jeszcze przetestowane.

Rozbudowujący się plik CLAUDE.md może zawierać nieaktualne komendy, zduplikowane reguły oraz instrukcje sprzeczne z wymaganiami konkretnych zadań. Dodanie bardziej stanowczych sformułowań nie rozwiązuje tych konfliktów.

Porównaj plik z aktualnym repozytorium. Usuń nieaktualne wytyczne, wyjaśnij sprzeczne reguły i przenieś instrukcje o wąskim zakresie zastosowania do reguł lub umiejętności o zasięgu ścieżki. Jeśli wymaganie wymaga egzekwowania, skonfiguruj i przetestuj odpowiednie mechanizmy kontroli zamiast polegać na powtarzających się przypomnieniach.

W wyniku przeglądu mogą zostać wykryte zarówno rzeczywiste błędy, jak i niejasne wątpliwości oraz opcjonalne sugestie dotyczące refaktoryzacji. Zastosowanie każdej sugestii może spowodować rozszerzenie zakresu zmian bez poprawy pożądanego zachowania.

Zapytaj o dowody i skutki każdego ustalenia. Nadaj priorytet problemom związanym z poprawnością i niespełnionymi wymaganiami, zbadaj niepewne twierdzenia i nie uwzględniaj w bieżącej analizie różnic niezwiązanych z tematem ulepszeń. Recenzent powinien być w stanie zgłosić brak ustaleń wymagających podjęcia działań, jeśli dowody zapewniają wsparcie dla takiego wniosku.

Aby dostosować szablon, zastąp w nim symbole zastępcze danymi z Twojego projektu i przed wprowadzeniem zmian zdecyduj, co ma zrobić Claude. Skorzystaj z poniższych kroków, aby przygotować zapytanie i sprawdzić wynik.

W przypadku niewielkiej, jasno zdefiniowanej zmiany możesz poprosić Claude'a o jej bezpośrednie wdrożenie. W przypadku nieznanego kodu, zmian obejmujących kilka plików lub nierozstrzygniętych wymagań zacznij od opracowania planu.

Naciśnij klawisze Shift+Tab, aż pojawi się tryb Planowania, lub uruchom Claude Code za pomocą komendy claude --permission-mode plan. W tym trybie Claude może przeglądać pliki i wykonywać komendy tylko do odczytu bez edytowania kodu źródłowego. Przejrzyj proponowane pliki, zależności i testy przed zatwierdzeniem implementacji. Naciśnij klawisze Ctrl+G, aby otworzyć proponowany plan w redaktorze.

Przekaż Claude'owi informacje niezbędne do zrozumienia zadania: odnośnik do pliku, oczyszczony dziennik błędów, zrzut ekranu lub dokument zawierający wymagania. Użyj znaku @, po którym podaj ścieżkę do pliku, aby dołączyć jego zawartość.

Wybierz najmniejszy użyteczny zestaw źródeł. Dołączenie całego dziennika lub katalogu może spowodować dodanie nieistotnych treści i nadmierne obciążenie kontekstu. Przed udostępnianiem dzienników usuń dane uwierzytelniające i dane wrażliwe oraz sprawdź, czy Claude dysponuje narzędziami niezbędnymi do pobrania podanych przez Ciebie adresów URL dokumentacji.

Na przykład polecenie `cat błąd.log | claude -p "Wyjaśnij ten błąd"` przesyła dziennik w ramach żądania nieinteraktywnego. Należy z niego korzystać dopiero po sprawdzeniu zawartości pliku. Na tym polega praktyczna wartość kontekstowej sztucznej inteligencji: dostarczanie modelowi informacji istotnych dla danego zadania.

Dodając nową funkcję, zidentyfikuj podobny komponent lub funkcję w repozytorium. Poinformuj Claude'a, jakich konwencji ma przestrzegać, np. dotyczących klienta API, logiki walidacji, obsługi błędów lub struktury testów.

„Zobacz, jak plik @src/widgets/Weather.tsx pobiera i buforuje dane” stanowi dla Claude’a konkretny punkt odniesienia. Wskaż również wszelkie różnice wymagane przez nową funkcję, aby nie kopiowała ona zachowań, które już nie są aktualne. Konwencje te powinny odzwierciedlać cykl pracy tworzonego oprogramowania w Twoim zespole.

W przypadku zmian w kodzie należy określić odpowiednią komendę testową, kompilacyjną lub lintującą oraz zachowanie, które ma zostać sprawdzone. W przypadku badań należy poprosić o odniesienia do plików lub ID commitów. W przypadku prac nad interfejsem użytkownika należy dostarczyć obraz referencyjny oraz skonfigurowany sposób uchwycenia implementacji w tym samym oknie wyświetlania.

Poproś Claude'a o przedstawienie raportu dotyczącego tego, co faktycznie sprawdził, w tym błędów i pominiętych kontroli. Sprawdź, czy dowody potwierdzają spełnienie wymagań; pomyślna kompilacja nie gwarantuje, że każde wymagane zachowanie działa poprawnie.

W przypadku dłuższych zadań Claude Code oferuje również warunek /goal oraz haki Stop. Moduł oceny celu analizuje informacje ujawnione w rozmowie, zamiast samodzielnie sprawdzać pliki lub uruchamiać testy. Skonfigurowany hak Stop może zablokować zakończenie zadania, ale ma ograniczenia dotyczące wielokrotnego blokowania. Żadne z tych rozwiązań nie zastępuje odpowiednich testów ani przeglądu przeprowadzanego przez człowieka.

Jeśli powtarzające się poprawki nie rozwiązują problemu, zatrzymaj się i ustal, co w pierwotnym zgłoszeniu pozostało niejasne. Zapisz przydatne ustalenia, aktualny status w Git oraz pozostałe zadania przed wyczyszczeniem historii rozmowy.

Przewodnik po najlepszych praktykach firmy Anthropic zaleca rozpoczęcie od nowa po dwóch nieudanych próbach poprawienia tego samego problemu. Użyj polecenia /clear, a następnie podaj poprawioną podpowiedź uwzględniającą zdobyte informacje. Wyczyścicie rozmowy nie cofa zmian w plikach.

Naciśnij klawisz Esc, aby przerwać wykonywanie odpowiedzi. Gdy podpowiedź jest pusta, naciśnij dwukrotnie klawisz Esc, aby otworzyć menu cofania i wybrać, co chcesz przywrócić. Cofanie nie cofa wszystkich efektów zewnętrznych, dlatego w przypadku zmian w bazach danych lub usługach zdalnych należy korzystać z punktów kontrolnych Git oraz oddzielnych procedur przywracania.

Zapisz wytyczne dotyczące całego projektu w pliku CLAUDE.md, powtarzalne procedury w sekcji „skills” oraz instrukcje dotyczące konkretnych plików w regułach o zasięgu ścieżki. Wykorzystaj haki do działań powiązanych z konkretnymi wydarzeniami, takimi jak uruchomienie formatownika po edycji.

Wybierz w zależności od tego, kiedy instrukcja ma mieć zastosowanie:

Wymagania dotyczące danej funkcji zazwyczaj powinny znajdować się w opisie zadania lub specyfikacji, a nie w pliku CLAUDE.md. Dodawanie tymczasowych instrukcji do pliku obejmującego cały projekt utrudnia odróżnienie ich od konwencji, które powinny obowiązywać w całym repozytorium.

Na przykład: umieść komendę testową projektu w pliku CLAUDE.md, umieść konwencje dotyczące poszczególnych komponentów w regule o zasięgu ścieżki oraz zapisz powtarzającą się procedurę przeglądu jako umiejętność. Przeglądaj te pliki w przypadku zmian komend lub konwencji, tak samo jak w przypadku pozostałej dokumentacji projektu.

Podpowiedzi, plik CLAUDE.md oraz przewodnik po umiejętnościach kierują zachowaniem Claude’a; nie gwarantują one jednak, że instrukcja zostanie wykonana. Haki mogą przeprowadzać kontrole przy określonych wydarzeniach, ale ich niezawodność zależy od typu haka i sposobu jego implementacji.

Hook komend uruchamia skrypt. Hook podpowiedzi lub agenta opiera się na ocenie modelu. Jak wyjaśnia przewodnik najlepszych praktyk firmy Anthropic: „Hook podpowiedzi lub agenta prosi inny model o podjęcie decyzji, więc również nie jest deterministyczny”. W przypadku reguły, która musi być egzekwowana, należy zastosować odpowiednie mechanizmy kontroli uprawnień i przetestować odpowiedni hook komend lub HTTP, w tym sposób, w jaki radzi sobie on z błędami.

Niestandardowe podagenty to kolejny sposób na organizację powtarzających się zadań. Zdefiniuj specjalistę w katalogu `claude/agents/`, gdy potrzebna jest odrębna rola recenzenta lub zakres narzędzi, zamiast dodawać każdą instrukcję dla specjalisty do głównej sesji. Dodatkowe informacje znajdziesz w tych przewodnikach dotyczących najlepszego modelu Claude do pracy oraz rodzajów agentów AI.

Jeśli Twój zespół zarządza podpowiedziami w ramach kilku produktów opartych na AI, zapoznaj się z tymi narzędziami do inżynierii podpowiedzi, które umożliwiają zarządzanie bibliotekami wykraczającymi poza Claude Code.

Gdy sesja daje niekompletny lub nieodpowiedni wynik, sprawdź, czy w żądaniu pozostawiono ważne decyzje nierozstrzygnięte. Te pięć błędów może utrudnić diagnozowanie i przeglądanie kodu.

Polecenie „Zbadaj repozytorium” nie daje Claude’owi zbyt wielu wskazówek dotyczących tego, które pliki są istotne ani kiedy należy zakończyć analizę. Możesz otrzymać ogólne podsumowanie bez odpowiedzi na problem, który stał się przyczyną wysłania zapytania.

Określ zachowanie lub decyzję, którą musisz zrozumieć, wskaż lokalizację początkową i zdefiniuj oczekiwany wynik. Na przykład: „Prześledź, w jaki sposób ten punkt końcowy sprawdza uprawnienia, i wskaż odpowiednie funkcje”. Jeśli korzystasz z podagentów, zadaj każdemu z nich konkretne pytanie, zamiast zlecać im to samo nieograniczone wyszukiwanie.

Przełączanie się między funkcją, niepowiązanym błędem a prośbą o uzupełnienie dokumentacji powoduje, że w rozmowie pozostaje kontekst, który może nie mieć zastosowania do bieżącego zadania. Odniesienia takie jak „ten plik” lub „poprzednie podejście” stają się niejednoznaczne.

Do wykonywania niepowiązanych zadań używaj oddzielnych sesji. Jeśli wiele sesji będzie edytować repozytorium, używaj oddzielnych drzew roboczych Git, aby nie modyfikowały tego samego katalogu roboczego. Krótka uwaga na marginesie: komenda /btw w Claude Code pozwala zachować wymianę wiadomości poza główną historią rozmowy.

Kompilacja może zakończyć się powodzeniem, mimo że dana funkcja działa nieprawidłowo. Zestaw testów może zakończyć się powodzeniem, ponieważ nigdy nie przetestowano w nim nieprawidłowych danych wejściowych. Poproszenie Claude’a o „uruchomienie testów” nie pozwala ustalić, które wymagania te testy weryfikują.

Przyporządkuj kryteria akceptacji do konkretnych testów. W przypadku naprawy błędu poproś o dowód, że test odtworzenia zakończył się niepowodzeniem przed wprowadzeniem zmiany, a po jej wprowadzeniu zakończył się powodzeniem. Nie traktuj pojedynczego pomyślnego polecenia jako weryfikacji całej zmiany, lecz zapewnij widoczność kryteriów, które nie zostały jeszcze przetestowane.

Rozbudowujący się plik CLAUDE.md może zawierać nieaktualne komendy, zduplikowane reguły oraz instrukcje sprzeczne z wymaganiami konkretnych zadań. Dodanie bardziej stanowczego sformułowania nie rozwiązuje tych konfliktów.

Porównaj plik z aktualnym repozytorium. Usuń nieaktualne wytyczne, wyjaśnij sprzeczne reguły i przenieś instrukcje o wąskim zakresie zastosowania do reguł lub umiejętności o zasięgu ścieżki. Jeśli wymaganie wymaga egzekwowania, skonfiguruj i przetestuj odpowiednie mechanizmy kontroli zamiast polegać na powtarzających się przypomnieniach.

W wyniku przeglądu mogą zostać wykryte zarówno rzeczywiste błędy, jak i niejasne wątpliwości oraz opcjonalne sugestie dotyczące refaktoryzacji. Zastosowanie każdej sugestii może spowodować rozszerzenie zakresu zmian bez poprawy pożądanego zachowania.

Zapytaj o dowody i skutki każdego ustalenia. Nadaj priorytet problemom związanym z poprawnością i niespełnionymi wymaganiami, zbadaj niejasne twierdzenia i nie uwzględniaj w bieżącej różnicy zmian niezwiązanych z tematem ulepszeń. Recenzent powinien być w stanie zgłosić brak ustaleń wymagających działania, jeśli dowody zapewniają wsparcie dla takiego wniosku.

Aby dostosować szablon, zastąp w nim symbole zastępcze danymi z Twojego projektu i przed wprowadzeniem zmian zdecyduj, co ma zrobić Claude. Skorzystaj z poniższych kroków, aby przygotować zapytanie i sprawdzić wynik.

W przypadku niewielkiej, jasno zdefiniowanej zmiany możesz poprosić Claude'a o jej bezpośrednie wdrożenie. W przypadku nieznanego kodu, zmian obejmujących kilka plików lub nierozstrzygniętych wymagań zacznij od opracowania planu.

Naciśnij klawisze Shift+Tab, aż pojawi się tryb Planowania, lub uruchom Claude Code za pomocą polecenia claude --permission-mode plan. W tym trybie Claude może przeglądać pliki i wykonywać komendy tylko do odczytu bez edytowania kodu źródłowego. Przejrzyj proponowane pliki, zależności i testy przed zatwierdzeniem implementacji. Naciśnij klawisze Ctrl+G, aby otworzyć proponowany plan w redaktorze.

Przekaż Claude'owi informacje niezbędne do zrozumienia zadania: odnośnik do pliku, oczyszczony dziennik błędów, zrzut ekranu lub dokument zawierający wymagania. Użyj znaku @, po którym podaj ścieżkę do pliku, aby dołączyć jego zawartość.

Wybierz najmniejszy użyteczny zestaw źródeł. Dołączenie całego dziennika lub katalogu może spowodować dodanie nieistotnych treści i nadmierne obciążenie kontekstu. Przed udostępnianiem dzienników usuń dane uwierzytelniające i dane wrażliwe oraz sprawdź, czy Claude dysponuje narzędziami niezbędnymi do pobrania podanych przez Ciebie adresów URL dokumentacji.

Na przykład polecenie `cat błąd.log | claude -p "Wyjaśnij ten błąd"` przesyła dziennik w ramach żądania nieinteraktywnego. Należy z niego korzystać dopiero po sprawdzeniu zawartości pliku. Na tym polega praktyczna wartość kontekstowej sztucznej inteligencji: dostarczanie modelowi informacji istotnych dla danego zadania.

Dodając nową funkcję, zidentyfikuj podobny komponent lub funkcję w repozytorium. Poinformuj Claude'a, jakich konwencji ma przestrzegać, np. dotyczących klienta API, logiki walidacji, obsługi błędów lub struktury testów.

„Zobacz, jak plik @src/widgets/Weather.tsx pobiera i buforuje dane” stanowi dla Claude’a konkretny punkt odniesienia. Wskaż również wszelkie różnice wymagane przez nową funkcję, aby nie kopiowała ona zachowań, które już nie są aktualne. Konwencje te powinny odzwierciedlać cykl pracy tworzonego oprogramowania w Twoim zespole.

W przypadku zmian w kodzie należy określić odpowiednią komendę testową, kompilacyjną lub lintującą oraz zachowanie, które ma zostać sprawdzone. W przypadku badań należy poprosić o odniesienia do plików lub ID commitów. W przypadku prac nad interfejsem użytkownika należy dostarczyć obraz referencyjny oraz skonfigurowany sposób uchwycenia implementacji w tym samym oknie wyświetlania.

Poproś Claude'a o raportowanie tego, co faktycznie sprawdził, w tym błędów i pominiętych kontroli. Sprawdź, czy dowody potwierdzają spełnienie wymagań; pomyślna kompilacja nie gwarantuje, że każde wymagane zachowanie działa poprawnie.

W przypadku dłuższych zadań Claude Code oferuje również warunek /goal oraz haki Stop. Moduł oceny celu analizuje informacje ujawnione w rozmowie, zamiast samodzielnie sprawdzać pliki lub uruchamiać testy. Skonfigurowany hak Stop może zablokować zakończenie zadania, ale ma ograniczenia dotyczące wielokrotnego blokowania. Żadne z tych rozwiązań nie zastępuje odpowiednich testów ani przeglądu przeprowadzanego przez człowieka.

Jeśli powtarzające się poprawki nie rozwiązują problemu, zatrzymaj się i ustal, co w pierwotnym zgłoszeniu pozostało niejasne. Zapisz przydatne ustalenia, aktualny status w Git oraz pozostałe zadania przed wyczyszczeniem rozmowy.

Przewodnik po najlepszych praktykach firmy Anthropic zaleca rozpoczęcie od nowa po dwóch nieudanych próbach poprawienia tego samego problemu. Użyj polecenia /clear, a następnie podaj poprawioną podpowiedź uwzględniającą zdobyte informacje. Wyczyścicie rozmowy nie cofa zmian w plikach.

Naciśnij klawisz Esc, aby przerwać wykonywanie odpowiedzi. Gdy podpowiedź jest pusta, naciśnij dwukrotnie klawisz Esc, aby otworzyć menu cofania i wybrać, co chcesz przywrócić. Cofanie nie cofa wszystkich efektów zewnętrznych, dlatego w przypadku zmian w bazach danych lub usługach zdalnych należy korzystać z punktów kontrolnych Git oraz oddzielnych procedur przywracania.

Zapisz wytyczne dotyczące całego projektu w pliku CLAUDE.md, powtarzalne procedury w sekcji „skills” oraz instrukcje dotyczące konkretnych plików w regułach o zasięgu ścieżki. Wykorzystaj haki do działań powiązanych z konkretnymi wydarzeniami, takimi jak uruchomienie formatownika po edycji.

Wybierz w zależności od tego, kiedy instrukcja ma mieć zastosowanie:

Wymagania dotyczące danej funkcji zazwyczaj powinny znajdować się w opisie zadania lub specyfikacji, a nie w pliku CLAUDE.md. Dodawanie tymczasowych instrukcji do pliku obejmującego cały projekt utrudnia odróżnienie ich od konwencji, które powinny obowiązywać w całym repozytorium.

Na przykład: umieść komendę testową projektu w pliku CLAUDE.md, umieść konwencje dotyczące poszczególnych komponentów w regule o zasięgu ścieżki oraz zapisz powtarzającą się procedurę przeglądu jako umiejętność. Przeglądaj te pliki w przypadku zmian komend lub konwencji, tak samo jak w przypadku pozostałej dokumentacji projektu.

Podpowiedzi, plik CLAUDE.md oraz przewodnik po umiejętnościach kierują zachowaniem Claude’a; nie gwarantują one jednak, że instrukcja zostanie wykonana. Haki mogą przeprowadzać kontrole przy określonych wydarzeniach, ale ich niezawodność zależy od typu haka i sposobu jego implementacji.

Hook komend uruchamia skrypt. Hook podpowiedzi lub agenta opiera się na ocenie modelu. Jak wyjaśnia przewodnik najlepszych praktyk firmy Anthropic: „Hook podpowiedzi lub agenta prosi inny model o podjęcie decyzji, więc również nie jest deterministyczny”. W przypadku reguły, która musi być egzekwowana, należy zastosować odpowiednie mechanizmy kontroli uprawnień i przetestować odpowiedni hook komend lub HTTP, w tym sposób, w jaki radzi sobie on z błędami.

Niestandardowe podagenty to kolejny sposób na organizację powtarzających się zadań. Zdefiniuj specjalistę w katalogu `claude/agents/`, gdy potrzebna jest odrębna rola recenzenta lub zakres narzędzi, zamiast dodawać każdą instrukcję dla specjalisty do głównej sesji. Dodatkowe informacje znajdziesz w tych przewodnikach dotyczących najlepszego modelu Claude do pracy oraz rodzajów agentów AI.

Jeśli Twój zespół zarządza podpowiedziami w ramach kilku produktów opartych na AI, zapoznaj się z tymi narzędziami do inżynierii podpowiedzi, które umożliwiają zarządzanie bibliotekami wykraczającymi poza Claude Code.

Gdy sesja daje niekompletny lub nieodpowiedni wynik, sprawdź, czy w żądaniu pozostawiono ważne decyzje nierozstrzygnięte. Te pięć błędów może utrudnić diagnozowanie i przeglądanie kodu.

Polecenie „Zbadaj repozytorium” nie daje Claude’owi zbyt wielu wskazówek dotyczących tego, które pliki są istotne ani kiedy należy zakończyć analizę. Możesz otrzymać ogólne podsumowanie bez odpowiedzi na problem, który stał się przyczyną wysłania zapytania.

Określ zachowanie lub decyzję, którą musisz zrozumieć, wskaż lokalizację początkową i zdefiniuj oczekiwany wynik. Na przykład: „Prześledź, w jaki sposób ten punkt końcowy sprawdza uprawnienia, i wskaż odpowiednie funkcje”. Jeśli korzystasz z podagentów, zadaj każdemu z nich konkretne pytanie, zamiast zlecać im to samo nieograniczone wyszukiwanie.

Przełączanie się między funkcją, niepowiązanym błędem a prośbą o uzupełnienie dokumentacji powoduje, że w rozmowie pozostaje kontekst, który może nie mieć zastosowania do bieżącego zadania. Odniesienia takie jak „ten plik” lub „poprzednie podejście” stają się niejednoznaczne.

Do niepowiązanych zadań używaj oddzielnych sesji. Jeśli wiele sesji będzie edytować repozytorium, używaj oddzielnych drzew roboczych Git, aby nie modyfikowały tego samego katalogu roboczego. Krótka uwaga na marginesie: komenda /btw w Claude Code pozwala zachować wymianę wiadomości poza główną historią rozmowy.

Kompilacja może zakończyć się powodzeniem, mimo że dana funkcja działa nieprawidłowo. Zestaw testów może zakończyć się powodzeniem, ponieważ nigdy nie przetestowano w nim nieprawidłowych danych wejściowych. Poproszenie Claude’a o „uruchomienie testów” nie pozwala ustalić, które wymagania te testy weryfikują.

Przyporządkuj kryteria akceptacji do konkretnych testów. W przypadku naprawy błędu poproś o dowód, że test odtworzenia zakończył się niepowodzeniem przed wprowadzeniem zmiany, a po jej wprowadzeniu zakończył się powodzeniem. Nie traktuj jednego pomyślnie wykonanej komendy jako weryfikacji całej zmiany, lecz zapewnij widoczność kryteriów, które nie zostały jeszcze przetestowane.

Rozbudowujący się plik CLAUDE.md może zawierać nieaktualne komendy, zduplikowane reguły oraz instrukcje sprzeczne z wymaganiami konkretnych zadań. Dodanie bardziej stanowczych sformułowań nie rozwiązuje tych konfliktów.

Porównaj plik z aktualnym repozytorium. Usuń nieaktualne wytyczne, wyjaśnij sprzeczne reguły i przenieś instrukcje o wąskim zakresie zastosowania do reguł lub umiejętności o zasięgu ścieżki. Jeśli wymaganie wymaga egzekwowania, skonfiguruj i przetestuj odpowiednie mechanizmy kontroli zamiast polegać na powtarzających się przypomnieniach.

W wyniku przeglądu mogą zostać wykryte zarówno rzeczywiste błędy, jak i niejasne wątpliwości oraz opcjonalne sugestie dotyczące refaktoryzacji. Zastosowanie każdej sugestii może spowodować rozszerzenie zakresu zmian bez poprawy pożądanego zachowania.

Zapytaj o dowody i skutki każdego ustalenia. Nadaj priorytet problemom związanym z poprawnością i niespełnionymi wymaganiami, zbadaj niepewne twierdzenia i nie uwzględniaj w bieżącej analizie różnic niezwiązanych z tematem ulepszeń. Recenzent powinien być w stanie zgłosić brak ustaleń wymagających podjęcia działań, jeśli dowody zapewniają wsparcie dla takiego wniosku.

Aby dostosować szablon, zastąp w nim symbole zastępcze danymi z Twojego projektu i przed wprowadzeniem zmian zdecyduj, co ma zrobić Claude. Skorzystaj z poniższych kroków, aby przygotować zapytanie i sprawdzić wynik.

W przypadku niewielkiej, jasno zdefiniowanej zmiany możesz poprosić Claude'a o jej bezpośrednie wdrożenie. W przypadku nieznanego kodu, zmian obejmujących kilka plików lub nierozstrzygniętych wymagań zacznij od opracowania planu.

Naciśnij klawisze Shift+Tab, aż pojawi się tryb Planowania, lub uruchom Claude Code za pomocą komendy claude --permission-mode plan. W tym trybie Claude może przeglądać pliki i wykonywać komendy tylko do odczytu bez edytowania kodu źródłowego. Przejrzyj proponowane pliki, zależności i testy przed zatwierdzeniem implementacji. Naciśnij klawisze Ctrl+G, aby otworzyć proponowany plan w redaktorze.

Przekaż Claude'owi informacje niezbędne do zrozumienia zadania: odnośnik do pliku, oczyszczony dziennik błędów, zrzut ekranu lub dokument zawierający wymagania. Użyj znaku @, po którym podaj ścieżkę do pliku, aby dołączyć jego zawartość.

Wybierz najmniejszy użyteczny zestaw źródeł. Dołączenie całego dziennika lub katalogu może spowodować dodanie nieistotnych treści i nadmierne obciążenie kontekstu. Przed udostępnianiem dzienników usuń dane uwierzytelniające i dane wrażliwe oraz sprawdź, czy Claude dysponuje narzędziami niezbędnymi do pobrania podanych przez Ciebie adresów URL dokumentacji.

Na przykład polecenie `cat błąd.log | claude -p "Wyjaśnij ten błąd"` przesyła dziennik w ramach żądania nieinteraktywnego. Należy z niego korzystać dopiero po sprawdzeniu zawartości pliku. Na tym polega praktyczna wartość kontekstowej AI: dostarczanie modelowi informacji istotnych dla danego zadania.

Dodając nową funkcję, zidentyfikuj podobny komponent lub funkcję w repozytorium. Poinformuj Claude'a, jakich konwencji ma przestrzegać, np. dotyczących klienta API, logiki walidacji, obsługi błędów lub struktury testów.

„Zobacz, jak plik @src/widgets/Weather.tsx pobiera i buforuje dane” stanowi dla Claude’a konkretny punkt odniesienia. Wskaż również wszelkie różnice wymagane przez nową funkcję, aby nie kopiowała ona zachowań, które już nie są aktualne. Konwencje te powinny odzwierciedlać cykl pracy w Twoim zespole.

W przypadku zmian w kodzie należy określić odpowiednią komendę testową, kompilacyjną lub lintującą oraz zachowanie, które ma zostać sprawdzone. W przypadku badań należy poprosić o odniesienia do plików lub ID commitów. W przypadku prac nad interfejsem użytkownika należy dostarczyć obraz referencyjny oraz skonfigurowany sposób uchwycenia implementacji w tym samym oknie wyświetlania.

Poproś Claude'a o raportowanie tego, co faktycznie sprawdził, w tym błędów i pominiętych kontroli. Sprawdź, czy dowody potwierdzają spełnienie wymagań; pomyślna kompilacja nie gwarantuje, że każde wymagane zachowanie działa poprawnie.

W przypadku dłuższych zadań Claude Code oferuje również warunek /goal oraz haki Stop. Moduł oceny celu analizuje informacje ujawnione w rozmowie, zamiast samodzielnie sprawdzać pliki lub uruchamiać testy. Skonfigurowany hak Stop może zablokować zakończenie zadania, ale ma ograniczenia dotyczące wielokrotnego blokowania. Żadne z tych rozwiązań nie zastępuje odpowiednich testów ani przeglądu przeprowadzanego przez człowieka.

Jeśli powtarzające się poprawki nie rozwiązują problemu, zatrzymaj się i ustal, co w pierwotnym zgłoszeniu pozostało niejasne. Zapisz przydatne ustalenia, aktualny status w Git oraz pozostałe zadania przed wyczyszczeniem historii rozmowy.

Przewodnik po najlepszych praktykach firmy Anthropic zaleca rozpoczęcie od nowa po dwóch nieudanych próbach poprawienia tego samego problemu. Użyj polecenia /clear, a następnie podaj poprawioną podpowiedź uwzględniającą zdobyte informacje. Wyczyścicie rozmowy nie cofa zmian w plikach.

Naciśnij klawisz Esc, aby przerwać wykonywanie odpowiedzi. Gdy podpowiedź jest pusta, naciśnij dwukrotnie klawisz Esc, aby otworzyć menu cofania i wybrać, co chcesz przywrócić. Cofanie nie cofa wszystkich efektów zewnętrznych, dlatego w przypadku zmian w bazach danych lub usługach zdalnych należy korzystać z punktów kontrolnych Git oraz oddzielnych procedur przywracania.

Zapisz wytyczne dotyczące całego projektu w pliku CLAUDE.md, powtarzalne procedury w sekcji „skills” oraz instrukcje dotyczące konkretnych plików w regułach o zasięgu ścieżki. Wykorzystaj haki do działań powiązanych z konkretnymi wydarzeniami, takimi jak uruchomienie formatownika po edycji.

Wybierz w zależności od tego, kiedy instrukcja ma mieć zastosowanie:

Wymagania dotyczące danej funkcji zazwyczaj powinny znajdować się w opisie zadania lub specyfikacji, a nie w pliku CLAUDE.md. Dodawanie tymczasowych instrukcji do pliku obejmującego cały projekt utrudnia odróżnienie ich od konwencji, które powinny obowiązywać w całym repozytorium.

Na przykład: umieść komendę testową projektu w pliku CLAUDE.md, umieść konwencje dotyczące poszczególnych komponentów w regule o zasięgu ścieżki oraz zapisz powtarzającą się procedurę przeglądu jako umiejętność. Przeglądaj te pliki w przypadku zmian komend lub konwencji, tak samo jak w przypadku pozostałej dokumentacji projektu.

Podpowiedzi, plik CLAUDE.md oraz przewodnik po umiejętnościach kierują zachowaniem Claude’a; nie gwarantują one jednak, że instrukcja zostanie wykonana. Haki mogą przeprowadzać kontrole przy określonych wydarzeniach, ale ich niezawodność zależy od typu haka i sposobu jego implementacji.

Hook komend uruchamia skrypt. Hook podpowiedzi lub agenta opiera się na ocenie modelu. Jak wyjaśnia przewodnik najlepszych praktyk firmy Anthropic: „Hook podpowiedzi lub agenta prosi inny model o podjęcie decyzji, więc również nie jest deterministyczny”. W przypadku reguły, która musi być egzekwowana, należy zastosować odpowiednie mechanizmy kontroli uprawnień i przetestować odpowiedni hook komend lub HTTP, w tym sposób, w jaki radzi sobie on z błędami.

Niestandardowe podagenty to kolejny sposób na organizację powtarzających się zadań. Zdefiniuj specjalistę w katalogu `claude/agents/`, gdy potrzebna jest odrębna rola recenzenta lub zakres narzędzi, zamiast dodawać każdą instrukcję dla specjalisty do głównej sesji. Dodatkowe informacje znajdziesz w tych przewodnikach dotyczących najlepszego modelu Claude do pracy oraz rodzajów agentów AI.

Jeśli Twój zespół zarządza podpowiedziami w ramach kilku produktów opartych na AI, zapoznaj się z tymi narzędziami do inżynierii podpowiedzi, które umożliwiają zarządzanie bibliotekami wykraczającymi poza Claude Code.

Gdy sesja daje niekompletny lub nieodpowiedni wynik, sprawdź, czy w żądaniu pozostawiono ważne decyzje nierozstrzygnięte. Te pięć błędów może utrudnić diagnozowanie i przeglądanie kodu.

Polecenie „Zbadaj repozytorium” nie daje Claude’owi zbyt wielu wskazówek dotyczących tego, które pliki są istotne ani kiedy należy zakończyć analizę. Możesz otrzymać ogólne podsumowanie bez odpowiedzi na problem, który stał się przyczyną wysłania zapytania.

Określ zachowanie lub decyzję, którą musisz zrozumieć, wskaż lokalizację początkową i zdefiniuj oczekiwany wynik. Na przykład: „Prześledź, w jaki sposób ten punkt końcowy sprawdza uprawnienia, i wskaż odpowiednie funkcje”. Jeśli korzystasz z podagentów, zadaj każdemu z nich konkretne pytanie, zamiast zlecać im to samo nieograniczone wyszukiwanie.

Przełączanie się między funkcją, niepowiązanym błędem a prośbą o uzupełnienie dokumentacji powoduje, że w rozmowie pozostaje kontekst, który może nie mieć zastosowania do bieżącego zadania. Odniesienia takie jak „ten plik” lub „poprzednie podejście” stają się niejednoznaczne.

Do niepowiązanych zadań używaj oddzielnych sesji. Jeśli wiele sesji będzie edytować repozytorium, używaj oddzielnych drzew roboczych Git, aby nie modyfikowały tego samego katalogu roboczego. Krótka uwaga na marginesie: komenda /btw w Claude Code pozwala zachować wymianę wiadomości poza główną historią rozmowy.

Kompilacja może zakończyć się powodzeniem, mimo że dana funkcja działa nieprawidłowo. Zestaw testów może zakończyć się powodzeniem, ponieważ nigdy nie przetestowano w nim nieprawidłowych danych wejściowych. Poproszenie Claude’a o „uruchomienie testów” nie pozwala ustalić, które wymagania te testy weryfikują.

Przyporządkuj kryteria akceptacji do konkretnych testów. W przypadku naprawy błędu poproś o dowód, że test odtworzenia zakończył się niepowodzeniem przed wprowadzeniem zmiany, a po jej wprowadzeniu zakończył się powodzeniem. Nie traktuj pojedynczego pomyślnego polecenia jako weryfikacji całej zmiany, lecz zapewnij widoczność kryteriów, które nie zostały jeszcze przetestowane.

Rozbudowujący się plik CLAUDE.md może zawierać nieaktualne komendy, zduplikowane reguły oraz instrukcje sprzeczne z wymaganiami konkretnych zadań. Dodanie bardziej stanowczego sformułowania nie rozwiązuje tych konfliktów.

Porównaj plik z aktualnym repozytorium. Usuń nieaktualne wytyczne, wyjaśnij sprzeczne reguły i przenieś instrukcje o wąskim zakresie zastosowania do reguł lub umiejętności o zasięgu ścieżki. Jeśli wymagane jest egzekwowanie danego wymogu, skonfiguruj i przetestuj odpowiednie mechanizmy kontrolne zamiast polegać na powtarzających się przypomnieniach.

W wyniku przeglądu mogą zostać wykryte zarówno rzeczywiste błędy, jak i niejasne wątpliwości oraz opcjonalne sugestie dotyczące refaktoryzacji. Zastosowanie każdej sugestii może spowodować rozszerzenie zakresu zmian bez poprawy pożądanego zachowania.

Zapytaj o dowody i skutki każdego ustalenia. Nadaj priorytet problemom związanym z poprawnością i niespełnionymi wymaganiami, zbadaj niepewne twierdzenia i nie uwzględniaj w bieżącej analizie różnic niezwiązanych z tematem ulepszeń. Recenzent powinien być w stanie zgłosić brak ustaleń wymagających podjęcia działań, jeśli dowody zapewniają wsparcie dla takiego wniosku.

Aby dostosować szablon, zastąp w nim symbole zastępcze danymi z Twojego projektu i przed wprowadzeniem zmian zdecyduj, co ma zrobić Claude. Skorzystaj z poniższych kroków, aby przygotować zapytanie i sprawdzić wynik.

W przypadku niewielkiej, jasno zdefiniowanej zmiany możesz poprosić Claude'a o jej bezpośrednie wdrożenie. W przypadku nieznanego kodu, zmian obejmujących kilka plików lub nierozstrzygniętych wymagań zacznij od opracowania planu.

Naciśnij klawisze Shift+Tab, aż pojawi się tryb Planowania, lub uruchom Claude Code za pomocą komendy claude --permission-mode plan. W tym trybie Claude może przeglądać pliki i wykonywać komendy tylko do odczytu bez edytowania kodu źródłowego. Przejrzyj proponowane pliki, zależności i testy przed zatwierdzeniem implementacji. Naciśnij klawisze Ctrl+G, aby otworzyć proponowany plan w redaktorze.

Przekaż Claude'owi informacje niezbędne do zrozumienia zadania: odnośnik do pliku, oczyszczony dziennik błędów, zrzut ekranu lub dokument zawierający wymagania. Użyj znaku @, po którym podaj ścieżkę do pliku, aby dołączyć jego zawartość.

Wybierz najmniejszy użyteczny zestaw źródeł. Dołączenie całego dziennika lub katalogu może spowodować dodanie nieistotnych treści i nadmierne obciążenie kontekstu. Przed udostępnianiem dzienników usuń dane uwierzytelniające i dane wrażliwe oraz sprawdź, czy Claude dysponuje narzędziami niezbędnymi do pobrania podanych przez Ciebie adresów URL dokumentacji.

Na przykład polecenie `cat błąd.log | claude -p "Explain this błąd"` przesyła dziennik w ramach żądania nieinteraktywnego. Należy z niego korzystać dopiero po sprawdzeniu zawartości pliku. Na tym polega praktyczna wartość kontekstowej sztucznej inteligencji: dostarczanie modelowi informacji istotnych dla danego zadania.

Dodając nową funkcję, zidentyfikuj podobny komponent lub funkcję w repozytorium. Poinformuj Claude'a, jakich konwencji ma przestrzegać, np. dotyczących klienta API, logiki walidacji, obsługi błędów lub struktury testów.

„Zobacz, jak plik @src/widgets/Weather.tsx pobiera i buforuje dane” stanowi dla Claude’a konkretny punkt odniesienia. Wskaż również wszelkie różnice wymagane przez nową funkcję, aby nie kopiowała ona zachowań, które już nie są aktualne. Konwencje te powinny odzwierciedlać cykl pracy tworzonego oprogramowania w Twoim zespole.

W przypadku zmian w kodzie należy określić odpowiednią komendę testową, kompilacyjną lub lintującą oraz zachowanie, które ma zostać sprawdzone. W przypadku badań należy poprosić o odniesienia do plików lub ID commitów. W przypadku prac nad interfejsem użytkownika należy dostarczyć obraz referencyjny oraz skonfigurowany sposób uchwycenia implementacji w tym samym oknie wyświetlania.

Poproś Claude'a o raportowanie tego, co faktycznie sprawdził, w tym błędów i pominiętych kontroli. Sprawdź, czy dowody potwierdzają spełnienie wymagań; pomyślna kompilacja nie gwarantuje, że każde wymagane zachowanie działa poprawnie.

W przypadku dłuższych zadań Claude Code oferuje również warunek /goal oraz haki Stop. Moduł oceny celu analizuje informacje ujawnione w rozmowie, zamiast samodzielnie sprawdzać pliki lub uruchamiać testy. Skonfigurowany hak Stop może zablokować zakończenie zadania, ale ma ograniczenia dotyczące wielokrotnego blokowania. Żadne z tych rozwiązań nie zastępuje odpowiednich testów ani przeglądu przeprowadzanego przez człowieka.

Jeśli powtarzające się poprawki nie rozwiązują problemu, zatrzymaj się i ustal, co w pierwotnym zgłoszeniu pozostało niejasne. Zapisz przydatne ustalenia, aktualny status w Git oraz pozostałe zadania przed wyczyszczeniem rozmowy.

Przewodnik po najlepszych praktykach firmy Anthropic zaleca rozpoczęcie od nowa po dwóch nieudanych próbach poprawienia tego samego problemu. Użyj polecenia /clear, a następnie podaj poprawioną podpowiedź uwzględniającą zdobyte informacje. Wyczyścicie rozmowy nie cofa zmian w plikach.

Naciśnij klawisz Esc, aby przerwać wykonywanie odpowiedzi. Gdy podpowiedź jest pusta, naciśnij dwukrotnie klawisz Esc, aby otworzyć menu cofania i wybrać, co chcesz przywrócić. Cofanie nie cofa wszystkich efektów zewnętrznych, dlatego w przypadku zmian w bazach danych lub usługach zdalnych należy korzystać z punktów kontrolnych Git oraz oddzielnych procedur przywracania.

Zapisz wytyczne dotyczące całego projektu w pliku CLAUDE.md, powtarzalne procedury w sekcji „skills” oraz instrukcje dotyczące konkretnych plików w regułach o zasięgu ścieżki. Wykorzystaj haki do działań powiązanych z konkretnymi wydarzeniami, takimi jak uruchomienie formatownika po edycji.

Wybierz w zależności od tego, kiedy instrukcja ma mieć zastosowanie:

Wymagania dotyczące danej funkcji zazwyczaj powinny znajdować się w opisie zadania lub specyfikacji, a nie w pliku CLAUDE.md. Dodawanie tymczasowych instrukcji do pliku obejmującego cały projekt utrudnia odróżnienie ich od konwencji, które powinny obowiązywać w całym repozytorium.

Na przykład: umieść komendę testową projektu w pliku CLAUDE.md, umieść konwencje dotyczące poszczególnych komponentów w regule o zasięgu ścieżki oraz zapisz powtarzającą się procedurę przeglądu jako umiejętność. Przeglądaj te pliki w przypadku zmian komend lub konwencji, tak samo jak w przypadku pozostałej dokumentacji projektu.

Podpowiedzi, plik CLAUDE.md oraz przewodnik po umiejętnościach kierują zachowaniem Claude’a; nie gwarantują one jednak, że instrukcja zostanie wykonana. Haki mogą przeprowadzać kontrole przy określonych wydarzeniach, ale ich niezawodność zależy od typu haka i sposobu jego implementacji.

Hook komend uruchamia skrypt. Hook podpowiedzi lub agenta opiera się na ocenie modelu. Jak wyjaśnia przewodnik najlepszych praktyk firmy Anthropic: „Hook podpowiedzi lub agenta prosi inny model o podjęcie decyzji, więc również nie jest deterministyczny”. W przypadku reguły, która musi być egzekwowana, należy zastosować odpowiednie mechanizmy kontroli uprawnień i przetestować odpowiedni hook komend lub HTTP, w tym sposób, w jaki radzi sobie on z błędami.

Niestandardowe podagenty to kolejny sposób na organizację powtarzających się zadań. Zdefiniuj specjalistę w katalogu `claude/agents/`, gdy potrzebna jest odrębna rola recenzenta lub zakres narzędzi, zamiast dodawać każdą instrukcję dla specjalisty do głównej sesji. Dodatkowe informacje znajdziesz w tych przewodnikach dotyczących najlepszego modelu Claude do pracy oraz rodzajów agentów AI.

Jeśli Twój zespół zarządza podpowiedziami w ramach kilku produktów opartych na sztucznej inteligencji, zapoznaj się z tymi narzędziami do inżynierii podpowiedzi, które umożliwiają zarządzanie bibliotekami wykraczającymi poza Claude Code.

Gdy sesja daje niekompletny lub nieodpowiedni wynik, sprawdź, czy w żądaniu pozostawiono ważne decyzje nierozstrzygnięte. Te pięć błędów może utrudnić diagnozowanie i przeglądanie kodu.

Polecenie „Zbadaj repozytorium” nie daje Claude’owi zbyt wielu wskazówek dotyczących tego, które pliki są istotne ani kiedy należy zakończyć analizę. Możesz otrzymać ogólne podsumowanie bez odpowiedzi na problem, który stał się przyczyną wysłania zapytania.

Określ zachowanie lub decyzję, którą musisz zrozumieć, wskaż lokalizację początkową i zdefiniuj oczekiwany wynik. Na przykład: „Prześledź, w jaki sposób ten punkt końcowy sprawdza uprawnienia, i wskaż odpowiednie funkcje”. Jeśli korzystasz z podagentów, zadaj każdemu z nich konkretne pytanie, zamiast zlecać im to samo nieograniczone wyszukiwanie.

Przełączanie się między funkcją, niepowiązanym błędem a prośbą o uzupełnienie dokumentacji powoduje, że w rozmowie pozostaje kontekst, który może nie mieć zastosowania do bieżącego zadania. Odniesienia takie jak „ten plik” lub „poprzednie podejście” stają się niejednoznaczne.

Do niepowiązanych zadań używaj oddzielnych sesji. Jeśli wiele sesji będzie edytować repozytorium, używaj oddzielnych drzew roboczych Git, aby nie modyfikowały tego samego katalogu roboczego. Krótka uwaga na marginesie: komenda /btw w Claude Code pozwala zachować wymianę wiadomości poza główną historią rozmowy.

Kompilacja może zakończyć się powodzeniem, mimo że dana funkcja działa nieprawidłowo. Zestaw testów może zakończyć się powodzeniem, ponieważ nigdy nie przetestowano w nim nieprawidłowych danych wejściowych. Poproszenie Claude’a o „uruchomienie testów” nie pozwala ustalić, które wymagania te testy weryfikują.

Przyporządkuj kryteria akceptacji do konkretnych testów. W przypadku naprawy błędu poproś o dowód, że test odtworzenia zakończył się niepowodzeniem przed wprowadzeniem zmiany, a po jej wprowadzeniu zakończył się powodzeniem. Nie traktuj jednej pomyślnie wykonanej komendy jako weryfikacji całej zmiany, lecz zapewnij widoczność kryteriów, które nie zostały jeszcze przetestowane.

Rozbudowujący się plik CLAUDE.md może zawierać nieaktualne komendy, zduplikowane reguły oraz instrukcje sprzeczne z wymaganiami konkretnych zadań. Dodanie bardziej stanowczych sformułowań nie rozwiązuje tych konfliktów.

Porównaj plik z aktualnym repozytorium. Usuń nieaktualne wytyczne, wyjaśnij sprzeczne reguły i przenieś instrukcje o wąskim zakresie zastosowania do reguł lub umiejętności o zasięgu ścieżki. Jeśli wymaganie wymaga egzekwowania, skonfiguruj i przetestuj odpowiednie mechanizmy kontroli zamiast polegać na powtarzających się przypomnieniach.

W wyniku przeglądu mogą zostać wykryte zarówno rzeczywiste błędy, jak i niejasne wątpliwości oraz opcjonalne sugestie dotyczące refaktoryzacji. Zastosowanie każdej sugestii może spowodować rozszerzenie zakresu zmian bez poprawy pożądanego zachowania.

Zapytaj o dowody i skutki każdego ustalenia. Nadaj priorytet problemom związanym z poprawnością i niespełnionymi wymaganiami, zbadaj niepewne twierdzenia i nie uwzględniaj w bieżącej analizie różnic niezwiązanych z tematem ulepszeń. Recenzent powinien być w stanie zgłosić brak ustaleń wymagających podjęcia działań, jeśli dowody zapewniają wsparcie dla takiego wniosku.