web-qa-explore

Explore a running web application in a real browser and report the bugs found, each with steps to reproduce and evidence.

Arguments

• A URL (required; ask for it when missing): the page or application to test, usually a local dev server.
• A focus (optional): a feature, a flow or a kind of problem (forms, navigation, mobile layout, performance).

Flow

1. Check the target. Confirm the URL answers. If it is not a local or staging address, ask the user to confirm that testing it is intended. Ask for a test account when the application needs a sign-in.
2. Map the application. From the routes in the code, when the repository is at hand, and from the page's own navigation, list the main flows. With a focus given, keep only the flows it touches. Tell the user which flows you will test.
3. Test each flow by delegating it to the web-qa-tester agent, a few flows at a time; without subagent support, drive the browser yourself with the playwright MCP server. For every flow cover:
   • the happy path, start to finish;
   • invalid and edge input: empty, very long, special characters, wrong formats, a double submit;
   • navigation: back and forward, reload in the middle of the flow, a deep link to an inner page;
   • a phone-sized viewport (390 pixels wide) besides the desktop one;
   • the keyboard: reaching and operating every control with Tab, Enter and Escape;
   • the browser console and the network: errors, failed and unexpectedly slow requests.
4. Performance (when asked, or when a page is visibly slow): record a trace of the page load with the chrome-devtools MCP server and note the largest contentful paint, layout shifts and long tasks.
5. Confirm every bug by reproducing it once more from a fresh page. Keep the ones that did not reproduce as "flaky".
6. Give the report. Change no code, and stop before any step the "Web QA" rules require asking about.

Report

• Summary: the URL, the flows tested, the viewports, and what was not tested and why.
• Bugs, most severe first. For each: title, severity (blocker, major, minor, cosmetic), the steps to reproduce, expected and actual result, the evidence, and the likely place in the code when the repository is at hand.
• Flaky observations, with how often each appeared.
• Console and network problems not tied to a bug above.
• Performance figures, when measured.
• Flows that passed, one line each.