Visual Acceptance Check

Design-Fidelity Acceptance Problems

Visual acceptance often stalls at “looks close enough”: spacing, corner radius, shadow, type hierarchy, and missing components are hard to audit item by item. Copy differences can also be mixed into confirmed product requirements, leading to inconsistent conclusions among developers, designers, and QA.

How the Skill Works

The skill takes a design tool link and development screenshots as input, then runs fidelity checks using 24 VA-* checkpoints.

• Design baseline: It pulls DSL from Figma, MasterGo, Pixso, and similar links, producing design-baseline.json with frame size, tokens, components, and icons.
• Viewport alignment: The development screenshot width should stay within 2% of the design frame; otherwise only layout-level checks are valid, and px-level items are marked untested.
• Capture and login: For H5 pages, it prefers production URLs, mobile user-agent emulation, and frame-width capture. Login walls are treated as blocked_login and are not scored.
• Checkpoint audit: Checks are layered into L1 layout, L2 tokens, and L3 styles. Each fail item requires design DSL evidence, an actual screenshot or CDP selector, and bbox_px.
• Report output: It generates a 24-line ledger, an HTML report, cropped difference images, and side-by-side design-link and development-page views.

Boundaries and Notes

This skill is suited for frontend visual acceptance when a design link, development screenshots, or a login URL is available. If only screenshots are uploaded without design DSL, many checks may become untested. Rechecks cannot override verdicts based on “looks close” or conversational pressure; copy changes should be separated into observations, confirmed requirements, and fail items.