Claude Code for frontend development: build, check in the browser, refine

Is Claude Code good for frontend development?

Yes. Claude Code writes and refactors components, fixes styling and state bugs, and writes tests, and it does its best work when it can look at the result in a real browser. Connect it to Chrome or use the desktop app's preview, give it your design system, and it can build a screen, check it, and fix what it sees.

Frontend work is visual, which used to be the weak spot for terminal agents: code that compiles can still look wrong. That gap has mostly closed. Claude Code can read screenshots and mockups, open your app in a browser, read console errors and click through flows. This guide covers how to set that up, a workflow, prompts that work, the skills worth adding, and where the limits are.

What can Claude Code do for frontend work?

• Build from a mockup. Paste a screenshot with Ctrl+V (or Alt+V on Windows and WSL), drag in an image, or give a file path. The common workflows page lists prompts like "Generate CSS to match this design mockup."
• Match your existing code. Ask it to follow an existing page or component, so new code uses the same patterns, tokens and libraries.
• Check in a real browser. With the Chrome integration, Claude opens tabs in your Chrome, reads console errors and DOM state, and fixes the code that caused them.
• Preview in the desktop app. In the desktop app, Claude starts your dev server, opens it in the Browser pane and, by default, verifies its changes after edits.
• Run and verify. The bundled /run and /verify skills launch your app and confirm a change works in the running app, not just in type checks.
• Code intelligence. The official typescript-lsp plugin gives Claude go-to-definition, find-references and type errors from a language server.

How do you let Claude Code see your app?

You have three options, and they can be combined.

Chrome integration. Start a session with claude --chrome. The Chrome docs list what it unlocks, including "Live debugging: read console errors and DOM state directly, then fix the code that caused them" and "Design verification: build a UI from a Figma mock, then open it in the browser to verify it matches." Claude shares your browser's login state, works in a visible window and pauses at login pages and CAPTCHAs. It needs the Claude in Chrome extension and a direct Anthropic plan (Pro, Max, Team or Enterprise), and it isn't supported in WSL.

Desktop app preview. The desktop docs say Claude "takes screenshots, inspects the DOM, clicks elements, fills forms, and fixes issues it finds." It stores the dev server setup in .claude/launch.json, and you can turn auto-verify off there with "autoVerify": false if you prefer to ask for checks yourself.

Playwright. For repeatable checks and tests that also run in CI, the Playwright CLI skill and Anthropic's webapp testing skill let Claude drive a browser through Playwright.

What does a good frontend workflow look like?

1. Describe your stack once. Run /init, then add your framework, component library, design tokens and test commands to CLAUDE.md. See the CLAUDE.md guide.
2. Point at a reference. Name the page or component to match. Anthropic's prompt library gives the example "add a settings page that follows the same layout as the profile page."
3. Give it the design. Paste the mockup or connect Figma (below).
4. Ask it to check its own work. Include "open it in the browser and compare with the mockup" or "run the tests" in the prompt so Claude iterates instead of stopping after one attempt.
5. Review visually and in the diff. Look at the page at a few widths yourself, then read the code.
6. Lock in what you learned. When you correct the same thing twice, add it to CLAUDE.md or a skill.

A frontend CLAUDE.md section can be short:

## Frontend rules
- Next.js App Router, TypeScript strict, Tailwind, shadcn/ui components in components/ui.
- Use tokens from app/globals.css. No hard-coded colors or spacing.
- Every interactive element must be reachable by keyboard and have a visible focus state.
- Check new screens at 375px and 1280px wide before saying a task is done.
- Run npm run lint and npm test before finishing.

Which prompts work well for frontend development?

Build the pricing section from this mockup [paste image]. Reuse the Card and Button components from components/ui, use our tokens only, then open it in the browser at 375px and 1280px and fix anything that doesn't match.

The checkout form shows a blank screen after submit. Open localhost:3000/checkout, reproduce it, read the console errors, find the cause and fix it. Tell me what was wrong.

Add a settings page that follows the same layout as the profile page. Include loading, empty and error states, and write tests for the form validation.

Audit the signup flow for accessibility: labels, focus order, contrast and keyboard use. Fix what you can and list anything that needs a design decision.

Find the components that re-render on every keystroke in the search page, explain why, and fix them without changing behavior. Show me before and after.

The React prompts, JavaScript prompts and v0 prompts collections have more.

Which skills and MCP servers help frontend work?

For Figma, the remote server installation page gives a Claude Code plugin and a manual command:

claude plugin install figma@claude-plugins-official
# or
claude mcp add --transport http figma https://mcp.figma.com/mcp

The best MCP servers guide compares Figma, Playwright and other servers for frontend work.

What are the limits and safety points?

• Browser access is real access. The Chrome integration uses your logged-in browser, so Claude can reach any site you are signed in to. Site permissions come from the Chrome extension's settings, where you control which sites Claude can browse, click and type on. The Chrome guide covers the setup.
• Web pages can carry prompt injection. Text on a page can try to steer an agent. Be careful when Claude browses sites you don't control.
• Screenshots are approximate. Large images are downscaled before Claude sees them, so ask it to crop the region you care about when pixel detail matters.
• Taste is still yours. Claude can match a mockup, but whether a layout works for your users is a design call. Review it yourself at real screen sizes.
• Keep secrets out of the client. Ask Claude to flag any API key or token that ends up in client code, and review environment variable use in the diff.

How do Cursor and Codex compare for frontend work?

Cursor's Browser lets its agent "control a web browser to test applications, audit accessibility, convert designs into code, and more," inside the editor and without extra setup. Codex can connect to the same Figma MCP server, with codex mcp add figma --url https://mcp.figma.com/mcp on Figma's page. All three can load the same Agent Skills, so a design or accessibility skill you write once works across them. See Claude Code vs Cursor for the wider comparison.

How do you keep your UI prompts and design rules reusable?

Your component conventions and review checklists are the part that makes an agent's UI look like your product. Kipt keeps prompts and Agent Skills as Markdown in a private GitHub repo you own, with {{name}} blanks for things like component or page names, and installs every skill into Claude Code or Codex with one npx skills add command. To turn a design checklist into a skill today, try the free SKILL.md generator.