Visual Playtest
Use the applicable browser-control skill. Match the effort to the request: a
static page review is not a full product certification.
Choose the scope
Identify the few states that can materially change the result: named pages,
viewport ranges, theme, scroll position, navigation state, and persistent or
fixed UI. Reproduce the user's reported combination before exploring adjacent
states.
Load additional guidance only when it is in scope:
- Read references/app-interactions.md for
functional QA of controls, dialogs, panels, keyboard flows, or app workspaces.
- Read references/media-workflows.md for audio,
video, image-generation, asset-management, download, or media trust-state QA.
- Read neither reference for an ordinary static or content-site visual review.
Do not load both references automatically.
Core pass
- Open the target at one representative desktop width and one narrow mobile
width. Add tablet or unusual wide states only when the design or report makes
them material.
- Capture the reported state before changing anything. When verifying a fix,
compare the same URL, viewport, theme, scroll position, and persistent UI.
- Inspect the top, middle, and bottom of the page for overlap, clipping,
overflow, broken wrapping, weak hierarchy, unreadable contrast, awkward
empty space, and fixed UI covering content.
- Exercise only controls that create a visually distinct state or belong to
the requested flow. A visual review does not require auditing every control.
- Use a fresh reload for final screenshots and console checks so stale state
is not mistaken for a current defect.
- Stop when the named issue and its closest responsive variants are resolved.
Do not expand into unrelated product QA without evidence or a user request.
Report
Lead with the visual outcome. List observed defects by severity with the
viewport/state, evidence, and smallest useful fix. Separate observed facts from
inference and unavailable states. Use a table only when several defects benefit
from comparison; otherwise keep the report short.
1---2name: visual-playtest3description: Visually inspect a local or deployed site/app in a real browser and report concrete layout, responsive, or design regressions. Use when asked to visually check UI changes, reproduce a screenshot issue, compare a page with a reference, or playtest representative visual states. Do not use for code-only review or open-ended design ideation.4---56# Visual Playtest78Use the applicable browser-control skill. Match the effort to the request: a9static page review is not a full product certification.1011## Choose the scope1213Identify the few states that can materially change the result: named pages,14viewport ranges, theme, scroll position, navigation state, and persistent or15fixed UI. Reproduce the user's reported combination before exploring adjacent16states.1718Load additional guidance only when it is in scope:1920- Read [references/app-interactions.md](references/app-interactions.md) for21 functional QA of controls, dialogs, panels, keyboard flows, or app workspaces.22- Read [references/media-workflows.md](references/media-workflows.md) for audio,23 video, image-generation, asset-management, download, or media trust-state QA.24- Read neither reference for an ordinary static or content-site visual review.2526Do not load both references automatically.2728## Core pass29301. Open the target at one representative desktop width and one narrow mobile31 width. Add tablet or unusual wide states only when the design or report makes32 them material.332. Capture the reported state before changing anything. When verifying a fix,34 compare the same URL, viewport, theme, scroll position, and persistent UI.353. Inspect the top, middle, and bottom of the page for overlap, clipping,36 overflow, broken wrapping, weak hierarchy, unreadable contrast, awkward37 empty space, and fixed UI covering content.384. Exercise only controls that create a visually distinct state or belong to39 the requested flow. A visual review does not require auditing every control.405. Use a fresh reload for final screenshots and console checks so stale state41 is not mistaken for a current defect.426. Stop when the named issue and its closest responsive variants are resolved.43 Do not expand into unrelated product QA without evidence or a user request.4445## Report4647Lead with the visual outcome. List observed defects by severity with the48viewport/state, evidence, and smallest useful fix. Separate observed facts from49inference and unavailable states. Use a table only when several defects benefit50from comparison; otherwise keep the report short.
swyxio