Prompty dla programistów

Napisz plik README.md dla mojego projektu.
Co robi projekt i dla kogo jest: [OPIS PROJEKTU].
Technologie i wymagania (wersje, rozszerzenia, usługi): [WYMAGANIA].
Jak się go instaluje i uruchamia (moje notatki, mogą być chaotyczne): [INSTALACJA].
Najważniejsze ustawienia lub zmienne środowiskowe: [KONFIGURACJA].

Struktura README:
1. nazwa i jedno zdanie, co to jest,
2. główne funkcje (3–6 punktów),
3. wymagania,
4. instalacja krok po kroku – każdy krok z poleceniem w bloku kodu,
5. konfiguracja (tabela: zmienna – opis – przykład),
6. przykład użycia,
7. najczęstsze problemy i rozwiązania,
8. struktura katalogów (krótko).
Pisz po polsku, konkretnie. Nie dopisuj funkcji, których nie podałem. Klucze i hasła pokazuj jako TWOJ_KLUCZ, nigdy prawdziwe.

Zaprojektuj schemat bazy danych dla aplikacji.
Opis aplikacji i najważniejszych funkcji: [OPIS APLIKACJI].
Kto korzysta (role, uprawnienia): [UŻYTKOWNICY].
Baza danych: [BAZA DANYCH].
Przewidywana skala (rekordy, użytkownicy): [SKALA].

Przygotuj:
1. listę tabel z krótkim opisem,
2. dla każdej tabeli: kolumny, typy, NULL/NOT NULL, klucze główne i obce,
3. relacje (jeden do wielu, wiele do wielu – z tabelą łączącą),
4. indeksy pod najczęstsze zapytania, z uzasadnieniem,
5. pełny skrypt CREATE TABLE,
6. 3 decyzje projektowe, które warto przemyśleć (np. usuwanie miękkie, historia zmian, waluty).
Wskaż, czego nie wiesz z mojego opisu i jakie założenie przyjąłeś.

Na podstawie poniższego opisu przygotuj specyfikację API.
Cel integracji: [CEL]
Systemy uczestniczące: [SYSTEMY]
Uwierzytelnianie: [SPOSÓB AUTH]
Opis funkcji lub istniejący kod: [MATERIAŁ].

Dla każdego endpointu opisz: metodę HTTP, ścieżkę, cel, wymagane uprawnienia, parametry ścieżki i zapytania, schemat body, przykładowe żądanie, przykładową odpowiedź, możliwe kody błędów, walidację, limity i skutki uboczne. Dodaj uwagi dotyczące idempotencji, paginacji i wersjonowania, jeśli mają zastosowanie.

Nie wymyślaj endpointów ani zachowania, którego nie ma w materiale. Braki oznacz jako pytania do zespołu. Przykłady muszą używać fikcyjnych danych i nie mogą zawierać prawdziwych sekretów.

Pomóż zdiagnozować błąd w aplikacji.
Technologia i wersje: [STACK / WERSJE]
Oczekiwane zachowanie: [OCZEKIWANE]
Rzeczywiste zachowanie: [RZECZYWISTE]
Kroki odtworzenia: [KROKI]
Komunikat błędu i istotny kod: [LOGI / KOD]
Co już sprawdziłem: [DOTYCHCZASOWE PRÓBY].

Najpierw wskaż najbardziej prawdopodobne przyczyny i poziom pewności. Następnie zaproponuj najmniejszy test, który odróżni te przyczyny. Nie podawaj dużej przebudowy jako pierwszego rozwiązania. Jeśli brakuje danych, zadaj maksymalnie 3 konkretne pytania. Po ustaleniu przyczyny zaproponuj poprawkę i test regresji. Nie twierdź, że uruchomiłeś kod, jeśli go faktycznie nie uruchomiłeś.

Pomóż przygotować plan kopii zapasowych i odtwarzania dla systemu.
Systemy i dane: [SYSTEMY / DANE]
Środowisko: [SERWER / CHMURA / CMS]
Dopuszczalna utrata danych: [RPO]
Docelowy czas przywrócenia: [RTO]
Ograniczenia kosztowe i prawne: [OGRANICZENIA].

Zaproponuj częstotliwość kopii, typy backupów, retencję, szyfrowanie, odseparowanie kopii od środowiska produkcyjnego, monitoring i procedurę odtworzenia. Dla każdego elementu podaj ryzyko, odpowiedzialną rolę i sposób testowania. Uwzględnij scenariusz przypadkowego usunięcia, awarii sprzętu, przejęcia konta i zaszyfrowania danych.

Nie zakładaj, że backup działa, dopóki odtworzenie nie zostanie przetestowane. Oznacz decyzje zależne od infrastruktury, regulacji i budżetu.

Przejrzyj poniższy kod PHP z [WTYCZKA LUB MOTYW WORDPRESS] pod kątem bezpieczeństwa.

Sprawdź: escapowanie wyjścia, sanitizację wejścia, nonce, uprawnienia (current_user_can), zapytania SQL ($wpdb->prepare), przesyłanie plików i przekierowania.

Dla każdego problemu podaj:
- linię,
- ryzyko (wysokie/średnie/niskie) i jak można je wykorzystać,
- poprawiony fragment.

Na końcu wypisz rzeczy, które są zrobione dobrze.

[WKLEJ KOD]

Dostaję taki błąd:
[WKLEJ BŁĄD]

Środowisko: [ŚRODOWISKO].
Co robiłem, gdy się pojawił: [CO ROBIŁEŚ].

Wyjaśnij:
1. co ten błąd oznacza prostymi słowami,
2. 3 najbardziej prawdopodobne przyczyny, od najczęstszej,
3. co sprawdzić po kolei, żeby znaleźć tę właściwą,
4. jak to naprawić dla każdej przyczyny.

Napisz wyrażenie regularne dla [JĘZYK LUB NARZĘDZIE].
Ma dopasować: [CO MA PASOWAĆ].
Nie może dopasować: [CZEGO NIE MA DOPASOWAĆ].

Podaj:
- wyrażenie,
- wyjaśnienie każdej części w tabeli,
- 5 przykładów, które pasują, i 5, które nie pasują,
- jedno miejsce, w którym wyrażenie może zawieść.

Potrzebuję fragmentu kodu do WordPressa, który: [CO MA ROBIĆ].
Wersja WordPressa: [WERSJA WORDPRESSA]. Motyw: [MOTYW].

Wymagania:
- użyj hooków WordPressa zamiast modyfikować pliki rdzenia,
- unikalny prefiks funkcji, żeby nie było konfliktu nazw,
- escapowanie i sprawdzanie uprawnień tam, gdzie trzeba,
- komentarz po polsku, co robi kod.

Napisz, czy lepiej wkleić to do functions.php motywu potomnego, czy jako małą wtyczkę, i dlaczego.