Twój projektant właśnie przekazał ci plik Figma z 30 ekranami, tech lead chce TypeScript wszędzie, a deadline jest w przyszły piątek. Te przepisy zamieniają tę presję w dostarczone funkcje. Każdy z nich to gotowy prompt, który generuje produkcyjnej jakości kod React — nie komponent z tutoriala, który się rozpadnie gdy dodasz prawdziwe dane.
Prompty do generowania typowanych komponentów React z projektów lub wymagań
Przepisy zarządzania stanem dla Zustand, React Query i wzorców kontekstu
Prompty optymalizacji wydajności, które znajdują i naprawiają prawdziwe wąskie gardła
Przepisy testowania generujące sensowne pokrycie, nie testy-zaznaczenie-checkboxa
Scenariusz: Masz projekt Figma karty cenowej i potrzebujesz pixel-perfekcyjnego komponentu React z propsami TypeScript i stylowaniem Tailwind.
Włącz serwer Figma MCP w swojej aplikacji desktopowej Figma (Preferences > Enable Dev Mode MCP Server), następnie dodaj go w Cursor Settings > MCP. Zaznacz komponent w Figma, potem otwórz tryb Agent.
Dodaj Figma MCP: claude mcp add figma --transport sse http://127.0.0.1:3845/sse. Następnie odwołaj się do zaznaczenia w swoim prompcie.
Skonfiguruj Figma MCP w swoim codex.json, następnie odwołaj się do zaznaczenia Figma w dowolnym interfejsie Codex.
Używając serwera Figma MCP, wygeneruj komponent React z mojego bieżącego zaznaczenia Figma. Wymagania: TypeScript z jawnym interfejsem propsów, Tailwind CSS do całego stylowania, responsywne breakpointy sm/md/lg, named export i plik Storybook story obok komponentu. Wyodrębnij tokeny projektowe (kolory, odstępy, zaokrąglenia) ze zmiennych Figma i zmapuj je na klasy Tailwind.
Oczekiwane wyjście: Plik komponentu .tsx z typowanym interfejsem propsów, klasami Tailwind odpowiadającymi projektowi, wariantami responsywnymi i towarzyszącym plikiem .stories.tsx z co najmniej trzema wariantami (default, loading, error).
Scenariusz: Potrzebujesz wielokrotnego użytku komponentu tabeli danych do panelu administracyjnego, który obsługuje 10 000+ wierszy bez zacinania.
Utwórz generyczny komponent DataTable używając @tanstack/react-table v8. Wymagania: generyki TypeScript, aby komponent przyjmował dowolny typ wiersza przez prop data i tablicę columns ColumnDef. Dołącz sortowanie kliknięciem na nagłówkach kolumn z cyklem asc/desc/none, filtr tekstowy na kolumnę, paginację z konfigurowalnymi rozmiarami strony (10, 25, 50, 100), stan szkieletu ładowania, stan pusty z konfigurowalnym komunikatem, zaznaczanie wierszy z kolumną checkbox i callbackiem onSelectionChange. Styluj Tailwindem. Dodaj nawigację klawiaturową dla dostępności. Napisz komponent, plik typów i przykład użycia z przykładowymi danymi użytkowników.
Oczekiwane wyjście: Trzy pliki — DataTable.tsx z generycznym komponentem, data-table.types.ts ze współdzielonymi typami i DataTableExample.tsx demonstrujący użycie z typem User.
Scenariusz: Odziedziczyłeś 400-liniowy komponent klasowy z componentDidMount, componentDidUpdate i shouldComponentUpdate. Musi stać się komponentem funkcyjnym bez zmiany zachowania.
Zrefaktoryzuj komponent klasowy w src/components/UserDashboard.tsx na komponent funkcyjny z hookami. Zmapuj każdą metodę lifecycle: componentDidMount staje się useEffect z pustymi zależnościami, componentDidUpdate staje się useEffect z konkretnymi zależnościami, shouldComponentUpdate staje się React.memo z niestandardową funkcją porównania. Wyodrębnij złożoną logikę stanu do niestandardowego hooka useUserDashboard w osobnym pliku. Zachowaj całkowicie istniejące zachowanie — nie zmieniaj propsów, nie zmieniaj renderowanego wyjścia, nie zmieniaj wywołań API. Uruchom istniejące testy po refaktoryzacji aby potwierdzić, że nic nie zostało zepsute.
Oczekiwane wyjście: Funkcyjny komponent UserDashboard, niestandardowy hook useUserDashboard.ts i wszystkie istniejące testy nadal przechodzące.
Scenariusz: Potrzebujesz globalnego stanu klienta dla preferencji użytkownika, motywu i stanu zwiniętego paska bocznego. Powinien przetrwać odświeżenie strony.
Utwórz store Zustand w src/stores/app-store.ts z pełnym typowaniem TypeScript. Dołącz te slice’y: user (dane profilu, boolean isAuthenticated, akcje login/logout), preferences (theme jako ‘light’ | ‘dark’ | ‘system’, boolean sidebarCollapsed, string locale, akcje toggle dla każdego), notifications (tablica items, selektor pochodny unreadCount, akcje addNotification/markRead/clearAll). Użyj middleware persist do zapisywania w localStorage z numerem wersji dla migracji. Użyj middleware devtools w trybie development. Eksportuj typowane selektory jak useUser(), usePreferences(), useNotifications() aby konsumenci nie mieli dostępu do surowego store’a. Napisz testy jednostkowe dla każdej akcji.
Oczekiwane wyjście: Plik store’a, plik selectors.ts z typowanymi hookami i plik __tests__/app-store.test.ts testujący wszystkie akcje i persystencję.
Scenariusz: Twoja aplikacja wykonuje 15 różnych wywołań API i zarządzasz stanami loading/error wszędzie za pomocą useState. Czas scentralizować z React Query.
Skonfiguruj TanStack Query v5 w tej aplikacji React. Utwórz src/lib/query-client.ts konfigurujący QueryClient z tymi domyślnymi: staleTime 5 minut, gcTime 30 minut, retry 2 razy z wykładniczym backoff, refetchOnWindowFocus tylko w produkcji. Następnie utwórz niestandardowe hooki w src/hooks/api/: useUsers() do listowania z parametrami paginacji, useUser(id) do pobrania pojedynczego, mutacja useCreateUser() z optymistyczną aktualizacją natychmiast dodającą nowego użytkownika do cache’u listy, mutacja useUpdateUser() aktualizująca użytkownika zarówno w cache’u listy jak i szczegółów, mutacja useDeleteUser() z optymistycznym usunięciem. Każdy hook powinien obsługiwać stany błędów z typowanymi odpowiedziami błędów. Dołącz komponent wrappera QueryProvider. Napisz testy używając @testing-library/react z niestandardowym narzędziem renderWithProviders.
Oczekiwane wyjście: Konfiguracja query client, 5 niestandardowych hooków, wrapper providera, narzędzie testowe i co najmniej jeden test na hook.
Scenariusz: Twoja aplikacja React potrzebuje 4 sekund na wyrenderowanie strony z listą produktów. React DevTools Profiler pokazuje 200+ niepotrzebnych re-renderów.
Otwórz katalog komponentów, zaznacz wszystkie pliki, następnie użyj trybu Agent z poniższym promptem.
Claude Code może czytać całe katalogi. Po prostu wskaż mu folder komponentów.
Codex może analizować całe repozytorium. Użyj poniższego promptu w dowolnym interfejsie.
Przeanalizuj każdy komponent w src/components/products/ pod kątem problemów wydajnościowych. Dla każdego pliku sprawdź: (1) komponenty przyjmujące propsy obiekt/tablica bez React.memo, (2) definicje funkcji inline w JSX powodujące re-rendery dzieci, (3) hooki useEffect z brakującymi lub zbyt szerokimi tablicami zależności, (4) kosztowne obliczenia nieopakowane w useMemo, (5) handlery zdarzeń odtwarzane przy każdym renderze, które powinny używać useCallback. Dla każdego znalezionego problemu zastosuj poprawkę bezpośrednio. Nie opakowuj wszystkiego w memo na ślepo — tylko tam, gdzie dane profilera to uzasadniają. Po poprawkach dodaj komentarz na górze każdego zmodyfikowanego pliku z informacją co zostało zoptymalizowane i dlaczego.
Oczekiwane wyjście: Zmodyfikowane pliki komponentów z celowanymi optymalizacjami, każdy udokumentowany komentarzem wyjaśniającym uzasadnienie wydajnościowe.
Scenariusz: Masz komponent CheckoutForm z walidacją, wywołaniami API i warunkowym renderowaniem. Ma zero testów.
Napisz testy dla src/components/CheckoutForm.tsx używając Vitest i @testing-library/react. Obejmij te scenariusze: (1) renderuje wszystkie pola formularza z poprawnymi etykietami i placeholderami, (2) pokazuje błędy walidacji przy przesyłaniu pustych wymaganych pól, (3) pokazuje walidację inline przy blur dla formatu email, długości numeru karty i daty wygaśnięcia w przeszłości, (4) dezaktywuje przycisk submit podczas przesyłania formularza, (5) wywołuje prop onSubmit z oczyszczonymi danymi formularza przy prawidłowym przesłaniu, (6) wyświetla komunikat błędu API gdy przesłanie kończy się odpowiedzią 422, (7) wyświetla stan sukcesu i wywołuje callback onSuccess po udanym przesłaniu, (8) gracefully obsługuje timeout sieci z opcją ponowienia. Mockuj klienta API, nie fetch bezpośrednio. Użyj userEvent do wszystkich interakcji. Testuj dostępność: każde pole wejściowe ma powiązaną etykietę, komunikaty błędów używają regionów aria-live.
Oczekiwane wyjście: Plik CheckoutForm.test.tsx z 8+ przypadkami testowymi, prawidłową konfiguracją mocków i asercjami dostępności.
Scenariusz: Twój zespół ciągle reimplementuje te same wzorce — debouncing, synchronizacja z local storage, media queries, intersection observer. Potrzebujecie współdzielonej biblioteki hooków.
Utwórz bibliotekę niestandardowych hooków w src/hooks/ z tymi hookami, każdy w swoim pliku z generykami TypeScript tam gdzie to zasadne i towarzyszącym plikiem testowym:
useDebounce<T>(value: T, delay: number) — zwraca zdebouncowaną wartość, anuluje przy odmontowaniuuseLocalStorage<T>(key: string, initialValue: T) — synchronizuje stan z localStorage, gracefully obsługuje SSR, nasłuchuje zdarzeń storage z innych kartuseMediaQuery(query: string) — zwraca boolean dopasowania, używa matchMedia API, obsługuje SSR z fallbackiemuseIntersectionObserver(options?) — zwraca ref i IntersectionObserverEntry, leniwie inicjalizuje obserwatoruseClickOutside<T extends HTMLElement>(handler: () => void) — zwraca ref do podpięcia do elementu, czyści listener przy odmontowaniuusePrevious<T>(value: T) — zwraca wartość z poprzedniego renderowaniauseAsync<T>(asyncFn: () => Promise<T>) — zwraca { data, error, loading, execute }, z obsługą abort Eksportuj wszystkie hooki z src/hooks/index.ts. Każdy plik testowy powinien obejmować ścieżkę sukcesu, przypadki brzegowe i zachowanie czyszczenia.
Oczekiwane wyjście: Siedem plików hooków, siedem plików testowych i eksport barrel index.ts.
Scenariusz: Gdy komponent w twoim dashboardzie pada, cała strona staje się biała. Potrzebujesz granularnych error boundaries pozwalających użytkownikom na ponowienie.
Utwórz system error boundary z trzema komponentami: (1) ErrorBoundary — komponent klasowy (wymagany dla getDerivedStateFromError), który przechwytuje błędy, loguje je do serwisu raportowania błędów przez prop onError i renderuje zapasowy UI z przyciskiem “Spróbuj ponownie”, który resetuje stan boundary. Przyjmij render prop fallback otrzymujący błąd i funkcję resetowania. (2) SectionErrorBoundary — opakowuje ErrorBoundary ze stylizowanym zapasowym card specyficznym dla sekcji dashboardu, pokazującym nazwę sekcji i przyjazny komunikat. (3) HOC withErrorBoundary — opakowuje dowolny komponent w ErrorBoundary z rozsądnymi domyślnymi. Dołącz generyki TypeScript aby HOC zachowywał typy propsów opakowanego komponentu. Dodaj hook useErrorHandler(), który pozwala komponentom potomnym programistycznie wyzwolić najbliższy error boundary dla błędów asynchronicznych, których getDerivedStateFromError nie może przechwycić. Przetestuj, że boundary przechwytuje błędy renderowania, wyświetla zapasowy UI i resetuje się gdy użytkownik kliknie ponowienie.
Oczekiwane wyjście: Trzy pliki komponentów, jeden plik hooka, jeden plik testowy obejmujący przechwytywanie błędów i przywracanie.
Scenariusz: Migrujesz stronę Next.js aby używać React Server Components. Musisz zidentyfikować, które części wymagają "use client", a które mogą pozostać na serwerze.
Przeanalizuj src/app/dashboard/page.tsx i jego komponenty potomne. Dla każdego komponentu określ: czy używa useState, useEffect, handlerów zdarzeń, API przeglądarki lub kontekstu? Jeśli tak, musi być komponentem klienckim. Jeśli tylko renderuje propsy i pobiera dane, zachowaj go jako komponent serwerowy. Zrefaktoryzuj stronę tak aby: układ strony, pobieranie danych i statyczna treść pozostały jako komponenty serwerowe. Interaktywne elementy (filtry, modale, formularze) staną się komponentami klienckimi z “use client” na górze. Utwórz czystą granicę — komponenty serwerowe przekazują serializowalne propsy do komponentów klienckich. Upewnij się, że żaden kod wyłącznie serwerowy (zapytania bazodanowe, zmienne środowiskowe) nie przecieka do komponentów klienckich. Dodaj komentarz na górze każdego pliku: ”// Server Component” lub ”// Client Component — uses [powód]”.
Oczekiwane wyjście: Zrefaktoryzowana strona z czystymi granicami serwer/klient, udokumentowana komentarzami wyjaśniającymi każdą decyzję.
Scenariusz: Twoja aplikacja ma 5 różnych implementacji modali, żadna z nich nie obsługuje poprawnie pułapki fokusu ani nawigacji klawiaturowej.
Utwórz zunifikowany system modali w src/components/ui/Modal/. Dołącz: (1) Komponent Modal, który renderuje do portalu, łapie fokus wewnątrz używając pętli focus-trap, zamyka się na Escape, zamyka się na kliknięcie tła (konfigurowalne), stosuje aria-modal=“true” i role=“dialog”, przywraca fokus do elementu wyzwalającego przy zamknięciu, blokuje przewijanie body gdy jest otwarty. (2) Komponenty złożone ModalHeader, ModalBody, ModalFooter dla spójnego layoutu. (3) Hook useModal() zwracający { isOpen, open, close, toggle } ze stabilną tożsamością callbacków. (4) ConfirmModal — gotowy wariant dla dialogów potwierdzenia/anulowania z konfigurowalnym tytułem, wiadomością i etykietami przycisków. Styluj Tailwindem, animuj przejściami CSS (fade + scale). Testuj nawigację klawiaturową (Tab cykluje przez focusowalne elementy, Shift+Tab idzie wstecz, Escape zamyka), atrybuty czytników ekranu i blokadę przewijania body.
Oczekiwane wyjście: Katalog komponentu Modal ze złożonymi komponentami, hookiem, wariantem potwierdzenia i testami dostępności.
Scenariusz: Twoja lista todo jest ślamazarna, bo każda akcja czeka na odpowiedź serwera przed aktualizacją UI.
Zrefaktoryzuj listę todo w src/features/todos/ aby używać optymistycznych aktualizacji z TanStack Query. Dla każdej mutacji: (1) addTodo — natychmiast dodaj nowe todo do cache’u listy z tymczasowym ID (użyj crypto.randomUUID()), pokaż je w UI z subtelnym wskaźnikiem “synchronizowanie”, zastąp tymczasowe ID serwerowym po sukcesie, cofnij i pokaż toast błędu przy niepowodzeniu. (2) toggleTodo — natychmiast przełącz stan completed w cache’u, cofnij przy niepowodzeniu. (3) deleteTodo — natychmiast usuń z cache’u, przywróć przy niepowodzeniu z toastem “cofnij” utrzymującym się przez 5 sekund. (4) reorderTodos — natychmiast zmień kolejność w cache’u używając nowej pozycji, cofnij przy niepowodzeniu. Użyj callbacków TanStack Query onMutate, onError i onSettled dla logiki optymistycznej. Napisz testy weryfikujące, że stan optymistyczny pojawia się przed rozwiązaniem API.
Oczekiwane wyjście: Zrefaktoryzowane hooki mutacji z logiką optymistycznych aktualizacji, zaktualizowane komponenty UI pokazujące wskaźniki synchronizacji i testy weryfikujące zachowanie optymistyczne.
Scenariusz: Twoja aplikacja ma 12 formularzy i każdy obsługuje walidację inaczej. Potrzebujesz spójnego systemu formularzy.
Zbuduj system formularzy używając React Hook Form v7 i Zod do walidacji. Utwórz: (1) Komponent FormField przyjmujący pole schematu Zod, renderujący odpowiedni typ inputu (text, email, number, select, textarea, checkbox, radio group, date picker), pokazujący błędy walidacji pod polem i obsługujący niestandardowe renderowanie przez render prop. (2) Komponent Form opakowujący FormProvider z React Hook Form, przyjmujący schemat Zod jako prop schema, wnioskujący typy TypeScript ze schematu dla handlera onSubmit i obsługujący błędy walidacji po stronie serwera mapując je na pola. (3) Schematy Zod dla typowych wzorców: loginSchema, registrationSchema, profileSchema, addressSchema. (4) Hook useFormWithSchema<T>(schema) zwracający metody formularza z poprawnie wnioskowanymi typami. Przetestuj, że błędy walidacji wyświetlają się poprawnie, że błędy serwerowe mapują się na pola i że formularz przesyła się tylko gdy jest prawidłowy.
Oczekiwane wyjście: Komponent FormField, wrapper Form, 4 schematy Zod, niestandardowy hook i testy walidacji.
Scenariusz: Twój bundle ma 2.4 MB, a początkowe ładowanie trwa 6 sekund na mobilnym. Większość użytkowników odwiedza tylko 2-3 strony na sesję.
Zaimplementuj code splitting oparty na trasach dla konfiguracji React Router w src/App.tsx. Dla każdej trasy: (1) Zamień statyczny import na React.lazy() z dynamicznym importem. (2) Opakuj każdą leniwą trasę w granicę Suspense ze szkieletem ładowania dopasowanym do layoutu strony (nie generyczny spinner). (3) Utwórz komponent wrappera LazyRoute łączący Suspense z ErrorBoundary, aby awarie ładowania chunków pokazywały komunikat “Nie udało się załadować strony. Odśwież aby spróbować ponownie.” zamiast białego ekranu. (4) Dodaj prefetching trasy: gdy użytkownik najedzie na link nawigacyjny przez 200ms, zacznij ładować chunk tej trasy używając dynamicznego wywołania import(). (5) Utwórz narzędzie prefetchRoute, które może być wywołane programistycznie (np. po logowaniu, prefetchuj trasę dashboardu). Zweryfikuj, że główny bundle spadnie poniżej 200KB i każdy chunk trasy ładuje się niezależnie.
Oczekiwane wyjście: Zaktualizowany router z leniwymi trasami, wrappery Suspense, error boundaries, narzędzie prefetch i komponent LazyRoute.
Scenariusz: Twój build CRA trwa 90 sekund, a hot reload ma 3-sekundowe opóźnienie. Czas przejść na Vite.
Zmigruj ten projekt Create React App do Vite. Kroki: (1) Utwórz vite.config.ts z pluginem React, aliasami resolve odpowiadającymi istniejącym ścieżkom tsconfig i obsługą zmiennych środowiskowych (zamień wszystkie prefiksy REACT_APP_ na VITE_). (2) Przenieś public/index.html do index.html w katalogu głównym i dodaj punkt wejścia skryptu Vite. (3) Zaktualizuj tsconfig.json aby używać typów Vite zamiast typów react-scripts. (4) Zamień react-scripts na vite w skryptach package.json (dev, build, preview). (5) Napraw problemy z importami: CRA wspiera importowanie SVG jako komponentów przez import { ReactComponent } — zamień je na vite-plugin-svgr. (6) Zaktualizuj dostęp do zmiennych środowiskowych z process.env.REACT_APP_* na import.meta.env.VITE_* we wszystkich plikach. (7) Usuń react-scripts, react-app-rewired i wszelkie zależności specyficzne dla CRA. (8) Zweryfikuj, że serwer dev startuje, build produkcyjny się udaje i wszystkie testy nadal przechodzą.
Oczekiwane wyjście: Zaktualizowane pliki konfiguracyjne, zmigrowane zmienne środowiskowe, usunięte zależności CRA i działająca konfiguracja Vite.
