micro-interactions

Micro-interaction audit

Target: $ARGUMENTS (if empty, ask for the URL, and ask which controls matter most — a form, a checkout button, a table row, a toggle).

What this skill can and cannot do

inspect_localhost_ui is read-only. It cannot hover, click, focus, type or scroll, and it returns a single still frame of the default state. You will never see a hover state, a focus ring or a pressed button in a capture you take unaided. Do not write a report that implies you did.

Verification therefore has exactly two routes, and every finding must name which one it came from:

1. Read the state classes out of simplifiedDOM. A state that is styled is declared in the markup: hover:, active:, focus:, focus-visible:, focus-within:, disabled:, aria-disabled:, data-[state=...]:, group-hover:, peer-checked:, aria-* attributes, and the disabled attribute itself. If a variant is absent from the class list, the state does not exist — that is a real finding, provable without seeing it. Plain-CSS projects declare the same thing as :hover, :active, :focus-visible and :disabled rules; find the selector in the stylesheet by the class you read.

2. Ask the user to render the state and hold it, then capture. This is the only way to see a state. Be specific and batch the requests so they do it once:

   Hover the primary CTA and keep the pointer on it, then tell me and I will capture. After that: press Tab until the focus ring is on the email input and leave it there. Then submit the form empty so the error state renders.

   If a state is reachable by other means, prefer that — it is repeatable and you can capture it yourself without waiting: a Storybook story per state, a ?state=loading dev query parameter, a temporary disabled prop, or a route that renders the error page directly. Ask for one of these when a state takes several steps to reach.

Behaviour in time — how fast a control acknowledges a click, whether an update is optimistic, whether validation fires per keystroke — is not observable at all from a still frame. Read it from the source: event handlers, onChange versus onBlur, isPending/isLoading flags, mutation callbacks. Report it as a code-read finding, not a visual one.