# UI Browser Check

> 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.

- Skill: `axidify/ui-browser-check` (Agent Skill)
- Install (CLI): `npx skillmds@latest add axidify/ui-browser-check`
- Raw SKILL.md: https://api.skillmd.com/api/skills/axidify/ui-browser-check/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: Axidify (https://skillmd.com/u/axidify)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/axidify/ui-browser-check

---


# 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

1. **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).
2. 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).
3. **Auth / demo:** follow project docs (`README`, `CONTRIBUTING`, `.env.example`).
   Do not guess passwords; ask or use documented test/demo accounts only.
4. **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