Browser Qa
Run staged smoke, interaction, and visual checks on a live preview URL before you merge or ship frontend changes.
Overview
browser-qa is an agent skill most often used in Ship (also Launch distribution checks) that automates smoke, interaction, and visual regression testing on live pages via browser MCP.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill browser-qaWhat is this skill?
- Three-phase workflow: smoke (console and network), interaction (forms, auth, critical journeys), visual regression (375/
- Smoke targets LCP under 2.5s, CLS under 0.1, and INP under 200ms with desktop and mobile above-the-fold screenshots.
- Interaction pass covers nav links, valid/invalid forms, login-logout, and flows like checkout, onboarding, and search.
- Works with browser automation MCP stacks such as claude-in-chrome, Playwright, or Puppeteer on real pages.
- Designed for post-deploy staging checks and PRs that touch frontend or accessibility.
- 3 testing phases: smoke, interaction, visual regression
- 3 breakpoints: 375px, 768px, 1440px
- Core Web Vitals thresholds: LCP < 2.5s, CLS < 0.1, INP < 200ms
Adoption & trust: 3.7k installs on skills.sh; 210k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You shipped to preview but still do not know if forms, auth, or layouts work on real viewports without hours of manual clicking.
Who is it for?
Indie SaaS and marketing sites with staging URLs and browser MCP wired into Claude Code or similar agents.
Skip if: Pure API backends with no UI, or teams without any preview environment or browser automation permission.
When should I use this skill?
After deploying a feature to staging or preview, when verifying UI across pages, before shipping, when reviewing PRs that touch frontend, or for accessibility and responsive audits.
What do I get? / Deliverables
You get evidence-backed pass/fail on console health, critical journeys, and breakpoint screenshots before merge or production cutover.
- Smoke and interaction pass/fail summary
- Desktop and mobile screenshots
- Visual regression flags when baselines exist
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Browser QA belongs on Ship because it validates behavior on deployed or preview environments right before release. Testing is the canonical subphase for automated UI verification, Core Web Vitals gates, and regression screenshots.
Where it fits
Run Phase 1 smoke on a Vercel preview after merging a navbar refactor.
Execute interaction tests on onboarding and search before tagging a release candidate.
Confirm marketing landing CTAs and forms work on mobile width before a launch post goes live.
Attach breakpoint screenshots to a frontend PR review when you cannot run Playwright locally.
How it compares
Use for post-deploy human-like UI verification instead of relying only on Jest or Vitest without a browser.
Common Questions / FAQ
Who is browser-qa for?
Solo builders and small teams shipping web UIs who want an agent to exercise staging like a user after deploy or on frontend PRs.
When should I use browser-qa?
After staging deploy during Ship testing; before release on Launch distribution checks; when validating responsive or a11y-sensitive UI; whenever a PR touches frontend and you need live interaction proof.
Is browser-qa safe to install?
It drives a real browser against URLs you provide and may capture screenshots—use non-production credentials and scoped preview hosts. Review the Security Audits panel on this Prism page before enabling network and browser tools.
SKILL.md
READMESKILL.md - Browser Qa
# 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. ### 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 ``` ### 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 5. Test critical user journeys (checkout, onboarding, search) ``` ### Phase 3: Visual Regression ``` 1. Screenshot key pages at 3 breakpoints (375px, 768px, 1440px) 2. Compare against baseline screenshots (if stored) 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 AA violations (contrast, labels, focus order) 3. Verify keyboard navigation works end-to-end 4. Check screen reader landmarks ``` ## 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) ``` ## 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.