browser-qa — Claude skill: post-deploy UI checks
Drives a live page through a browser MCP: console errors, Core Web Vitals, forms, screenshots at three widths and axe-core. Ends with a SHIP or DO NOT SHIP verdict.
npx skills add affaan-m/ECC --skill browser-qa -a claude-codeWhat browser-qa does
The skill walks a deployed page the way a person would. First a smoke pass: console errors with analytics noise filtered out, network responses free of 4xx and 5xx, an above-the-fold screenshot on desktop and mobile, and LCP, CLS and INP readings. Then interaction — clicking every nav link, submitting forms with valid and invalid data, logging in and out with test credentials, running critical journeys.
Visual regression comes next. Key pages are captured at 375px, 768px and 1440px and compared against committed baselines. Layout shifts over 5px, missing elements and overflow get flagged. No baseline means the report says INCONCLUSIVE rather than a silent PASS. The last phase is accessibility through axe-core: WCAG 2.2 AA violations, focus order, keyboard navigation, screen reader landmarks.
Any browser MCP works: claude-in-chrome tools, Playwright via mcp__browserbase__*, or plain Puppeteer scripts. Everything runs read-only by default. Mutating journeys such as checkout or delete never touch a production URL without explicit opt-in and a staging URL, and credentials, tokens and PII should be redacted before any screenshot is saved. Worth installing if frontend ships often and you want broken forms and layout caught before users hit them. On a project with no staging environment the payoff drops.
What it helps with
- catch console errors on a deployed page
- test forms with valid and invalid input
- diff layout against baseline screenshots at three widths
- run axe-core and surface WCAG 2.2 AA violations
- verify login and logout with test credentials
Example prompts for the agent
- run browser-qa against the preview URL and tell me if we can ship
- check forms and navigation on staging, give me the verdict report
- do visual regression at 375, 768 and 1440 and audit accessibility
How to install browser-qa
1Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill browser-qa -a claude-code2Manually: put the files in place
~/.claude/skills/browser-qa/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/browser-qa/
1Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill browser-qa -a codex2Manually: put the files in place
.agents/skills/browser-qa/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill browser-qa -a cursor2Manually: put the files in place
.cursor/skills/browser-qa/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install affaan-m/ECC browser-qa2Manually: put the files in place
.github/skills/browser-qa/SKILL.md1Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill browser-qa -a gemini-cli2Platform CLI
gemini skills install https://github.com/affaan-m/ECC --path skills/browser-qaManually: put the files in place
.devin/skills/browser-qa/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill browser-qa -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
From the same set146
The whole set →Similar
Questions about browser-qa
How do I install browser-qa in Claude?
Run npx skills add affaan-m/ECC --skill browser-qa -a claude-code. The skill lands in ~/.claude/skills/browser-qa/SKILL.md.
What does browser-qa do?
It verifies a deployed UI through a browser MCP: console, network, Core Web Vitals, forms, auth, screenshots at three breakpoints and accessibility. It closes with a SHIP, SHIP WITH FIXES or DO NOT SHIP verdict.
Which browser MCPs does the skill support?
claude-in-chrome, Playwright through mcp__browserbase__*, and direct Puppeteer scripts. Mutating journeys only run against staging with explicit opt-in.
Source text
SKILL.md · MIT
---
name: browser-qa
description: "Run automated post-deploy UI verification with a browser automation MCP (claude-in-chrome, Playwright, or Puppeteer): console-error and Core Web Vitals smoke checks, form and auth-flow interaction tests, screenshot visual regression across three breakpoints, and axe-core accessibility audits ending in a SHIP / DO-NOT-SHIP verdict. Use when testing a deployed feature on staging or preview, before shipping frontend changes, reviewing a frontend PR, or checking responsive layout and accessibility."
metadata:
origin: ECC
---
# Browser QA — Automated Visual Testing & Interaction
## When to Use
- After deploying a feature to staging/preview
- When you need to verify UI behavior across pages
- Before shipping — confirm layouts, forms, interactions actually work
- When reviewing PRs that touch frontend code
- Accessibility audits and responsive testing
## How It Works
Uses the browser automation MCP (claude-in-chrome, Playwright, or Puppeteer) to interact with live pages like a real user.
### Safety first — blast radius (run read-only by default)
Browser QA drives real auth and real user journeys, so treat the blast radius explicitly.
Default to **read-only**: never run a **mutating** journey (checkout, payment, delete,
mass-update) against a production URL — require an explicit opt-in **and** a staging/preview
URL. Use seeded **test credentials**, never real production logins, and **redact**
credentials/tokens/PII before saving any screenshot.
### Phase 1: Smoke Test
```
1. Navigate to target URL
2. Check for console errors (filter noise: analytics, third-party)
3. Verify no 4xx/5xx in network requests
4. Screenshot above-the-fold on desktop + mobile viewport
5. Check Core Web Vitals: LCP < 2.5s, CLS < 0.1, INP < 200ms
(INP replaced FID in March 2024; thresholds per web.dev)
```
### Phase 2: Interaction Test
```
1. Click every nav link — verify no dead links
2. Submit forms with valid data — verify success state
3. Submit forms with invalid data — verify error state
4. Test auth flow: login → protected page → logout (test creds only, never prod)
5. Test critical user journeys (checkout, onboarding, search)
— read-only by default; only exercise mutating journeys against staging
with explicit opt-in (see "Safety first" above)
```
### Phase 3: Visual Regression
```
1. Screenshot key pages at 3 breakpoints (375px, 768px, 1440px)
2. Compare against committed baseline screenshots
— no baseline ⇒ report INCONCLUSIVE, never a silent PASS
3. Flag layout shifts > 5px, missing elements, overflow
4. Check dark mode if applicable
```
### Phase 4: Accessibility
```
1. Run axe-core or equivalent on each page
2. Flag WCAG 2.2 AA violations (contrast, labels, focus order)
3. Verify keyboard navigation works end-to-end
4. Check screen reader landmarks
```
> Note: axe-core automatically covers roughly 30–40% of WCAG. A clean run is **necessary,
> not sufficient** — keyboard nav, focus order, and a screen-reader pass still need a manual
> check. Don't report "accessible" from an automated pass alone.
## Output Format
```markdown
## QA Report — [URL] — [timestamp]
### Smoke Test
- Console errors: 0 critical, 2 warnings (analytics noise)
- Network: all 200/304, no failures
- Core Web Vitals: LCP 1.2s ✓, CLS 0.02 ✓, INP 89ms ✓
### Interactions
- [✓] Nav links: 12/12 working
- [✗] Contact form: missing error state for invalid email
- [✓] Auth flow: login/logout working
### Visual
- [✗] Hero section overflows on 375px viewport
- [✓] Dark mode: all pages consistent
### Accessibility
- 2 AA violations: missing alt text on hero image, low contrast on footer links
### Verdict: SHIP WITH FIXES (2 issues, 0 blockers)
# verdict ∈ SHIP / SHIP WITH FIXES / DO NOT SHIP; use INCONCLUSIVE if no visual baseline
```
## Integration
Works with any browser MCP:
- `mChild__claude-in-chrome__*` tools (preferred — uses your actual Chrome)
- Playwright via `mcp__browserbase__*`
- Direct Puppeteer scripts
Pair with `/canary-watch` for post-deploy monitoring.
© affaan-m · MIT · affaan-m/ECC