/frontend-design

name: frontend-design
description: "Frontend design skill fused from Impeccable + custom extensions. Covers design philosophy, anti-AI-slop patterns, typography, color (OKLCH), spatial design, motion, interaction, responsive, UX writing, state management, engineering, and 4 style variants. Includes 20 command skills for audit/critique/polish/animate/etc."
license: "Apache 2.0 (Impeccable) + MIT (custom extensions)"
user-invocable: true
disable-model-invocation: false

Frontend Design (Impeccable Fusion Edition)

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. It fuses [Impeccable](https://github.com/pbakaus/impeccable) design philosophy with extended knowledge on state management, engineering, and design style systems.

---

Context Gathering Protocol

Design skills produce generic output without project context. You MUST have confirmed design context before doing any design work.

**Required context** — every design skill needs at minimum:

• **Target audience**: Who uses this product and in what context?
• **Use cases**: What jobs are they trying to get done?
• **Brand personality/tone**: How should the interface feel?

**Gathering order:** 1. **Check current instructions (instant)**: If your loaded instructions already contain a **Design Context** section, proceed immediately. 2. **Check .impeccable.md (fast)**: If not in instructions, read `.impeccable.md` from the project root. If it exists and contains the required context, proceed. 3. **Gather it now (REQUIRED)**: If neither source has context, ask the user for the three items above before doing anything else. Do NOT skip this step and do NOT infer context from the codebase instead. Once gathered, offer to save it to `.impeccable.md` at the project root so future sessions skip straight to step 2. (The detailed intake playbook lives at `impeccable/teach-impeccable/SKILL.md`.)

---

Design Direction

Commit to a BOLD aesthetic direction:

• **Purpose**: What problem does this interface solve? Who uses it?
• **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc.
• **Constraints**: Technical requirements (framework, performance, accessibility).
• **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?

**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work — the key is intentionality, not intensity.

---

Frontend Aesthetics Guidelines

Typography

> *Consult [typography reference](reference/typography.md) for scales, pairing, and loading strategies.*

Choose fonts that are beautiful, unique, and interesting. Pair a distinctive display font with a refined body font.

**DO**: Use a modular type scale with fluid sizing (clamp) for display text; fixed rem scales for app UIs **DO**: Vary font weights and sizes to create clear visual hierarchy **DON'T**: Use overused fonts — Inter, Roboto, Arial, Open Sans, system defaults **DON'T**: Use monospace typography as lazy shorthand for "technical/developer" vibes **DON'T**: Put large icons with rounded corners above every heading — they rarely add value

Color & Theme

> *Consult [color reference](reference/color-and-contrast.md) for OKLCH, palettes, and dark mode.*

Commit to a cohesive palette. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.

**DO**: Use OKLCH (not HSL) for perceptually uniform, maintainable palettes **DO**: Tint your neutrals toward your brand hue — even a subtle hint creates subconscious cohesion **DON'T**: Use gray text on colored backgrounds — use a shade of the background color instead **DON'T**: Use pure black (#000) or pure white (#fff) — always tint **DON'T**: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds **DON'T**: Use gradient text for "impact" — it's decorative rather than meaningful **DON'T**: Default to dark mode with glowing accents

Layout & Space

> *Consult [spatial reference](reference/spatial-design.md) for grids, rhythm, and container queries.*

**DO**: Create visual rhythm through varied spacing — tight groupings, generous separations **DO**: Use fluid spacing with clamp() that breathes on larger screens **DO**: Use asymmetry and unexpected compositions; break the grid intentionally **DON'T**: Wrap everything in cards — not everything needs a container **DON'T**: Nest cards inside cards — flatten the hierarchy **DON'T**: Use identical card grids — same-sized cards with icon + heading + text, repeated endlessly **DON'T**: Center everything — left-aligned text with asymmetric layouts feels more designed **DON'T**: Use the same spacing everywhere — without rhythm, layouts feel monotonous

Visual Details

**DO**: Use intentional, purposeful decorative elements that reinforce brand **DON'T**: Use glassmorphism everywhere — blur effects used decoratively rather than purposefully **DON'T**: Use rounded elements with thick colored border on one side — a lazy accent **DON'T**: Use sparklines as decoration — tiny charts that convey nothing meaningful **DON'T**: Use rounded rectangles with generic drop shadows — safe, forgettable **DON'T**: Use modals unless there's truly no better alternative

Motion

> *Consult [motion reference](reference/motion-design.md) for timing, easing, and reduced motion.*

**DO**: Use motion to convey state changes — entrances, exits, feedback **DO**: Use exponential easing (ease-out-quart/quint/expo) for natural deceleration **DO**: For height animations, use grid-template-rows transitions **DON'T**: Animate layout properties (width, height, padding, margin) — use transform and opacity only **DON'T**: Use bounce or elastic easing — they feel dated and tacky

Inte