refactor-ui — diagnose-then-edit refactoring for existing UI

This skill is a process, not a design system. "Refactor this UI" without context usually produces generic cleanup that misses the point. The questions this skill asks are about meaning — what the UI is for, what matters, what's locked. Aesthetic direction is a single neutral question, not the main event.

Inputs

The user gives you one or more of:

• an image of a UI (screenshot, mock, Figma export)
• a component file path (or a directory of components)
• both — preferred, because diagnosis is sharper with the image and edits require the code

If the input is image-only and the user wants edits, ask where the code lives before Phase 3. If the user explicitly wants code written from an image with no existing source, say so and proceed — but that's closer to frontend-design than a refactor.

The four phases

Run in order. Don't skip, don't merge them into a wall of text. Each phase produces a distinct visible step for the user.

Phase 1 — Observe (silent)