Skill v1.0.1

currentAutomated scan100/100

affaan-m/ecc/browser-qa

+4 new

──Details

PublishedSeptember 7, 2026 at 09:13 PM

Content Hashsha256:c501257d2c9ca711...

Git SHAcf065358fb67

Bump Typepatch

Compare with v1.0.0

──Files

Files (1 file, 3.7 KB)

SKILL.md3.7 KBactive

SKILL.md · 107 lines · 3.7 KB

version: "1.0.1" name: browser-qa description: Use this skill to automate visual testing and UI interaction verification using browser automation after deploying features. 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.

← v1.0.0 All versions