Measure UI

Screenshots produce confident wrong conclusions, both false passes and false failures. Every claim about layout, fidelity, hover, focus, overflow or animation rests on a measurement: computed styles, rects and hit tests read in a live browser, asserted as numbers.

Pick the branch

• Fidelity: you have a design reference (a mockup, a design file, or your own earlier build) and an implementation, and need to prove they match or find why they differ.
• Interaction states: a dropdown, overlay, drawer or CSS animation looks broken, or you are about to claim an interactive change works.
• Visual parity: a styling-system migration or a reimplementation must not move a pixel; a frozen screenshot baseline and a zero image diff decide.

Matching a design usually needs both: fidelity for the static layout, then interaction states for every menu and animation.

Who does what

Proving a UI claim takes three skills, each owning one part:

• verify-this frames the claim and gives the verdict (VERIFIED, NOT VERIFIED or INCONCLUSIVE).
• This skill sets the evidence rules for anything visual or interactive: what to measure, how to actuate, what counts as proof.
• A driver only runs the browser: call the Skill tool with "control-ui" for a local browser or Electron app, or "orca" inside the Orca IDE.