/ui-regression

name: ui-regression
description: This skill should be used when the user asks to "verify UI changes", "test every screen and action", "run regression QA", "check a deployed UI", or "validate an extension release". Test known web and browser-extension workflows on localhost, staging, or production with action coverage, recovery, localization, accessibility, and real integration evidence. Use dogfood for open-ended bug discovery.

UI Regression

Verify that the requested UI works from entry to outcome. Cover the changed surface and its dependencies, without expanding a small edit into an unrelated product audit.

Use the browser tools available and permitted in the current environment. When using the agent-browser CLI, read [its skill](../agent-browser/SKILL.md) first. This workflow does not require a particular browser driver or local source access.

Scope and evidence

• Identify the target URL or extension build, environment, affected screens, actions, roles, locales, and dimensions. Inspect source and API contracts when available. For deployed-only QA, derive coverage from visible navigation and the requested workflows.
• Keep a compact coverage ledger in working notes or an existing artifact: screen/action, locale/account state, expected outcome, observed result, evidence, and pass/fail/blocked/not-applicable. Inventory before testing, then update as results arrive. A screenshot does not cover its buttons.
• Record the tested revision or deployed version when observable, browser, viewport, data source, and build mode. Mark unknown revisions explicitly. Compare visuals with matching content, state, and dimensions when a baseline exists.
• When asked to test every function, account for every inventoried action. Do not silently omit blocked checks or impose an arbitrary bug-count stopping point.

Real behavior and safe boundaries

• Exercise the actual UI, API, and persistence together against an authorized environment. A mocked UI test plus a direct endpoint test does not prove their integration.
• Use fixtures or an isolated test environment to reproduce loading, empty, failure, and recovery states. Do not inject failures into production. Keep fixture results separate from live integration and packaged-extension results. Never present simulated playback as real third-party playback.
• Use dedicated test accounts and test-mode resources for side effects. Existing task authorization still applies. QA alone does not authorize payments, emails, production mutations, or broader access. Prefer read-only deployed checks unless the requested workflow authorizes more.
• If credentials, browser capabilities, source access, or external dependencies block a check, record the exact boundary. Continue independent checks. Never bypass browser protections or substitute a mock to claim a pass.

Actions and recovery

• Within the authorized side-effect boundaries, click each affected button, link, menu item, toggle, and submit control. Verify its destination or persisted result. For new-tab links, inspect the new tab and redirects rather than judging the unchanged opener.
• Exercise applicable loading, empty, success, failure, and retry states. Check that busy controls prevent duplicate submissions, retries recover, and success follows confirmation. Deliberately failing a request should not leave the page stuck loading.
• For forms/preferences, test validation, save failure/retry, cancel and Escape, reopening, reload persistence, and preservation of unrelated values. Cover defaults and deselect-all where supported.
• For auth changes, cover signed-out, signed-in, expired-session, sign-out failure/retry, and account switching. Verify protected actions enforce access and account changes do not reuse another user's data.
• For changed credit, quota, or request behavior, verify ownership, fresh versus repeated actions, exhaustion, unlimited access, and duplicate submissions. Use an isolated test backend for failure injection and access-control probes. Do not enumerate or alter real users' records.
• Check relevant direct entry, refresh, back/forward navigation, interruption, and repeated actions. Stop retrying once the failure is understood, especially when requests can create side effects.

Language, layout, and feedback

• Test every in-scope screen in each supported locale, including transient labels and errors. Check language detection/fallback, localized destinations, natural copy, and mixed-language strings.
• Choose narrow, medium, and wide dimensions appropriate to the surface, including actual popup dimensions for extensions. Inspect wrapping, overflow, scroll access, and long labels.
• Compare screenshots for layout, spacing, typography, colors, brand assets, and media. Check media loading, status/type, dimensions, aspect ratio, and playback when affected.
• Exercise keyboard order, focus visibility, accessible names, dialog focus containment/restoration, Escape, and an automated accessibility scan when supported. Check pressed/loading/success/error feedback and reduced motion. Report scan limitations separately from manual checks.
• Inspect console and network errors, failed assets, redirects, and unexpected 4xx/5xx responses. Distinguish intentional failures from regressions. Verify the browser has loaded the current candidate before attributing stale UI to a code defect.

Browser extensions

Apply these checks only to affected extension behavior.

• Load the production build in a supported browser. Exercise the popup, background/service worker, content script, messaging, storage, and host permissions involved. A localhost component preview does not validate extension APIs or browser permissions.
• Check popup close/reopen, extension reload, service-worker restart, and account-change messages where relevant. Verify listeners, timers, and injected UI do not duplicate.
• For player UI, test in-site title navigation, video-element replacement, fullscreen entry/exit, dismiss