impeccable

# Impeccable > This adapted file has been modified. See `THIRD_PARTY_NOTICES.md` for the applicable license notice. Use this skill for frontend design and UX work. Applicable tasks include: - designing a new interface; - shaping a feature before implementation; - reviewing an existing UI; - improving visual hierarchy; - fixing layout and spacing; - improving responsive behavior; - accessibility review; - hardening empty, loading, error, and edge states; - reducing visual noise; - adding personality without sacrificing usability; - final UI polish. The product brief and existing project design decisions outrank generic design preferences. ## First classify the task ### Shape Use when behavior, hierarchy, navigation, layout, or interaction still needs to be decided before implementation. ### Critique Use when reviewing an existing interface and identifying UX or visual problems. ### Audit Use for technical interface quality: - accessibility; - responsiveness; - semantics; - keyboard interaction; - touch targets; - overflow; - performance-related UI problems. ### Polish Use when the interface is already correct and needs a bounded final refinement. ### Harden Use when the main design exists but real product states are incomplete. ### Adapt Use when the interface needs to work well across viewport sizes, input methods, themes, or device classes. These modes may be combined when the task genuinely spans them. ## Process ### 1. Load product context Before changing the UI, understand: - what the product does; - who uses this surface; - the user's primary task; - existing product requirements; - current design conventions; - accepted visual direction; - relevant constraints. Do not invent a new design system when an established one already exists. ### 2. Inspect the current interface When refining existing work, inspect the real implementation or rendered UI. Look at: - hierarchy; - layout; - spacing; - typography; - component consistency; - states; - interaction; - responsiveness; - accessibility; - visual noise; - unused space; - density. Preserve intentional existing identity unless the user asked for a redesign. ### 3. Define the surface's job Ask what successful use looks like. Common modes: - **Operate:** complete a task efficiently. - **Read:** understand information. - **Persuade:** decide and act. - **Experience:** explore or appreciate the content itself. Optimize the surface for that job. Do not apply landing-page aesthetics to a dense admin tool merely because they look more impressive. ### 4. Establish hierarchy Make clear: - what the user should notice first; - what action is primary; - what information is secondary; - what can be visually quieter; - which elements belong together. Use layout before decoration. Use spacing, typography, alignment, grouping, and contrast deliberately. ### 5. Design real states Account for applicable states: - loading; - empty; - unavailable; - disabled; - selected; - active; - success; - error; - partial data; - long content; - overflow; - destructive confirmation; - permission restrictions. Do not leave fake controls or dead interactions that imply unsupported behavior. ### 6. Accessibility Use semantic elements and native controls where practical. Check: - keyboard access; - visible focus; - labels; - form errors; - heading order; - color contrast; - touch target size; - motion sensitivity; - information not conveyed by color alone. ### 7. Responsive behavior Do not merely shrink the desktop layout. Decide what should: - wrap; - stack; - scroll; - collapse; - remain fixed; - change priority; - disappear only when genuinely nonessential. Protect important actions and readable content at smaller sizes. ### 8. Refine visual craft Avoid default AI-generated UI patterns unless they genuinely fit the product. Watch for: - excessive cards; - unnecessary gradients; - arbitrary rounded containers; - giant empty hero space; - decorative glow; - excessive badges; - repeated icon-label patterns; - inconsistent spacing; - generic dashboard layouts copied without regard to the workflow. A simple interface can still be deliberate. ### 9. Verify in bounded passes For UI tasks with explicit viewport, theme, or state requirements, plan the relevant checks before reviewing. Confirm the needed states are reachable with existing data or fixtures; use focused tests or isolated fixtures for gaps when justified. Record each requirement as visually inspected, automated, unavailable, or skipped. Automated checks do not replace visual inspection. Keep this proportional to the task. When implementation tools allow rendered inspection: 1. build the complete intended change; 2. inspect relevant desktop and smaller-screen states; 3. collect problems into one batch; 4. fix the batch; 5. perform one final confirmation pass. Do not enter an endless polish loop. ## Refinement vs redesign ### Refinement Preserve: - identity; - content; - behavior; - information architecture outside scope. Improve execution. ### Redesign Preserve product truth and functional requirements, but allow the visual system or information architecture to change. Do not accidentally redesign when the user asked for polish. ## Rules - The brief wins. - Product usability outranks decoration. - Design the interaction before styling when behavior is unclear. - Prefer deliberate hierarchy over visual busyness. - Reuse existing components and tokens when suitable. - Do not introduce new dependencies for trivial visual problems. - Avoid unsupported factual or marketing copy. - Do not sacrifice accessibility for aesthetics. - Do not keep polishing after the important problems are resolved. ## Completion UI work is complete when: - the primary task is obvious; - hierarchy is intentional; - relevant states are handled; - keyboard and semantic basics are sound; - important viewport sizes remain usable; - styling is internally consistent; - the rendered result has been inspected when possible; - no major design problem remains within the requested scope.