Kiedy użyć tego promptu
Po skończeniu zadania, zanim wyślesz zmiany do przeglądu. Commit „fix” i pull request bez opisu oznaczają, że osoba sprawdzająca musi sama zgadywać, co i po co zmieniłeś. Dobry opis skraca code review i za kilka miesięcy pozwala zrozumieć, dlaczego kod wygląda tak, a nie inaczej.
Przykład
Przykładowe dane do uzupełnienia:
- KONTEKST ZADANIA: zgłoszenie: formularz kontaktowy nie wysyła maili, gdy temat zawiera polskie znaki
- KONWENCJA: Conventional Commits, opisy po polsku
Czego się spodziewać: Dostaniesz commit w stylu „fix(contact): kodowanie tematu maila w UTF-8” z wyjaśnieniem przyczyny oraz opis PR z krokami testu typu „wyślij formularz z tematem »Zażółć gęślą jaźń« i sprawdź nagłówek Subject w odebranej wiadomości”.
Jak dopasować prompt do siebie
- Duży PR: poproś o podział zmian na logiczne części i propozycję, jak rozbić go na mniejsze.
- Opis dla osoby nietechnicznej (klient, PM): poproś o dodatkowe streszczenie w 3 zdaniach bez żargonu.
- Zmiana w bazie danych: dodaj sekcję o migracji i sposobie wycofania zmian.
Wskazówki
- Wklejaj diff bez sekretów – sprawdź, czy w zmianach nie ma kluczy ani haseł.
- „Dlaczego” jest ważniejsze niż „co” – co się zmieniło, widać w kodzie.
- Kroki testu w PR powinny dać się wykonać bez pytania autora.
Najczęstsze błędy
- Jeden commit z dziesięcioma niezwiązanymi zmianami i opisem „poprawki”.
- Opis PR, który powtarza tytuł zadania, bez kroków sprawdzenia.