---
name: responsive-visual-qa
description: Inspect a running web interface across screen sizes, supported themes and interactive states; produce a reproducible visual QA report with screenshots and prioritized findings. Use for responsive layout reviews and before/after visual verification.
---

# Responsive visual QA

Turn observable layout problems into reproducible findings. Work with the user's URL, local project and requested journeys; use the browser automation available in the environment. The skill does not bundle a browser or automatically scan a URL.

## Scope and setup

Read repository instructions when source is available. Reuse its start command and existing test tooling. Establish the target routes and key journey from the request. Start with representative narrow and wide screens (for example 390×844 and 1440×900), then inspect a tablet width and both sides of any breakpoint implicated by a finding. Treat these sizes as coverage samples, not device certification.

Discover the app's actual theme and language controls. Exercise supported variants without fabricating an alternate theme or injecting unrelated styles. Use authorized test data; do not submit purchases, send messages or modify live records just to inspect a state.

## Inspect and collect evidence

Wait for the page's meaningful ready state, fonts and relevant images. Do not wait indefinitely for network idle on a streaming app. Record any loading failure. Respect reduced motion when requested and retain a separate check of motion where it is in scope.

Inspect both viewport and full-page captures, then interact: open navigation, expand content, focus fields, show validation and dialogs when relevant. Check text wrapping, overlapping elements, clipped actions, sticky headers, overlays, horizontal overflow and focus visibility. Use long but realistic content when fixtures can be changed safely.

DOM geometry can locate a candidate overflow; confirm it visually. A deliberate scrollable table, offscreen menu or shadow is not automatically a defect. A screenshot difference alone is not a regression: compare the same content, viewport, theme, scroll position and UI state, and separate rendering jitter from user impact.

For every confirmed issue, record route, viewport, theme, state, reproduction, expected versus observed behavior, screenshot path and impact. If source is available, identify the responsible layout rule only after inspecting it. Follow [references/report.md](references/report.md) for the deliverable.

## Report or fix

A review request produces findings. If the user asks for fixes, make the smallest relevant changes and repeat the failing scenario plus a nearby width/state that might regress. Capture before and after under identical conditions. Preserve the user's visual direction; do not redesign the page during QA.

Report what was inspected, what failed and what could not be checked. Keep screenshot capture failures and inaccessible routes visible as coverage gaps. An automated overflow check or passing audit is not evidence that every layout is correct. Emulated viewports are not physical-device tests.