How to use
- Copy the installation command and review the source package before installing it in your own agent environment.
- Check the source document for required tools, credentials and supported hosts.
- Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/affaan-m/ecc --skill browser-qaBefore you start
- Installation does not include a model subscription, API allowance or permission to access your files.
- Repository stars and installation counts describe activity, not an independent quality or security test.
Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
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 applicablePhase 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 landmarksNote: 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
## 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 baselineIntegration
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.


