← Back to Skills Marketplace
Browser QA
by
Deonte Cooper
· GitHub ↗
· v1.0.1
· MIT-0
208
Downloads
0
Stars
1
Active Installs
2
Versions
Install in OpenClaw
/install browser-qa
Description
Automate visual testing and UI interaction verification. 4-phase methodology: smoke test (console errors, network status, Web Vitals), interaction test (form...
README (SKILL.md)
Browser QA — Automated Visual Testing & Interaction
Structured QA methodology for verifying UI behavior, visual consistency, and accessibility.
Quick Start
- Phase 1: Smoke Test — Navigate page, check for console errors, verify Core Web Vitals
- Phase 2: Interaction Test — Click links, submit forms, verify user flows (login, checkout)
- Phase 3: Visual Regression — Screenshot key pages at 3 breakpoints (375px, 768px, 1440px)
- Phase 4: Accessibility — Run axe-core, verify keyboard nav, check screen reader landmarks
Key Concepts
- Smoke Test: Detects hard-breaking errors before interaction testing wastes time
- Interaction Test: Verifies critical user journeys (auth, forms, checkout)
- Visual Regression: Detects layout shifts, missing elements, viewport overflow issues
- Accessibility: WCAG AA compliance, keyboard navigation, screen reader support
Common Usage
Phase 1: Smoke Test
1. Navigate to target URL
2. Check for console errors (filter analytics noise)
3. Verify no 4xx/5xx in network requests
4. Screenshot above-the-fold (desktop + mobile)
5. Check Core Web Vitals: LCP \x3C 2.5s, CLS \x3C 0.1, INP \x3C 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 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 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
## 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, low contrast footer links
### Verdict: SHIP WITH FIXES (2 issues, 0 blockers)
References
references/tools.md— browser automation tools (claude-in-chrome, Playwright, Puppeteer)references/wcag.md— WCAG AA checklist and common violations
Adapted from everything-claude-code by @affaan-m (MIT)
Usage Guidance
This is an instruction-only QA methodology and is coherent with its description, but before running it you should: (1) ensure you have the required tooling (Playwright/Puppeteer/axe-core or an appropriate browser automation setup) installed in a controlled environment; (2) avoid running tests against production with your real Chrome profile — use a dedicated test profile or a headless browser to prevent accidental access to cookies/session data; (3) provide only test/staging credentials (never leak real user credentials) if you need to validate auth flows; (4) review any npm packages the agent suggests installing yourself before executing installs; and (5) if you plan to allow autonomous runs, accept that automation using your local browser may touch local data — prefer isolated CI/staging environments for sensitive sites.
Capability Analysis
Type: OpenClaw Skill
Name: browser-qa
Version: 1.0.1
The browser-qa skill bundle is a legitimate tool designed for automated UI testing, visual regression, and accessibility audits. The instructions in SKILL.md and the documentation in references/tools.md and references/wcag.md provide a standard QA methodology using tools like Playwright and Puppeteer without any evidence of malicious intent, data exfiltration, or unauthorized execution.
Capability Assessment
Purpose & Capability
The name and description (automated visual testing, interaction checks, accessibility) match the SKILL.md and reference docs. However, the skill references tooling (Playwright, Puppeteer, axe-core, and 'claude-in-chrome') and includes example code/snippets that imply Node/npm usage and a local Chrome instance, yet the registry metadata declares no required binaries, packages, or env vars. This mismatch is explainable for an instruction-only guide but worth noting: the skill will realistically need browser automation tooling present.
Instruction Scope
Instructions stay within QA scope (navigate pages, capture console/network, take screenshots, run axe-core, test auth flows). They do not instruct reading arbitrary files or contacting unknown endpoints. One important scope consideration: the guidance recommends using a real Chrome instance ('claude-in-chrome') and testing auth flows; that can access local browser profile, cookies, and authenticated sessions if used — a privacy/attack surface consideration even though it is coherent with testing authenticated journeys.
Install Mechanism
There is no install spec and no code files to run; the skill is instruction-only. This is the lowest install risk. References include example npm commands (e.g., installing @axe-core/react) and Playwright example code, which implies the operator will install packages themselves; that is expected for an instructions-only QA guide.
Credentials
The skill requests no environment variables or credentials. Practically, many of the suggested tests (auth flow, staging tests) require test credentials or access to a staging environment; those are not requested by the skill. Also, using the user's local Chrome for tests can expose cookies or other session data — the skill does not request them explicitly, but the operational guidance implies access to sensitive local browser state. This is a proportionality note, not a direct contradiction.
Persistence & Privilege
The skill does not request persistent presence (always:false) and does not claim to modify other agent configurations. It is user-invocable and can be run autonomously per platform defaults; nothing in the package requests elevated privileges or persistent/system-wide changes.
How to Use
- Make sure OpenClaw is installed (local or Docker)
- Run the install command in chat:
/install browser-qa - After installation, invoke the skill by name or use
/browser-qa - Provide required inputs per the skill's parameter spec and get structured output
Version History
v1.0.1
Fix: replace bare code blocks with ```text for consistent rendering
v1.0.0
Initial release. 4-phase browser QA methodology with accessibility testing. Adapted from everything-claude-code by @affaan-m (MIT)
Metadata
Frequently Asked Questions
What is Browser QA?
Automate visual testing and UI interaction verification. 4-phase methodology: smoke test (console errors, network status, Web Vitals), interaction test (form... It is an AI Agent Skill for Claude Code / OpenClaw, with 208 downloads so far.
How do I install Browser QA?
Run "/install browser-qa" in the OpenClaw or Claude Code chat to install it in one step — no extra setup required.
Is Browser QA free?
Yes, Browser QA is completely free, licensed under MIT-0. You can download, install and use it at no cost.
Which platforms does Browser QA support?
Browser QA is cross-platform and runs anywhere OpenClaw / Claude Code is available (linux, darwin, win32).
Who created Browser QA?
It is built and maintained by Deonte Cooper (@djc00p); the current version is v1.0.1.
More Skills