Guide · Agent skill
How to use the Browser QA agent skill: install and run it
Updated · written with AI from the project's own documentation and checked against our catalogue data
browser-qa is an agent skill, a folder of written instructions that tells an AI agent how to test a deployed web page in a real browser. This guide explains what the skill makes the agent do, how to install it, how to ask for a test in plain language, and what to watch for before running it. By the end you will be able to run a smoke, interaction, visual and accessibility check on a staging or preview site and read the pass/fail report it produces.
Browser QA Testingaffaan-m/ECC · MIT Download the skill Quick start
- 1Install a browser automation tool. Set up Playwright, Puppeteer or claude-in-chrome (MCP) so the agent can drive a real browser. The skill cannot run without one.
- 2Download the skill ZIP. Download the ZIP from this page. It contains SKILL.md.
- 3Unzip into the skills folder. Place the folder in ~/.claude/skills/ for personal use or in your project's .claude/skills/ folder.
- 4Or upload it in the Claude apps. Go to Settings → Capabilities → Skills and upload the skill.
- 5Make a test environment ready. Use a staging or preview URL, and prepare test credentials if you plan to test login.
- 6Ask for a test in plain language. Name the URL and what to check, such as smoke test, responsive widths or accessibility.
- 7Review the QA report. Read the pass and fail ticks, then fix or retest the failing items.
What the browser-qa skill makes the agent do
The skill is organised as four phases. A smoke test loads the target URL, checks the console for errors (filtering out analytics and third-party noise), confirms there are no 4xx or 5xx network responses, takes screenshots at desktop and mobile viewports, and checks Core Web Vitals against LCP under 2.5s, CLS under 0.1 and INP under 200ms.
The interaction phase clicks every navigation link to find dead links, submits forms with valid data and then invalid data to check success and error states, and tests login, protected page and logout flows along with key journeys such as checkout, onboarding or search.
The visual regression phase takes screenshots at 375px, 768px and 1440px, compares them with saved baselines if they exist, and flags layout shifts over 5px, missing elements and overflow. The accessibility phase runs axe-core or an equivalent engine on each page and reports WCAG AA violations and keyboard navigation problems.
The output is a QA report with ticks and crosses for each check, using a Markdown template from the skill.
What you need before you install it
The skill itself is only written instructions. It cannot drive a browser on its own, so you need a browser automation tool such as Playwright, Puppeteer or claude-in-chrome (MCP). The skill also references an accessibility engine such as axe-core, or an equivalent.
If you want the login flow tested, you will need test credentials. The skill file does not say how to supply them.
- A browser automation tool: Playwright, Puppeteer or claude-in-chrome (MCP)
- An accessibility engine such as axe-core, or equivalent
- Test credentials, only if you test a login flow
Install the browser-qa skill
Download the ZIP from the skill page on this site. The package contains a single file, SKILL.md. Unzip it so the skill folder sits in one of the locations below.
For a personal install, place the folder in ~/.claude/skills/. For a single project, place it in that project's .claude/skills/ folder. You can also upload the skill in the Claude apps under Settings → Capabilities → Skills.
- Personal: ~/.claude/skills/
- Project only: .claude/skills/ inside your project
- Claude apps: Settings → Capabilities → Skills, then upload
How to trigger the skill with natural requests
You do not need a special command. Describe the task in plain language and name the page or environment. The skill's own description says it runs browser automation for visual testing and UI interaction checks after a feature is deployed, so requests about a deployed page are the ones it fits.
Be specific about the URL and what you care about. Say whether you want a smoke test, a responsive check, an accessibility audit or a full run.
- Check the staging page at [URL] after this deploy and report any console or network errors.
- Test the signup form on the preview environment with valid and invalid data.
- Check the homepage at phone, tablet and desktop widths for layout breaks.
- Run an accessibility check against WCAG AA on the pricing page.
- Review the frontend changes in this pull request by running the browser QA checklist on the preview link.
Read the QA report
The skill asks for a report in a fixed format, so results are easy to compare between runs. Each check is marked with a tick for pass or a cross for failure, and accessibility violations are counted by WCAG level.
- Smoke test: page load, console errors, Core Web Vitals and screenshots
- Interaction test: navigation, form validation and any broken menus
- Visual regression: layout by viewport, with overflow or image problems flagged
- Accessibility: counts of WCAG AA and WCAG A violations
## QA Report — [URL] — [timestamp]
### Smoke Test
- ✓ ページが読み込まれる
- ✗ コンソールエラー：オプト不可なトラッキング警告
- ✓ Core Web Vitals OK
- [スクリーンショット]Safety notes: scripts and network access
The skill does not run scripts. It is instructions only, and it uses the network, because the browser tool loads and interacts with your live page.
Do not point it at production sites with logins or real customer data. The flow submits forms and tests login, which could change live accounts or records. Use a staging or preview environment instead.
- Runs scripts: no
- Uses network: yes
- Avoid production sites with real accounts or customer data
Tips for better results
Give the agent a clear list of key pages and journeys, because the skill tests what it is pointed at. Keep saved baseline screenshots if you want visual regression comparisons, since the skill compares against baselines only when they exist.
The skill also pairs with other commands in the same project: it can be used with /benchmark for performance checks, with /canary-watch for post-deploy monitoring, and in a pull request workflow to catch frontend changes.
- Name the exact URL and environment each time
- Save baseline screenshots for visual comparisons
- Pair with /benchmark for performance and /canary-watch for post-deploy monitoring
What people use it for
- Smoke-testing a feature on a staging site right after deploy
- Checking a pull request that changes forms or layout on its preview link
- Verifying responsive layout at 375px, 768px and 1440px
- Running a repeatable WCAG AA accessibility checklist across key pages
- Testing a signup or search flow with valid and invalid inputs
Frequently asked questions
Is browser-qa free to use?
The skill is published under the MIT licence, as stated on this page. The browser automation tool it needs, such as Playwright or Puppeteer, is a separate project with its own licence, so check those before you rely on them.
What do I need to install browser-qa?
You need the SKILL.md file from the ZIP placed in ~/.claude/skills/ or a project's .claude/skills/ folder, or uploaded under Settings → Capabilities → Skills. You also need a browser automation tool such as Playwright, Puppeteer or claude-in-chrome (MCP), because the skill cannot drive a browser by itself.
Does browser-qa run scripts on my machine?
The skill is only written instructions and does not run scripts. It does use the network, since the browser tool loads and interacts with the page you point it at.
Can I run browser-qa on a production site?
This is not recommended. The flow submits forms and tests login, which could affect live accounts or customer records. Use a test or staging environment instead.
Why does the skill need axe-core?
The accessibility phase runs axe-core, or an equivalent engine, on each page to find WCAG AA violations such as contrast, labels and focus order. The skill references it, so it should be available in your setup.
What are the alternatives to browser-qa?
The source does not compare this skill with other tools. You can write your own test scripts in Playwright or Puppeteer directly, which give you more control but require more code. browser-qa is a checklist the agent follows using one of those tools.
New agent skills, repos and AI tools — every week
The best new skills and open-source projects, the fastest-growing repos, and one free prompt. Five minutes to read. Unsubscribe anytime.
Our verdict
Use browser-qa if you are a developer or front-end reviewer who wants a consistent smoke, responsive and accessibility checklist on a staging or preview site, and you already have Playwright, Puppeteer or claude-in-chrome set up. Skip it if you need a finished testing app, want to test production sites with real accounts, or do not have a browser automation tool installed.
Download the skill