Prompty do kodowania dla Grok

Używam [język lub framework i wersja]. Wyjaśnij ten błąd prostymi słowami, wymień trzy najbardziej prawdopodobne przyczyny według prawdopodobieństwa i powiedz, co sprawdzić najpierw przy każdej z nich: [wklej pełny błąd i stack trace]

Ta funkcja zwraca [faktyczny wynik] po wywołaniu z [dane wejściowe], ale oczekuję [oczekiwany wynik]. Prześledź wykonanie linijka po linijce dla tych danych wejściowych, śledząc każdą zmienną, i zatrzymaj się na pierwszej linijce, w której stan różni się od oczekiwanego: [wklej kod]

Ten kod w [język] czasami daje [objaw] pod obciążeniem, ale nigdy podczas pojedynczych testów: [wklej kod]. Poszukaj wyścigów (race conditions), współdzielonego stanu i założeń co do kolejności wykonywania. Dla każdego podejrzanego miejsca opisz dokładny przeplot operacji powodujący błąd i sposób jego naprawy.

Oceń tego diffa jako wymagający senior developer w projekcie w [język]. Podziel uwagi na błędy, ryzyka, czytelność i testy, podaj numery linii i zakończ werdyktem: approve, approve with changes lub request changes, dodając jednozdaniowe uzasadnienie: [wklej diff]

Dla poniższej funkcji wypisz wszystkie przypadki brzegowe, które warto przetestować, wraz z uzasadnieniem, a następnie napisz testy w [framework testowy]. Dołącz co najmniej jeden test, który według Ciebie nie przejdzie na obecnym kodzie, i wskaż go: [wklej funkcję]

Przygotuj realistyczne fixture'y testowe dla tego modelu danych w [format, np. JSON lub factory function]: [wklej model]. Uwzględnij dziesięć typowych rekordów i pięć nietypowych/wrednych przypadków (np. puste ciągi znaków, bardzo długie nazwiska, znaki spoza alfabetu łacińskiego, daty graniczne) i oznacz, które są które.

Na podstawie tego schematu: [wklej schemat], napisz zapytanie do [baza danych], które zwraca [czego potrzebujesz]. Wyjaśnij zapytanie klauzula po klauzuli, a następnie pokaż wariant, który obsługuje również [przypadek brzegowy, np. klienci bez zamówień].

To wyrażenie regularne powinno [oczekiwane zachowanie] w [język lub narzędzie], ale [co działa źle]: [wklej regex]. Rozbij je na części i wyjaśnij każdą z nich, pokaż ciąg wejściowy ujawniający problem i podaj poprawioną wersję wraz z trzema ciągami, które musi odrzucić.

Napisz skrypt w [bash lub PowerShell], który [zadanie, np. archiwizuje pliki logów starsze niż 30 dni do pliku zip]. Zadbaj o bezpieczeństwo: tryb dry-run wypisujący tylko planowane operacje, czytelne komunikaty o błędach i komentarz przy każdej linijce, która usuwa lub nadpisuje pliki.

Napisz dokumentację techniczną dla tego endpointu: [wklej kod handlera lub trasę]. Uwzględnij metodę i ścieżkę, parametry z typami oraz informacją, czy są wymagane, przykładowe zapytanie, przykładowe odpowiedzi sukcesu i błędu oraz każdy kod statusu, jaki może zwrócić.

Moje repozytorium Git jest w takim stanie: [wklej git status i kilka ostatnich linii z git log]. Mój cel to: [cel]. Wyjaśnij prostymi słowami, co się stało, i podaj dokładne polecenia, aby to naprawić – zaczynając od takiego, które zabezpieczy moją obecną pracę. Ostrzeż mnie przed każdym poleceniem, które nadpisuje historię.

Płynnie posługuję się [znany język] i uczę się [nowy język]. Weź ten fragment napisany w moim zwykłym stylu: [wklej kod] i przepisz go tak, jak zrobiłby to doświadczony programista [nowy język]. Następnie wyjaśnij użyte idiomy, które nie mają bezpośredniego odpowiednika w moim języku wyjściowym.

Załączam zrzut ekranu mojej strony. Problem: [co wygląda źle]. Oto kod HTML i CSS dla tej sekcji: [wklej kod]. Znajdź przyczynę, podaj minimalną poprawkę w CSS i wyjaśnij, dlaczego tak się stało, abym nie powtarzał tego błędu.

Załączam zdjęcie szkicu modelu danych z tablicy dla [aplikacja]. Przekształć go w definicje tabel dla [baza danych] z kluczami głównymi, obcymi i sensownymi typami danych. Wypisz wszelkie relacje, które na szkicu są niejednoznaczne, i dopytaj o nie, zanim przyjmiesz własne założenia.

Jaka jest złożoność czasowa i pamięciowa tej funkcji i dlaczego? [wklej kod] Jeśli istnieje szybsze podejście dla danych wejściowych o rozmiarze około [rozmiar], pokaż je i wyjaśnij, jak wpływa na czytelność kodu.

Zrefaktoryzuj tę funkcję, aby była bardziej czytelna, nie zmieniając jej działania: [wklej kod]. Działaj w małych, nazwanych krokach, wyjaśnij każdą zmianę w jednej linijce i wypisz wszelkie zachowania, co do których masz wątpliwości, abym mógł je potwierdzić przed scaleniem.

Napisz plik README dla mojego projektu [nazwa], który [co robi]. Sekcje: czym jest projekt, szybki start z poleceniami gotowymi do skopiowania, opcje konfiguracji w tabeli, typowe problemy oraz jak wspierać projekt. Oto kluczowe pliki i polecenia: [wklej szczegóły]

Wyjaśnij, co robi ten kod w [język], osobie, która zna programowanie, ale nie ten projekt. Zacznij od dwuzdaniowego podsumowania, omów go blok po bloku i wskaż wszystko, co wygląda na błąd lub prowizoryczny hack: [wklej kod]

Planuję zbudować [funkcjonalność] w ten sposób: [opisz podejście]. Wejdź w rolę adwokata diabła. Wskaż trzy najbardziej prawdopodobne sposoby, na jakie ten projekt zawiedzie na produkcji, jakie będą tego objawy i tańszą alternatywę, jeśli istnieje. Pisz bez ogródek – wolę dowiedzieć się teraz niż o 3 w nocy.

Przekonwertuj ten kod z [język źródłowy] na idiomatyczny [język docelowy], zamiast przepisywać go linijka po linijce: [wklej kod]. Użyj biblioteki standardowej języka docelowego, zachowaj identyczne działanie i wskaż miejsca, w których oba języki zachowują się inaczej (np. dzielenie liczb całkowitych czy kodowanie ciągów znaków).