mockup-reviewlisted

# Mockup Review ## Purpose Review a mockup — markdown wireframe, linked screenshot, Figma URL — through one or more lenses (designer, accessibility, content) and emit a structured report. Catches problems before implementation when fixes are cheap. The same skill produces three different reports depending on `--lens`, so the lead can dispatch all three in parallel and merge the findings. ## Scope In: - One mockup reference: a path to a markdown wireframe, an image file, or a URL (Figma, screenshot, etc.). - A configurable lens — `designer`, `a11y`, `content`, or `all`. - A structured walk through: information hierarchy, interaction states, responsive behavior, copy slots, design-token usage. Out: - Live-prototype evaluation — that's `usability-review`. - Tool-driven a11y scanning — that's `a11y-scan` (mockup hasn't been built yet; no DOM to scan). - Code review of the implementation — that's `code-reviewer`. ## When to use - After a designer hands off a mockup and before frontend implementation begins. - Before an ADR locks in an interaction pattern that will be expensive to change later. - For component-library proposals — every new primitive gets a three-lens mockup review. - When stakeholders are debating two design directions — run the review on both and let the report inform the call. ## When NOT to use - For trivial visual tweaks (color swap, copy change) — overkill. - After implementation is already shipped — use `usability-review` on the live