UI browser check
The user may struggle to describe what they see. Use the Playwright MCP server
(project .cursor/mcp.json or user MCP settings) to open the app and inspect via
accessibility snapshots before guessing from code alone.
Before browsing
- Find how to run dev — read
README.md, package.json scripts, or ask.
Common: pnpm dev, npm run dev, yarn dev. Note host/port (often
http://localhost:3000; may differ).
- Confirm dev is running at the URL the user uses (including LAN/device hosts
like
http://0.0.0.0:3000 if they test on a phone).
- Auth / demo: follow project docs (
README, CONTRIBUTING, .env.example).
Do not guess passwords; ask or use documented test/demo accounts only.
- E2E vs MCP: MCP is for exploration. Do not replace the project's committed
e2e suite (
pnpm test:e2e, npm test, etc.) for regression — run that when
the issue might be a regression.
What to do in the browser
- Navigate to the route or screen they mean (ask if unclear; infer from
src/app,
pages/, or routes in docs).
- Reproduce steps they gave (or reasonable variants).
- Use accessibility snapshots: roles, names, states, disabled, expanded.
- Note: labels, error text, duplicate banners, layout order, focus traps, broken links.
- Check console errors and failed network requests when MCP exposes them.
- Report back in plain language what you observed (what a user would see).
Limits
- MCP may miss purely visual issues (contrast, pixel overflow). Ask for a screenshot if suspected.
- For regressions, still run the project's e2e tests when available.
Ports (avoid confusion)
| Typical URL |
Purpose |
| Dev server URL from README |
Dev — what the user usually has open |
| Separate e2e / preview port in config |
Test server — check playwright.config.*, CI, or README |
When dev and test ports differ, state which URL you used.
If Playwright MCP is unavailable
Ask for a screenshot, screen recording, URL, and repro steps. Run the project's
e2e tests if the issue might be a regression.
Related skills
- debug — root cause after you know what the UI shows
- implement — apply a code fix in the repo
- plan-driven-implementation — log browser findings in plan Issues & fixes log during initiative work
- web-design-engineer — design exploration or in-repo UI polish
- test — regression via the project's e2e suite
1---2name: ui-browser-check3description: Use Playwright MCP to inspect a running web app when the user reports a visual or interaction issue but cannot describe it precisely. Use when they mention layout, spacing, wrong copy, button behavior, hydration flash, or "something looks off" on any page or route.4---56# UI browser check78The user may struggle to describe what they see. **Use the Playwright MCP server**9(project `.cursor/mcp.json` or user MCP settings) to open the app and inspect via10accessibility snapshots before guessing from code alone.1112## Before browsing13141. **Find how to run dev** — read `README.md`, `package.json` scripts, or ask.15 Common: `pnpm dev`, `npm run dev`, `yarn dev`. Note host/port (often16 `http://localhost:3000`; may differ).172. Confirm **dev is running** at the URL the user uses (including LAN/device hosts18 like `http://0.0.0.0:3000` if they test on a phone).193. **Auth / demo:** follow project docs (`README`, `CONTRIBUTING`, `.env.example`).20 Do not guess passwords; ask or use documented test/demo accounts only.214. **E2E vs MCP:** MCP is for exploration. Do not replace the project's committed22 e2e suite (`pnpm test:e2e`, `npm test`, etc.) for regression — run that when23 the issue might be a regression.2425## What to do in the browser2627- Navigate to the route or screen they mean (ask if unclear; infer from `src/app`,28 `pages/`, or routes in docs).29- Reproduce steps they gave (or reasonable variants).30- Use **accessibility snapshots**: roles, names, states, disabled, expanded.31- Note: labels, error text, duplicate banners, layout order, focus traps, broken links.32- Check **console errors** and failed network requests when MCP exposes them.33- Report back in plain language what you observed (what a user would see).3435## Limits3637- MCP may miss **purely visual** issues (contrast, pixel overflow). Ask for a screenshot if suspected.38- For regressions, still run the project's e2e tests when available.3940## Ports (avoid confusion)4142| Typical URL | Purpose |43|-------------|---------|44| Dev server URL from README | **Dev** — what the user usually has open |45| Separate e2e / preview port in config | **Test server** — check `playwright.config.*`, CI, or README |4647When dev and test ports differ, state which URL you used.4849## If Playwright MCP is unavailable5051Ask for a screenshot, screen recording, URL, and repro steps. Run the project's52e2e tests if the issue might be a regression.5354## Related skills5556- **debug** — root cause after you know what the UI shows57- **implement** — apply a code fix in the repo58- **plan-driven-implementation** — log browser findings in plan Issues & fixes log during initiative work59- **web-design-engineer** — design exploration or in-repo UI polish60- **test** — regression via the project's e2e suite
Axidify