visual-verification-workflowlisted

## Purpose Reading a diff and believing it's correct is not the same as confirming it's correct. This skill is the concrete procedure for actually looking at a UI change running in a browser before reporting the task as finished — it's what backs the "never done without visual verification" rule. ## When to use it After any change that touches rendered UI: a new component, a style change, a layout change, new interactive behavior, or a fix to a visual bug. Skip it only for changes with no rendered surface at all (e.g. a pure backend/API change with no UI-visible effect). ## Steps 1. **Get it running.** Start (or reuse) the dev server / preview environment for the app. If no browser or preview tool is available in the current environment, stop here and say so explicitly in your report — do not report the change as verified. 2. **Check the golden path.** Navigate to the actual screen/component affected and exercise the primary interaction the change was meant to support — click the button, submit the form, open the panel — not just a glance at the initial render. Confirm it behaves as intended, not merely that it renders without crashing. 3. **Check at least one edge case.** Pick whichever is most relevant to the change: - **Empty state** — what does it look like with zero data/items? - **Long content** — what happens with an unusually long string, a long list, or a large number where the design assumed something shorter? - **Mobile width** — resize (or use devi