Przepisy frontendowe

Przepisy frontendowe to pięć stron gotowych promptów dla Claude Code, Codeksa i Cursora, po jednej dla Angulara, Next.js, Nuxta, Reacta i Vue. Każdy przepis działa najlepiej, gdy agent może otworzyć działającą aplikację w przeglądarce, a repozytorium nazywa swoje bramki: sprawdzenie typów, testy jednostkowe, test w przeglądarce, skan dostępności i zrzut ekranu.

Ta strona jest dla programistów, którzy oddają agentowi kod interfejsu. Znasz ten scenariusz: komponent się kompiluje, test jednostkowy przechodzi, a ekran i tak jest zły. Układ rozjeżdża się przy 375 pikselach, konsola pełna jest ostrzeżeń o hydracji, modal nie przechwytuje fokusu i nikt tego nie widzi, dopóki nie zauważy użytkownik.

Który przepis frontendowy pasuje do twojego frameworka?

Każdy przepis zakłada konfigurację przeglądarki i bramek z dwóch kolejnych sekcji.

Twój framework	Przepis	Co obejmuje przepis
Angular	Przepisy dla Angulara	Sygnały, komponenty standalone, typowane formularze, leniwe trasy, interceptory
Next.js App Router	Przepisy dla Next.js	Server Components, streaming, Server Actions, cache, Core Web Vitals
Nuxt	Przepisy dla Nuxta 4	Trasy serwerowe, composables do pobierania danych, renderowanie hybrydowe, testy
React	Przepisy dla Reacta	Typowane komponenty z projektu, stan serwera, formularze, error boundaries, testy
Vue 3	Przepisy dla Vue.js	Composition API, store’y Pinia, composables, leniwe trasy, i18n

React Native, Flutter i Expo znajdziesz w przepisach mobilnych. Skille, które podnoszą jakość wizualną generowanego UI, porównuje strona najlepsze skille do frontendu.

Daj agentowi przeglądarkę przed pierwszym przepisem

Agent, który nie widzi strony, zgaduje układ. Serwer MCP z przeglądarką pozwala mu załadować serwer deweloperski, przeklikać ścieżkę użytkownika, przeczytać konsolę i zrobić zrzut ekranu. Najczęstszy wybór to Playwright MCP (@playwright/mcp, 0.0.82 na dzień 2026-09-26). Flaga --isolated trzyma profil przeglądarki w pamięci, więc dwóch agentów w dwóch worktree nie walczy o jeden profil.

Uruchom w terminalu w katalogu repozytorium:

claude mcp add playwright -- npx @playwright/mcp@latest --isolated

Dodaj --scope project, żeby zapisać wpis w .mcp.json i udostępnić go zespołowi.

Uruchom w terminalu:

codex mcp add playwright -- npx @playwright/mcp@latest --isolated

codex mcp list potwierdza, że wpis istnieje.

Dodaj serwer do .cursor/mcp.json w projekcie, w formacie, który README Playwrighta opisuje dla Cursora:

{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest", "--isolated"] } } }

Do śladów wydajności i podglądu sieci dodaj w ten sam sposób Chrome DevTools MCP (chrome-devtools-mcp, 1.10.1), na przykład codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest. Domyślnie wysyła statystyki użycia do Google, chyba że dodasz --no-usage-statistics. Strona Playwright MCP kontra Playwright CLI omawia flagi, konfigurację dla równoległych worktree i wariant z CLI, który zużywa mniej kontekstu.

Zapisz bramkę frontendową w instrukcjach agenta

Przepis kończy się poleceniem „uruchom bramkę”, więc repozytorium musi mówić, czym ta bramka jest. Dla aplikacji w TypeScripcie z Vitestem i Playwrightem:

## Commands
- Types: `npx tsc --noEmit`
- Lint: `npm run lint`
- Unit and component tests: `npx vitest run`
- Browser tests, including axe accessibility scans: `npx playwright test`

## Definition of done for UI changes
Types, lint, unit, and browser tests pass, and your reply ends with the last
lines of each. Every new screen or component state gets a Playwright test that
checks it at 375 px and 1280 px wide, runs an axe scan with
@axe-core/playwright, and fails on any console error. Never update a
screenshot baseline or edit an existing test without asking first.

Claude Code czyta CLAUDE.md; od v2.1.277 (kanał latest) czyta też AGENTS.md, gdy projekt nie ma CLAUDE.md, więc na kanale stable trzymaj CLAUDE.md z jedną linią @AGENTS.md. Codex czyta AGENTS.md, gdy oznaczysz projekt jako zaufany. W Cursorze powtórz obie sekcje w regule projektu, która obowiązuje przy każdym zapytaniu. O wyniku decyduje job CI, który uruchamia te same polecenia przy każdym pull requeście.

Jak zweryfikować kod UI bez czytania każdej linii?

Poproś o test, który zaświeci się na czerwono przy każdym błędzie, i wymagaj, żeby agent dołączył jego wynik.

Błąd	Test, który go łapie
Układ rozjeżdża się na małym ekranie	Test Playwrighta dla każdej szerokości ekranu plus porównanie `toHaveScreenshot` z zatwierdzonym wzorcem
Niezgodność hydracji albo błąd w runtime	Test w przeglądarce, który nie przechodzi, gdy strona zaloguje błąd w konsoli
Brak etykiet, kontrast, kolejność fokusu	Skan axe w teście przeglądarkowym plus test całej ścieżki wyłącznie z klawiatury; zobacz testy dostępności
Komponent w niczym nie przypomina projektu	Uzgodniony mock lub zrzut ekranu jako cel akceptacji; zobacz akceptację wizualną przed implementacją frontendu
Regresja rozmiaru bundla lub wydajności	Budżet rozmiaru bundla albo przebieg Lighthouse w CI, który nie przechodzi powyżej progu

Człowiek zatwierdza dwa razy: cel wizualny, zanim agent zacznie, oraz zrzuty ekranu i każdy zmieniony wzorzec, gdy skończy. Oba zatwierdzenia trafiają do pakietu dowodów pull requesta.

Prompty działają bez zmian w Claude Code, Codeksie i Cursorze, gdy serwer Playwright MCP jest podłączony.

Build the account settings form described in the acceptance criteria above,
following the existing components in src/components/.
Work test-first:
1. Write failing Playwright tests: the form at 375 px and 1280 px wide,
   validation messages for each invalid field, submit with the keyboard
   only, and an axe scan with @axe-core/playwright that allows no violations.
2. Make every test fail on any console error.
3. Implement until the Definition of done in AGENTS.md passes.
4. Open the page with the Playwright MCP tools, take a screenshot at each
   width, and attach them with the last lines of every gate command.
Do not update screenshot baselines or edit a test to make it pass.

Start the dev server and open /checkout with the Playwright MCP tools.
Check the page at 375 px, 768 px and 1280 px wide. Report every console error,
every element that overflows the viewport, every interactive element you cannot
reach with Tab, and every control without an accessible name. For each finding,
give the component file and write a failing Playwright test that proves it
before you change any code.

Co się psuje, gdy agent pisze kod frontendu?

Agent sam akceptuje swoją różnicę w zrzutach ekranu. Uruchamia polecenie aktualizacji snapshotów i test wizualny robi się zielony. Wyjście: zabroń aktualizacji wzorców w pliku instrukcji i przeglądaj zmiany wzorców jako osobny commit. Strona ochrona wyroczni pokazuje, jak zablokować agentowi edycję testów.
Kod używa API ze starszej wersji frameworka. Kod z Pages Routera trafia do projektu na App Routerze albo Options API do bazy kodu opartej na Composition API. Wyjście: podaj wersję i idiom w pliku instrukcji, a aktualną dokumentację dostarcz agentowi przez Context7.
Testy przechodzą w jsdom, a strona jest zepsuta. Wyjście: wymagaj co najmniej jednego testu w prawdziwej przeglądarce dla każdego zmienionego ekranu, jak w bramce powyżej.
Równolegli agenci kolidują na przeglądarce albo porcie serwera deweloperskiego. Wyjście: uruchamiaj serwer MCP z --isolated, startuj serwer deweloperski każdego worktree z jawnym --port i kieruj na ten port baseURL oraz webServer.url w konfiguracji Playwrighta. Konfigurację worktree opisuje strona równolegli agenci.
UI działa, ale wygląda generycznie. Wyjście: daj agentowi cel wizualny i skill projektowy; zobacz Taste Skill i Impeccable.

Dokąd dalej z przepisami frontendowymi

Przepisy dla Reacta

Weryfikacja w przeglądarce przez agenta

Automatyzacja testów end-to-end

Najlepsze skille do frontendu

Książka kucharska dla deweloperów AI