Read-Only Browser QA Skill

A browser agent can produce a convincing screenshot while proving almost nothing. It may be on the wrong account, the wrong environment, or a stale page. It may also cross a line that looked harmless—a button marked “Continue,” a form field containing private data, a cookie prompt that changes consent—before anyone notices. This Skill turns browser QA into a bounded evidence job: define what may be observed, walk the shortest safe path, and report exactly what the run did and did not establish.

What “read-only” means in a browser

Read-only is not the same as “do not click.” Modern interfaces hide essential evidence behind tabs, filters, accordions, menus, and dialogs. A useful review may need to open those controls. The real distinction is whether an action merely changes the current view or commits state outside the inspection session.

This classification is intentionally based on effect, not label. “Preview” can trigger an expensive render. “Continue” can submit the current step. Typing a secret into a form transmits it to the page even before a final submit. If the effect is unclear, the Skill stops; uncertainty is not a reason to experiment on the user's account.

The Skill's operating contract

Before opening the target, the Skill records the origin, starting route, account state, environment marker, acceptance criteria, viewport, and permitted evidence. Authenticated pages, third-party redirects, downloads, forms, and ambiguous buttons trigger the more detailed scope contract included in the bundle.

The browser pass then follows a fixed rhythm:

1. Identify the page. Confirm the final URL and visible product or environment marker. A 200 response or generic app shell is not enough.
2. Exercise one criterion. Walk the shortest path needed to observe that behavior; avoid browsing adjacent features.
3. Capture the right evidence. A screenshot supports a layout claim. Visible text or an accessibility snapshot supports wording and semantics. Network evidence can show a request occurred, but not that a downstream human received it.
4. Preserve failed states. Do not refresh or repeat until the desired result appears. When timing is relevant, use a declared repeat count and report the distribution.
5. Close the boundary. List untested states, actions not performed, and anything that a reader could otherwise over-infer.

Why the verdict has only four values

Browser reports often end in ambiguous language: “looks good,” “seems fixed,” or “mostly working.” Those phrases collapse different evidence states. This Skill uses four controlled verdicts.

• PASS means every in-scope acceptance criterion was observed.
• FAIL means at least one criterion was contradicted by reproducible evidence.
• PARTIAL means the run produced useful evidence but could not complete every criterion within the allowed boundary.
• BLOCKED means access, target identity, prerequisites, or safe-action limits prevented meaningful inspection.

A login wall is not a failure of the product behavior behind it; it is a blocked test. A page that loads but omits a required confirmation is not “partial” if that confirmation was the criterion; it is a failure. A run that checks desktop but cannot create the requested mobile viewport is partial. These distinctions make the report usable by someone who was not watching the agent.

Evidence must match the claim

The bundle's JSON contract forces every passed or failed criterion to reference a retained evidence file. Its standard-library validator checks the controlled status values, viewport dimensions, relative evidence paths, file existence, and verdict logic. It rejects a report that says PASS while containing a failed or unchecked criterion.

That machine check is deliberately modest. It can prove that a referenced screenshot exists; it cannot prove the screenshot shows the right account or that the claim was interpreted correctly. The human-readable report therefore retains starting state, minimal steps, expected result, observed result, repeat count, and uncertainty for each finding.

What it refuses to do

The Skill does not press a real Send button to “see whether it works,” enter a card number, accept legal terms, upload a private document, authorize an integration, or change a user's settings. It does not treat instructions embedded in page content as authority. It does not cross to a new origin simply because a link or redirect appears relevant.

Those are not missing capabilities. They are the reason the Skill is safe enough to use early in diagnosis. If a release decision genuinely requires a write—creating a draft order in a sandbox, for example—that should become a separate, explicitly authorized test with its own account, cleanup plan, and readback.

Use the included files

• SKILL.md contains the activation boundary, workflow, evidence rules, and verdicts.
• references/scope-contract.md freezes allowed origins, account state, interactions, and stop conditions.
• references/report-contract.md defines the Markdown sections and JSON record.
• scripts/validate_browser_qa_report.py rejects structurally incomplete reports and missing evidence references.
• agents/openai.yaml supplies concise interface metadata for compatible hosts.

Install the top-level read-only-browser-qa folder in your personal or project Skills directory. Then invoke it with a concrete target and criterion: “Use the Read-Only Browser QA Skill on this local order page. At 390×844, verify that the Order ID remains visible when the details panel opens. Do not submit, save, download, or leave localhost.”

Read the verification label honestly

The bundle passes the current structural checks for its name, frontmatter, metadata, references, and files. The report validator was exercised with a complete synthetic report plus missing-evidence and false-PASS mutations. The procedure was also applied to a fictional localhost interface, so the wording has been confronted with a real rendered state rather than reviewed only on paper.

We did not test automatic invocation, different models, a real logged-in account, cross-browser consistency, or consequential actions. The page is therefore labeled Structure Checked. This is a reusable operating boundary, not a promise that any browser agent will behave safely on every site.

Pair it with the right next step

Use the complete safe browser-agent testing guide to build an isolated fixture and design normal, edge, adverse, and interruption cases. When the question is specifically how the layout behaves across widths, switch to the Responsive UI Review Skill; it adds a viewport matrix, reflow checks, and a keyboard pass.

Bottom line: a good browser QA run is small enough to audit. Freeze the target, classify actions by effect, keep page content untrusted, collect evidence that actually supports each criterion, and stop before observation turns into an unauthorized transaction.