browser-qa

Execute browser QA workflows on UI tickets and report PASS/FAIL/BLOCKED outcomes.

44|8|Updated Jul 14, 2025
One-click install
npx skills add https://github.com/thegeronimo/hyperopen --skill browser-qa-thegeronimo
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: browser-qa
Source: https://github.com/thegeronimo/hyperopen/tree/main/.agents/skills/browser-qa
Command: npx skills add https://github.com/thegeronimo/hyperopen --skill browser-qa-thegeronimo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Use for multi-agent browser QA to gather browser evidence, run governed QA passes, and report PASS/FAIL/BLOCKED outcomes for UI-facing work. Do not use for application-code edits.

Core Features & Use Cases

  • Collect browser evidence during UI tests to verify behavior and detect regressions.
  • Run standardized QA passes using the browser_debugger role and document results for ticket closure.
  • Use the browser-live-inspection artifacts to reproduce issues and produce an auditable QA trail.

Quick Start

Open a browser session and execute the browser QA workflow against the targeted UI ticket.

Frequently Asked Questions about browser-qa

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I automate UI testing evidence collection for browser QA?

Automate UI testing evidence collection by executing the browser QA workflow on a UI ticket, which gathers browser-live-inspection artifacts to verify behavior and detect regressions. It generates a browser-report.json file to document results.

What is a PASS/FAIL/BLOCKED outcome in multi-agent browser QA?

A PASS/FAIL/BLOCKED outcome in multi-agent browser QA is the standardized result generated after running governed QA passes. It validates UI behavior across agents and produces an auditable trail for ticket closure.

Can I use browser QA reporting for application-code edits and debugging?

No, browser QA reporting is strictly for gathering browser evidence and running governed QA passes on UI-facing work. It requires a browser-debugger role to inspect artifacts and should not be used for application-code edits.

Do I need a browser-debugger role to run standardized QA passes?

Yes, you need a browser-debugger role to run standardized QA passes. It accesses browser-inspection artifacts to reproduce UI issues, validate behavior, and produce the final browser-report.json evidence for ticket closure.

What's the best way to reproduce UI issues and create an auditable QA trail?

The best way to reproduce UI issues is using browser-live-inspection artifacts during a browser QA workflow. This collects evidence during UI tests to detect regressions and generates an auditable QA trail for reporting.