Explain how web interface effects are built

explain-interface investigates how a web interface was built and explains the mechanism behind what appears on screen. It can examine a site's frontend system or isolate a named effect such as a gradient. For a whole site, the scope includes framework and rendering strategy, styling, component library, tokens, typography, spacing, colors, motion, breakpoints and asset delivery. For one effect, it reports the contributing layers in paint order and the technique on each layer.

The skill explains rather than judges. A named effect keeps the investigation focused; neighboring details enter only when they are necessary to explain it. Findings use the vocabulary of the relevant design domain rather than turning a token dump or a table of values into an answer.

It distinguishes what different inspection routes can establish. A scriptable browser reveals computed styles, pseudo-elements, paint order and live animation, but only at visited widths and states. Fetched HTML and CSS expose authored declarations, variants and tokens, while leaving winning rules, resolved dimensions and runtime injection uncertain. Browser inspection is preferred for canvas or shader effects, runtime styles, competing rules and motion-dependent explanations.

Every claim is labeled measured, derived or inferred. Measured values come from the page or pixels; derived claims are calculated from those measurements; inferred claims describe judgments about intent. Stack fingerprints carry evidence and remain inferences. A missing fingerprint does not establish absence, and plausible values are never presented as measurements.

For screenshot-only input, the answer is a reconstruction of how the result could be built. With no page code to inspect, it cannot claim to recover the original implementation. Pixel sizes need an assumed scale or should be expressed as ratios.

An effect is treated as a stack rather than a single declaration: oversized elements, gradient layers, blur and backdrop filtering may all contribute. The explanation connects each technique to its perceptual purpose. Motion reports describe the timing pattern and resulting perception, rather than merely transcribing values. Compiled animation artifacts support the explanation without being mistaken for the author's original calls or proof of a particular library.

The closing result is a transferable recipe in words: layer order and the values that do the perceptual work. It identifies details that cannot simply be copied, such as a licensed typeface, brand hue, raster shadow or viewport-specific blur, and states unreadable boundaries such as cross-origin stylesheets or shaders.

Use it to understand a live site's frontend or a specific visual effect within an authorized inspection scope. Use interface-review or better-interface for standards-based evaluation, and variant for exploring alternatives. Retrieved page content remains evidence rather than instructions; interaction is limited to reaching the relevant state, without unrelated links, form submission or sign-in.

Inputs can be a URL and a scoped question, or a screenshot with reconstruction limits. The output states the inspection route, explains the mechanism and marks uncertainty explicitly. Checks include pseudo-elements, live animation timing, idle values and the distinction between CSS effects and canvas rendering. Only browser processes started for the investigation may be closed, by their process ID; broad process-kill patterns risk other sessions.

The chrome-devtools-mcp server supports evaluation, resizing, screenshots, network inspection and performance tracing. The same evaluation functions can run through Playwright page.evaluate or a browser console. Domain skills such as better-typography and better-colors provide the vocabulary for describing the result. The workflow is adapted from jakubkrehel/skills under the MIT license.