validating-ui

Validates frontend UI changes in the browser against design references and runtime health checks.

3|Updated Apr 2, 2026
One-click install
npx skills add https://github.com/OktayCopurlu/ai-shared --skill validating-ui-oktaycopurlu
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: validating-ui
Source: https://github.com/OktayCopurlu/ai-shared/tree/main/.github/workflows/skills/validating-ui
Command: npx skills add https://github.com/OktayCopurlu/ai-shared --skill validating-ui-oktaycopurlu

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? After implementing frontend changes, it is easy to ship visual regressions, viewport-specific layout bugs, or design drift that unit tests never catch. This Skill provides a structured browser-level validation methodology so every UI change is verified before a PR is created. ## Core Features & Use Cases - Six-stage validation checklist: Covers page load, visual correctness at desktop and mobile viewports, Figma design comparison with token-level fidelity checks, runtime health, regression on adjacent UI, and analytics tracking verification. - Recovery and experiment protocols: Defines concrete recovery steps when the target UI is unreachable (broken localhost, missing preview, hidden sections) and override procedures for feature flags, experiments, and A/B tests. - Structured verdict format: Produces a Pass / Pass with notes / Fail verdict with evidence, including a checklist of what was tested and what was not verified. - Use Case: After finishing a ticket that changes a product page component, run this Skill to navigate the page with playwright-cli, compare computed styles against the Figma node at both 1280px and 375px viewports, check console and network health, and produce an evidence-backed verdict before opening the PR. ## Quick Start Validate the UI changes from my current branch in the browser at desktop and mobile viewports and give me a pass or fail verdict with evidence.

Frequently Asked Questions about validating-ui

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I validate frontend UI changes before creating a PR?▼

Run a structured browser validation after lint, type, and test gates pass: check page load and console errors, test desktop (≥1280px) and mobile (375px) viewports, compare against Figma if referenced, verify runtime health, and check regression on adjacent UI. Finish with a Pass, Pass with notes, or Fail verdict backed by evidence.

How to compare implemented UI against a Figma design?▼

Perform a token-level fidelity check: read computed styles in the browser (spacing, sizing, typography, color, borders) and compare each value against the Figma node properties. Screenshots and side-by-side visual checks are supporting evidence only, not the primary verification method.

What should I do when localhost will not open during UI validation?▼

Do not mark validation as blocked after one failed attempt. Confirm the dev server command and port, try the PR preview URL, run the PR branch locally, check route and data prerequisites, and try alternate render surfaces like Storybook or a deep link before reporting blocked.

How do I test UI behind a feature flag or A/B experiment?▼

Identify the exact flag or experiment key and look for supported override mechanisms such as URL parameters, cookies, localStorage, or SDK debug APIs. Apply only confirmed overrides, reload, and verify the active variant through rendered UI or tracking payloads rather than the stored value alone.

Does browser UI validation replace accessibility audits?▼

No. UI validation covers visual correctness, runtime health, and regression, but accessibility findings are intentionally excluded. Load a dedicated accessibility audit skill separately so a11y issues are tracked in their own process.

Why do passing unit tests not guarantee correct UI?▼

Tests verify logic, not pixels. Visual regressions, layout shifts across viewports, hydration warnings, and styling drift do not appear in unit test results, which is why browser-level validation at multiple viewports is required.