Masz Claude Code, zainstalowałeś, odpalasz - i piszesz "popraw to". Albo "dodaj walidację". Albo "zrefaktoruj". I wynik jest… taki sobie.
W tym filmie pokażę Ci 10 konkretnych promptów, których używam codziennie w projektach .NET. Do skopiowania. Zapisz ten artykuł - za chwilę będziesz miał bibliotekę, do której będziesz wracał.
Jedna rzecz na start - te prompty zakładają, że masz w projekcie dobrze napisany CLAUDE.md z konwencjami i stackiem. Bez tego zadziałają gorzej. Jeśli go nie masz - wróć najpierw do mojego poprzedniego artykułu w którym rozwijam ten temat i zacznij od CLAUDE.md.
OK, zaczynamy.
PROMPT 1 - Nowa funkcjonalność w konwencji projektu
Pierwszy, i najczęstszy. Dodajesz nowy command w architekturze CQRS.
Dodaj feature [nazwa] w folderze /Features/[Moduł] zgodnie z konwencją pozostałych. Stwórz Command, Handler, Validator, endpoint w kontrolerze i test jednostkowy. Popatrz na @FeatureReferencyjna jako wzór struktury. Uruchom testy na końcu.
Klucz: referencja do istniejącej funkcjonalności przez znak @. Claude kopiuje styl zamiast zmyślać własny.
PROMPT 2 - Testy jednostkowe dla istniejącej klasy
Klasa bez testów, chcesz ją pokryć przed refaktorem.
Napisz testy jednostkowe dla @ŚcieżkaDoKlasy.cs w stylu testów z /Tests. Pokryj scenariusz pozytywny, konkretne przypadki brzegowe i wyjątki. xUnit plus AwesomeAssertions plus Moq. Nazwy w konwencji Should_cośTam_When_warunek. Uruchom dotnet test.
Ważne: wymień konkretne przypadki brzegowe. Bez tego Claude napisze tylko scenariusz pozytywny i się cieszy.
PROMPT 3 - Analiza przyczyny zamiast plastra
Masz stack trace, coś się sypie, chcesz zrozumieć - nie tylko załatać.
Mam błąd: [stack trace]. Kontekst: gdzie, co zmieniłem ostatnio, czy mogę powtórzyć. NIE ZMIENIAJ KODU. Przeanalizuj co dokładnie jest przyczyną, jakie scenariusze to wywołują i jak to potwierdzić. Potem zaproponuj plan naprawy do zatwierdzenia.
Kluczowe: "nie zmieniaj kodu". Claude ma naturalną skłonność do natychmiastowego naprawiania - co przy debugowaniu często znaczy naprawę objawu, nie przyczyny.
PROMPT 4 - Code review własnego diffa
Skończyłeś funkcjonalność, za chwilę idzie PR.
Zrób code review bieżących zmian (git diff HEAD vs main). Szukaj: potencjalnych bugów, problemów wydajnościowych, brakujących testów, niezgodności z konwencjami, rzeczy, które spowodują komentarze w review. Dla każdego: plik, linia, problem, propozycja. Nie poprawiaj - zgłoś.
U mnie łapie średnio 2-3 rzeczy na większy PR. Kolega z review potem ma mniej do zgłoszenia.
PROMPT 5 - Walidacja FluentValidation
Dodaj walidator FluentValidation dla @CommandFile.cs w /Validators zgodnie z konwencją. Reguły: [lista konkretnych reguł biznesowych]. Niestandardowe walidacje - sprawdzenia w bazie, wywołania zewnętrzne - ZAPROPONUJ, ale nie implementuj jeszcze. Dopisz testy walidatora.
Zastrzeżenie o niestandardowych walidacjach jest krytyczne. Bez niego Claude potrafi sam się wstrzyknąć do DI w dziwne miejsca.
PROMPT 6 - Refactor z nienaruszalnym API
Długa metoda, narusza SRP. Chcesz ją rozbić, ale bez psucia 20 miejsc, które ją wołają.
Mała uwaga zanim pokażę prompt - używam tu Plan Mode, czyli wbudowanego trybu Claude Code, w którym najpierw dostajesz plan zmian do zatwierdzenia, a dopiero potem kod. Jeśli go nie znasz - włączasz przez Shift+Tab dwa razy (albo komendą /plan, jeśli jesteś na Windowsie i skrót nie działa).
Zrefaktoruj @Plik.cs. Konkretnie metoda [X] robi za dużo - rozbij na mniejsze. ZASADY: publiczne API klasy ma zostać niezmienione. Zachowaj lub uzupełnij testy. Nie dopisuj nowej funkcjonalności. Plan Mode przed zmianami.
"Zostaw publiczne API" to największe zabezpieczenie jakie istnieje. Bez niego Claude potrafi "poprawić" sygnaturę metody wywołanej w całym projekcie.
PROMPT 7 - Migracja EF Core
Zrobiłem zmiany w @Entity.cs. Uruchom dotnet ef migrations add NazwaMigracji. Pokaż wygenerowaną migrację do review. Sprawdź: DropColumn na danych produkcyjnych, nullability, indexy na nowych FK. Jeśli coś nie tak - zaproponuj ręczne dopracowanie Up i Down. NIE uruchamiaj database update.
Konkretny przykład - ostatnio złapał mi DropColumn na tabeli, którego ja przeoczyłem przy review zmian w encji. Autogenerowane migracje EF Core mają takie pułapki, a Claude łapie je szybciej niż ludzkie oko. Zakaz database update jest kluczowy - chcesz najpierw zobaczyć migrację, nie wykonać ją na bazie.
PROMPT 8 - Audyt rejestracji w DI
Klasyczny .NET-owy strzał w stopę: AddSingleton tam, gdzie powinno być Scoped. DbContext jako Singleton. HttpClient stworzony w pętli. Bug, który ujawnia się dopiero pod obciążeniem.
Przeanalizuj rejestracje serwisów w @Program.cs i @*ServiceCollectionExtensions.cs. Sprawdź: Singleton trzymające stan zależny od request, Scoped wstrzykiwane do Singleton, DbContext lub UnitOfWork zarejestrowane źle, HttpClient bez IHttpClientFactory, brakujące Dispose. Nie poprawiaj. Zgłoś listę: rejestracja, problem, ryzyko, propozycja.
To jeden z tych promptów, których nie używasz codziennie - ale raz na kwartał warto go puścić na całym projekcie. Często coś znajdzie.
PROMPT 9 - Przegląd wydajności
Funkcjonalność działa, chcesz ją przejrzeć pod kątem wydajności zanim pójdzie do scalenia.
Przeanalizuj @Plik.cs pod kątem: N+1 w EF Core, brakujących AsNoTracking, brakujących ConfigureAwait(false), niepotrzebnych ToList(), alokacji w często wykonywanym kodzie, sync-over-async, brakujących CancellationToken. Nie poprawiaj. Zgłoś jako listę: plik, linia, problem, zmiana, szacunek wpływu.
To jest najmocniejszy prompt z całej dziesiątki. Lista konkretnych problemów wymusza konkretny output - bez niej dostajesz ogólniki typu "tu można by zoptymalizować". Z nią dostajesz listę z numerami linii i propozycjami zmiany.
U mnie regularnie łapie N+1, których nie widać w testach jednostkowych, bo mockujesz repo.
PROMPT 10 - Aktualizacja README i CHANGELOG
Skończyłeś funkcjonalność, trzeba zaktualizować dokumentację. Najczęściej odkładana rzecz.
Zaktualizuj README.md i CHANGELOG.md o zmiany z ostatniego commita/brancha. CHANGELOG: wpis [Unreleased] w Keep a Changelog, jedno-dwa zdania PISANE DO UŻYTKOWNIKA, nie programisty. README: tylko sekcje, których realnie dotyczy zmiana. Jeśli trzeba ruszyć /docs - zgłoś, nie edytuj.
Zwróć uwagę - nie podaję Claude listy zmian. Sam czyta git log. To ogólniejsza lekcja: nie podawaj mu informacji, które może wyciągnąć narzędziami sam. Twoja rola to nadać styl i zakres, nie streszczać.
Co je łączy
Cała dziesiątka opiera się na tej samej zasadzie - i ta zasada jest ważniejsza niż konkretne prompty.
Każdy z nich ma pięć elementów:
1. Konkretny cel - nie "popraw", tylko "popraw co, w czym"
2. Ograniczenia - co można, czego nie można
3. Wzór do naśladowania - istniejący plik przez @
4. Kryterium sukcesu - testy, format outputu
5. Granica swobody - co zrobić samemu, co zgłosić do zatwierdzenia
To nie są magiczne zaklęcia. To są instrukcje dla kompetentnego programisty - tak samo jak byś pisał dla juniora. Im jaśniejsza instrukcja, tym mniej iteracji.
Jedna rzecz, której nie ukrywam - te prompty nie zawsze trafią perfekcyjnie za pierwszym razem. To są dobre punkty startu. Druga iteracja domyka resztę. Jeśli ktoś Ci mówi, że u niego AI trafia za pierwszym razem zawsze - kłamie albo robi rzeczy proste.
Najważniejsze
I teraz najważniejsza rzecz.
To 10 promptów. U mnie pokrywają jakieś 80% codziennej roboty z Claude Code. Ale pod nimi jest druga warstwa - i tej już w tym filmie nie zmieszczę.
Jak rozbić duży refaktor w stylu DDD na sekwencję promptów, które ze sobą współpracują. Jak wygląda mój CLAUDE.md dla projektu z CQRS i architekturą hexagonalną. Jak projektować prompty dla testów integracyjnych z WebApplicationFactory.
Tego uczę w Szkole 3x Dev - jak budować aplikacje szybciej dzięki AI. Konkretne wzorce na realnych projektach .NET, gotowe szablony, studium przypadków.
