Review UI Changes with Playwright MCP in Claude Code
Use Playwright MCP in Claude Code for UI review evidence, not as an open-ended browser operator. Microsoft’s Playwright MCP server gives Claude Code a browser surface it can inspect and drive, which helps a Claude team check changed screens, reproduce a flow, and return review notes tied to visible behavior. A Playwright MCP Claude Code workflow works best when the task is narrow, the environment is local or disposable, and the reviewer knows what evidence should come back. In a Claude Code workshop, I would make the team write that review contract before connecting it to a real repo.
Start with a browser evidence job
Ask Claude Code to use the browser only after it has read the changed files and understood the user flow. Otherwise the agent can spend time clicking around without knowing which behavior matters.
A concrete workflow is a Next.js checkout change. Claude Code reads app/checkout/page.tsx, components/payment-form.tsx, and the related Playwright test, then opens the local checkout route through MCP and checks the changed path: empty cart, one item, invalid card, successful submit. The output should name the route, the inputs used, what changed on screen, and which claim still needs a human eye.
This belongs in the Review step of our methodology: delegate the browser pass, then review the evidence before you trust the proposed code. The MCP server helps collect observations, but it does not replace the reviewer’s judgment.
Rolling this out in your team?
We train engineering teams on their own codebase in two days. Claude Code setup, shared rules and review included.
Keep the server on a short leash
Give the Playwright MCP server a small job and a safe target. Localhost, preview deployments, seeded test users, and non-production data are the right defaults.
Do not let the first team convention be broad browser control. It is better to say: inspect this route, follow this flow, report evidence, and stop before making unrelated product decisions.
There is a tradeoff. Browser-backed review is slower than reading a diff, and UI flows can be flaky when data, animations, or auth are unstable. Use MCP when visual behavior matters, not for every refactor.
Use a slash command for repeatable UI review
A slash command is a good team artifact because it turns a vague review request into a repeatable sequence. Paste this into a repo command such as .claude/commands/ui-review.md if your team uses custom Claude Code commands.
# /ui-review
Use this command when reviewing a UI change with the Playwright MCP server.
Inputs:
- Local or preview URL:
- Changed files:
- User flow to check:
- Expected behavior:
- Known non-goals:
Steps:
1. Read the changed files before opening the browser.
2. State the user flow you will check.
3. Use Playwright MCP only against the supplied local or preview URL.
4. Exercise the happy path and one relevant failure path.
5. Do not use production credentials or production customer data.
6. Report browser evidence before proposing code changes.
7. If the evidence is weak or flaky, say so and stop.
Review output:
- Route and environment checked:
- Inputs used:
- Visible behavior observed:
- Mismatch with expected behavior:
- Suggested code change, if any:
- Test to add or update:
- Human review still needed:
The important part is the stop condition. Claude Code should not turn a UI review into a product redesign, a test rewrite, and a style cleanup unless the reviewer asked for that work.
Separate temporary evidence from durable rules
For Team conventions, keep the Playwright MCP workflow close to the review habit it supports. Do not bury temporary browser instructions in long-lived memory.
| Team artifact | Use it for | Limit |
|---|---|---|
| Playwright MCP server | Inspecting and driving a changed UI in a safe browser session | It gives observations, not proof that the feature is correct |
| Playwright tests | Turning important flows into repeatable regression checks | Tests need stable selectors, data, and ownership |
| Slash command | Making the review sequence easy to repeat across pull requests | It can go stale if the team changes its review process |
| CLAUDE.md | Stable repo rules, architecture notes, and conventions | It should not become a task checklist for one browser review |
| Claude skill | Reusable review technique that applies across repos or teams | It needs a clear activation description or it will not be used at the right time |
If your team already uses hooks to enforce review boundaries, pair this workflow with Claude Code Hooks for Team Conventions. The hook can protect the workflow, while the slash command tells the agent what useful review evidence looks like.
Further reading
Run one review on a small UI change
Bring one non-critical UI change to hands-on training on Claude Code team workflows and use the command above as the review exercise.
Train your team on Claude Code
Two days on your team's own repository, onsite or remote, with a written proposal before you commit.
Book a callPrefer to measure first? Take the free team check.