Frontend recipes

The frontend recipes are five pages of copy-paste prompts for Claude Code, Codex, and Cursor, one each for Angular, Next.js, Nuxt, React, and Vue. Each recipe works best when the agent can open the running app in a browser and when the repository names its gates: type check, unit tests, a browser test, an accessibility scan, and a screenshot.

This hub is for developers who let an agent write interface code. You know the failure: the component compiles, the unit test passes, and the screen is still wrong. The layout breaks at 375 pixels, a hydration warning fills the console, the modal traps no focus, and nobody notices until a user does.

Which frontend recipe fits your framework?

Every recipe assumes the browser and gate setup in the next two sections.

Your framework	Recipe	What the recipe covers
Angular	Angular development recipes	Signals, standalone components, typed forms, lazy routes, interceptors
Next.js App Router	Next.js optimization recipes	Server Components, streaming, Server Actions, caching, Core Web Vitals
Nuxt	Nuxt 4 development recipes	Server routes, data-fetching composables, hybrid rendering, testing
React	React development recipes	Typed components from a design, server state, forms, error boundaries, tests
Vue 3	Vue.js workflow recipes	Composition API, Pinia stores, composables, lazy routes, i18n

React Native, Flutter, and Expo live in mobile development recipes. Skills that raise the design quality of generated UI are compared in best skills for frontend development.

Give the agent a browser before the first recipe

An agent that cannot see the page guesses at layout. A browser MCP server lets it load the dev server, click through a flow, read the console, and take a screenshot. Playwright MCP (@playwright/mcp, 0.0.82 on 2026-09-26) is the common choice. The --isolated flag keeps the browser profile in memory, so two agents in two worktrees do not fight over one profile.

Claude Code

Run in a terminal inside the repository:

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

Add --scope project to write the entry to .mcp.json and share it with the team.

Codex

Run in a terminal:

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

codex mcp list confirms the entry.

Cursor

Add the server to .cursor/mcp.json in the project, the shape Playwright’s README documents for Cursor:

.cursor/mcp.json

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

For performance traces and network inspection, add Chrome DevTools MCP (chrome-devtools-mcp, 1.10.1) the same way, for example codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest. It sends usage statistics to Google unless you add --no-usage-statistics. Playwright MCP versus Playwright CLI covers the flags, the parallel-worktree setup, and the CLI route that costs less context.

Write the frontend gate into the agent’s instructions

A recipe ends with “run the gate”, so the repository has to say what the gate is. For a TypeScript app with Vitest and Playwright:

AGENTS.md

## 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 reads CLAUDE.md; from v2.1.277 (the latest channel) it also reads AGENTS.md when the project has no CLAUDE.md, so on the stable channel keep a CLAUDE.md with the line @AGENTS.md. Codex reads AGENTS.md once you trust the project. In Cursor, repeat both sections in a project rule that applies to every request. The CI job that runs the same commands on every pull request is the gate that decides.

How do you verify UI code without reading every line?

Ask for the check that goes red for each failure, and require the agent to attach its output.

Failure	The check that catches it
Layout breaks on a small screen	A Playwright test per viewport, plus a toHaveScreenshot comparison against a committed baseline
Hydration mismatch or runtime error	A browser test that fails when the page logs a console error
Missing labels, contrast, focus order	An axe scan in the browser test, plus a keyboard-only test of the flow; see accessibility testing
The component looks nothing like the design	An agreed mock or screenshot as the acceptance target; see visual acceptance before frontend implementation
Bundle or performance regression	A bundle-size budget or a Lighthouse run in CI that fails above a threshold

A human signs off twice: on the visual target before the agent starts, and on the screenshots and any changed baseline after it finishes. Both go into the pull request’s evidence bundle.

The prompts work unchanged in Claude Code, Codex and Cursor once the Playwright MCP server is connected.

Copy-paste prompt: a component that proves itself

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.

Copy-paste prompt: audit a screen in the browser

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.

What breaks when agents write frontend code?

• The agent accepts its own screenshot diff. It runs the update-snapshots command and the visual test goes green. Recovery: forbid baseline updates in the instruction file, and review baseline changes as their own commit. Protect the oracle shows how to make tests read-only for the agent.
• The code uses an API from an older framework version. Pages Router code lands in an App Router project, or Options API code in a Composition API codebase. Recovery: state the version and the idiom in the instruction file, and give the agent current docs through Context7.
• Tests pass in jsdom but the page is broken. Recovery: require at least one real-browser test per changed screen, as in the gate above.
• Parallel agents collide on the browser or the dev-server port. Recovery: run the MCP server with --isolated, start each worktree’s dev server with an explicit --port, and point Playwright’s baseURL and webServer.url at that port. See parallel agents for the worktree setup.
• The UI works but looks generic. Recovery: give the agent a design target and a design skill; see Taste Skill and Impeccable.

Where to go next with frontend recipes

React development recipes

Agent-driven browser verification

End-to-end test automation

Best skills for frontend development

AI Developer Cookbook