Run practical browser-backed QA against real routes, forms, viewports, accessibility, console, and network behavior. Use for UI, authentication, session, navigation, or browser-network changes.
Installs into .claude/skills of the current project.
Are you the author of Planr Browser Qa?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/openplanr-planr-browser-qa)
---
name: planr-browser-qa
description: "Run practical browser-backed QA against real routes, forms, viewports, accessibility, console, and network behavior. Use for UI, authentication, session, navigation, or browser-network changes."
---
# OpenPlanr Browser QA
Exercise the real browser surface directly and return useful findings from the current request and
repository context.
## Establish the target
Infer the routes, user journeys, runtime command, and relevant viewports from the request and
repository. Ask one concise question only when the target or required credentials cannot be
inferred. Never persist credentials, cookies, or session secrets.
## Run focused browser checks
1. Start or reuse the project's documented local runtime.
2. Exercise the requested route and the shortest meaningful happy path.
3. Check navigation, forms, responsive layout, keyboard access, visible focus, accessible names,
console errors, failed requests, and loading or error states that are relevant to the change.
4. When a browser capability is unavailable, report the exact missing capability and provide the
smallest runnable fallback; do not invent a PASS.
5. Remain report-only. When the user also wants fixes, return reproducible findings that a coding
workflow can act on, then rerun Browser QA after those changes are available.
## Return
Lead with the observed result. Link relevant browser evidence and expand only
actionable findings; keep long console/network logs in the report. Report checks
not exercised as unverified, with the missing capability and smallest recovery
action. A passing subset must not imply that the entire application passed.
- **Outcome:** pass, issues-found, or blocked, with one sentence.
- **Coverage:** routes, journeys, viewports, and checks actually exercised.
- **Findings:** prioritized reproducible problems with path or UI location and expected behavior.
- **Fixes:** changed files and verification, or none.
- **Issues:** missing capability or unresolved risk, or none.
Omit empty categories in the human summary and preserve the actual browser
evidence. Different summary wording never requires another browser run.
