Beautify Frontend

Purpose

Use this skill to turn a working frontend into a more polished, coherent, production-quality interface without changing the product's intent or breaking existing behavior.

Core Workflow

1. Inspect the current UI structure, styles, routes, and component boundaries before editing.
2. Identify the product type and audience: dashboard, SaaS tool, content site, creative page, ecommerce, game, or utility.
3. Preserve existing user flows, state, data contracts, accessibility intent, and tests unless the user explicitly asks for behavior changes.
4. Improve the design system first: spacing scale, typography, color roles, surface hierarchy, controls, icons, empty/loading/error states, and responsive rules.
5. Implement the smallest coherent set of changes that makes the interface feel intentional across desktop and mobile.
6. Run the project checks available in the repository, then inspect the rendered UI when a dev server or static preview is available.

Design Priorities

Prioritize clarity over decoration. Make important actions obvious, secondary information scannable, and repeated workflows efficient.

Use visual hierarchy deliberately:

• Establish one primary focal point per screen or section.
• Keep headings sized to their container; avoid hero-scale type inside panels, cards, sidebars, and compact tools.
• Use spacing, alignment, and contrast before adding borders or shadows.
• Prefer consistent component variants over one-off styling.

Use color with restraint:

• Assign semantic roles for background, surface, text, muted text, border, primary action, danger, success, and warning.
• Avoid one-note palettes dominated by a single hue family.
• Avoid excessive purple/blue gradients, beige/tan themes, dark slate themes, and orange/brown palettes unless the existing brand requires them.
• Check CSS colors before finishing; revise if the page reads as visually monotonous.

Use assets and icons appropriately:

• Use the project's existing icon library when available; prefer lucide icons if it is already installed.
• Use bitmap or real product/place/person imagery for websites where visuals matter.
• Avoid decorative orbs, bokeh blobs, generic abstract SVG hero art, and stock-like dark blurred backgrounds.

Layout Rules

Use stable dimensions for fixed-format UI:

• Boards, grids, toolbar buttons, counters, tiles, and controls need explicit sizing, aspect ratios, or responsive constraints.
• Hover states, icons, dynamic labels, and loading text must not shift the layout.

Keep layout architecture clean:

• Do not put UI cards inside other cards.
• Do not make every page section a floating card.
• Use cards for repeated items, modals, and genuinely framed tools.
• Use full-width bands or unframed constrained layouts for major page sections.

Make responsive behavior real:

• Test narrow mobile, tablet-ish, and desktop widths when possible.
• Ensure text does not overflow buttons, tabs, cards, panels, or nav items.
• Do not scale font size directly with viewport width.
• Keep letter spacing at 0 unless matching an existing design system.

Interaction And Accessibility

Use familiar controls for familiar jobs:

• Icon buttons for tools and compact commands, with accessible labels or tooltips.
• Segmented controls for modes.
• Toggles or checkboxes for binary settings.
• Sliders, steppers, or numeric inputs for numeric values.
• Menus for option sets.
• Tabs for switching views.

Check interactive states:

• Hover, focus-visible, active, selected, disabled, loading, empty, and error states should be visually distinct.
• Keyboard focus must remain visible.
• Contrast must be sufficient for body text, muted labels, borders that carry meaning, and disabled states.

Frontend Implementation Guidance

Follow the repository's existing framework, file structure, styling method, and component conventions.

When editing React or component-based code:

• Keep state and data flow unchanged unless visual behavior requires a small local adjustment.
• Extract reusable UI pieces only when it reduces meaningful duplication or matches local patterns.
• Avoid broad refactors during visual polish.
• Prefer CSS classes, tokens, and component variants over inline one-offs when the codebase supports them.

When editing CSS:

• Consolidate repeated values into existing tokens or local custom properties when appropriate.
• Remove obsolete style rules only after confirming they are unused by the edited UI.
• Keep animations subtle, purposeful, and respectful of prefers-reduced-motion when motion is substantial.

Verification Checklist

Before finishing, verify:

• The app builds or the relevant checks pass, when available.
• The primary screen renders without broken assets or console-visible layout failures.
• Desktop and mobile layouts are coherent.
• No text overlaps or escapes its container.
• Primary actions, navigation, form fields, and dialogs remain usable.
• Visual changes preserve existing functionality.

If verification cannot be run, state what was not run and why.