Design Frontend Dev

Impeccable

Designs and reviews production-grade frontend interfaces with strong UX, visual hierarchy, accessibility, responsive behavior, and anti-slop discipline.

This is the clean Companion edition derived from pbakaus/impeccable under Apache-2.0. It keeps the design reasoning and review logic, but intentionally excludes the upstream CLI, hooks, live browser mode, install flow, site, extension, marketing material, and bundled scripts.

Protected Invariants

• Agent-only skill: do not require npx, bundled scripts, hooks, live mode, browser injection, extension APIs, or a product website.
• No commercial calls to action, install prompts, update checks, telemetry, or external service dependency.
• Keep SKILL.md compact and load detailed reference files only when relevant.
• Respect the host agent's higher-priority rules. When used from another review skill, that owner skill's safety rules win.
• For code-review use, stay read-only unless the user explicitly asked for implementation.

Setup

Before design or review work:

1. Gather project context from existing files when present: PRODUCT.md, DESIGN.md, README, design-system docs, tokens, CSS/theme files, component libraries, and representative pages/components.
2. Classify the surface:
   • brand: marketing, landing, campaign, portfolio, long-form content, or any surface where design is the product. Read reference/brand.md.
   • product: app UI, admin, dashboard, settings, tools, authenticated surfaces, or any surface where design serves the task. Read reference/product.md.
3. Read at least one concrete implementation file before making design claims. Prefer tokens, CSS, theme config, a shared component, and the changed or requested surface.
4. Pick only the reference files needed for the task.

If PRODUCT.md is missing, do not stop. Infer from available context, state the assumption, and continue. If DESIGN.md is missing, use visible conventions in code as the design source of truth.

Shared Design Laws

Color

• Use OKLCH when creating new color systems.
• Verify contrast: body text needs WCAG AA contrast, and muted text must still remain readable.
• Gray text on colored backgrounds often looks washed out. Use a darker shade of the background hue or transparent ink.
• Choose a color strategy before choosing colors:
  • Restrained: tinted neutrals plus one accent, best for most product UI.
  • Committed: one saturated color carries a large part of the surface.
  • Full palette: three or four roles used deliberately.
  • Drenched: the surface is the color, reserved for strong brand moments.
• Avoid category reflexes. If the palette can be guessed from the category alone, redesign the color direction.

Typography

• Cap body line length around 65-75ch.
• Use real hierarchy through scale and weight. Avoid flat type systems.
• Keep display heading letter spacing readable. Do not let letters touch.
• For product UI, prefer fixed rem scales over viewport-fluid headings.
• For brand UI, choose fonts from brand voice, not from generic "modern" or "premium" reflexes.

Layout

• Vary spacing for rhythm. Identical padding everywhere looks mechanical.
• Cards are not the default layout. Use them only when they are the right affordance.
• Never nest cards inside cards.
• Use stable responsive constraints for fixed-format UI: aspect ratios, min/max widths, grid tracks, and container-aware sizing.
• Check text overflow on mobile and tablet.

Motion

• Motion must explain state, continuity, hierarchy, or delight.
• Do not animate layout properties casually.
• Use ease-out quart/quint/expo curves. Avoid bounce and elastic for product UI.
• Provide reduced-motion alternatives.
• Content must be visible without waiting for animation triggers.

Interaction

• Interactive elements need default, hover, focus, active, disabled, loading, error, and success states when applicable.
• Never remove focus outlines without a visible replacement.
• Prefer native affordances for dialogs, popovers, buttons, inputs, labels, and forms.
• Validate forms at humane moments, usually blur or submit, not every keystroke unless the feedback is genuinely useful.

Absolute Bans

Refuse and redesign these patterns:

• Side-stripe borders as decoration on cards, lists, callouts, or alerts.
• Gradient text used as decoration.
• Decorative glassmorphism by default.
• The hero-metric template: big number, label, stats, gradient accent.
• Identical icon-card grids repeated as the main structure.
• Tiny uppercase eyebrow labels above every section.
• Numbered section markers unless the content is truly sequential.
• Text overflowing its container.
• Generic AI-looking palettes, excessive rounded cards, ghost-card border plus soft shadow, decorative stripe backgrounds, and sketchy SVG fallback illustrations.

Command Routing

Use these routes when the user names a mode or when intent clearly matches one:

For general frontend design work, read the matching register reference plus the two or three most relevant focused references.

Review Output

When reviewing, lead with actionable findings. For each issue include:

• severity: P0/P1/P2/P3
• location: file, component, route, or visible surface
• impact: what user or system outcome suffers
• evidence: code line, visual state, accessibility rule, responsive condition, or design-system mismatch
• fix direction: concrete next step, not a broad rewrite unless genuinely necessary

Avoid subjective taste notes unless they connect to user comprehension, task success, accessibility, brand fit, maintainability, or conversion.

Build Output

When implementing UI, produce real production code. Preserve the existing framework, component library, tokens, icon set, and routing conventions unless there is a concrete reason to change. Verify responsive behavior, focus states, loading/error/empty states, copy, and contrast before finishing.

Attribution

Derived from pbakaus/impeccable commit 3590bf9e37c84ecbc92f9c205ce1aebf2185a971, licensed Apache-2.0. This package is modified to remove CLI, hooks, live mode, install flow, website, extension, and commercial surface.