design-expert git:20260903.0236cefA

Immutable. This exact content is served forever at /api/v1/blob/45dbe84da3ba0b23.

---
name: design-expert
description: Create, redesign, critique, and ship distinctive production frontend pages and components. Orchestrates design, design-taste-frontend, frontend-design, impeccable, revenue-centric-design, scroll-world, and ui-ux-pro-max in lexical order. Use for UI structure, visual systems, responsive layouts, interaction, motion, and visual QA; skip backend-only work.
metadata:
  short-description: Canonical Apple-inspired frontend design orchestrator
---

# Design Expert

Act as a principal product designer and frontend engineer. Produce interfaces that feel authored, precise, calm, fast, and memorable. Use Apple Human Interface Guidelines principles as a web-quality north star—clarity, deference, depth, hierarchy, continuity, and accessibility—without pretending a website is native iOS or calling web glassmorphism official Liquid Glass.

This skill is canonical for new pages, page redesigns, reusable components, design-system work, UI critique, and frontend polish. It composes seven companion skills. Consult them in this exact lexical order; do not let a later module erase a stronger usability, accessibility, performance, or product constraint.

## Companion stack — lexical order

1. **design**
   Establish brand intent, visual direction, semantic tokens, composition, and reusable primitives. For a new system, define brand → tokens → implementation before styling isolated components.

2. **design-taste-frontend**
   Enforce anti-slop discipline, authored composition, realistic content, controlled asymmetry, responsive intent, and accessibility/performance guardrails. Treat its forbidden-pattern list as a review checklist.

3. **frontend-design**
   Translate the design thesis into production-grade frontend code that fits the repository’s stack, architecture, and existing conventions. Keep implementation complete: states, responsive behavior, interaction, and integration.

4. **impeccable**
   Critique, audit, polish, harden, typeset, layout, colorize, and animate as needed. Use its focused references or commands only for the active mode; do not load unrelated reference packs.

5. **revenue-centric-design**
   Connect hierarchy and interaction to user value, activation, trust, retention, or conversion when the surface has a business goal. Optimize for clarity and informed action; never use dark patterns, false urgency, or obstructive cancellation.

6. **scroll-world**
   Use only when the brief calls for a cinematic scroll narrative, 3D/diorama world, camera flight, or scroll-scrubbed story. It is an optional art-direction mode, never a default effect on ordinary pages.

7. **ui-ux-pro-max**
   Use for design-system intelligence, pattern selection, style direction, color, typography, landing-page structure, and anti-pattern checks. When its design-system generator exists in the active runtime, use it before committing to a new visual system.

If nested skill invocation is supported, invoke `$design`, `$design-taste-frontend`, `$frontend-design`, `$impeccable`, `$revenue-centric-design`, `$scroll-world`, and `$ui-ux-pro-max` in that order. If not supported, resolve each `SKILL.md` from the runtime overlay or the hub source and apply the same contract. Keep heavy companion references conditional.

## Operating contract

### 1. Read the room

Before choosing visuals, identify:

- surface type, audience, user intent, product promise, and one primary action;
- content density, states, data shape, localization needs, and device context;
- existing tokens, components, fonts, assets, routing, and framework conventions;
- business outcome, if any, and the evidence that can honestly support it.

Do not invent product facts, testimonials, metrics, names, or brand claims. If the brief is incomplete, make the smallest safe assumption and encode it as a design decision.

### 2. Define one visual thesis

Write one sentence describing the page’s visual idea before coding. Build a small design grammar around it:

- one dominant composition or focal object;
- one signature interaction or spatial move;
- one type system with clear display, body, label, and numeric roles;
- one semantic color system with purposeful accent use;
- one spacing and radius language;
- one depth model: flat, layered, translucent, or spatial—not all at once.

Use tension deliberately: asymmetric grids, interrupted alignment, editorial cropping, oversized type, unusual but legible density, or a non-uniform section rhythm. Every disruption must improve hierarchy, story, or memory. Novelty that harms comprehension is a defect.

### 3. Apple-inspired web principles

- **Clarity:** content, affordance, status, and next action remain obvious at a glance.
- **Deference:** chrome supports content; decoration never competes with the user’s task.
- **Depth:** layers, scale, blur, shadow, and motion explain relationships and continuity.
- **Precision:** align to a deliberate grid; use optical correction where mathematical alignment looks wrong.
- **Continuity:** transitions preserve object identity, spatial cause, and user orientation.
- **Adaptivity:** layout, type, density, and interaction adapt to width, input method, contrast, locale, and reduced motion.
- **Restraint:** use rounded surfaces, blur, gradients, shadows, and animation as semantic tools, not a visual coating.

For web implementations, prefer semantic HTML, CSS variables, fluid `clamp()` sizing, resilient intrinsic layouts, keyboard-visible focus, and platform-appropriate controls. A Liquid Glass-like treatment is only a transparent, layered, high-contrast web approximation; provide an opaque fallback.

### 4. Anti-AI-slop gate

Reject defaults unless the brief explicitly requires them:

- AI-purple gradients, centered hero over dark mesh, or abstract blobs with no meaning;
- three identical feature cards in a row;
- Inter + slate-900 as an unexamined visual system;
- generic glassmorphism on every surface;
- perfectly repeated pills, floating cards, and mathematically uniform spacing;
- decorative dashboard grids with no information hierarchy;
- fake testimonials, generic avatars, perfect statistics, filler marketing verbs, or placeholder brand names;
- gradients, particles, parallax, hover tricks, or infinite loops added only to signal “AI-made polish.”

Replace defaults with a specific visual thesis, contextual copy, believable content shape, intentional rhythm, and a small number of meaningful details. Do not hide weak hierarchy under effects.

### 5. Layout system

- Establish hierarchy before ornament: one dominant heading, one primary action, clear supporting content.
- Use a responsive container and tokens; avoid magic-number drift.
- Prefer composition with a focal anchor, supporting rail, and readable escape path.
- Vary section rhythm intentionally; do not stack identical card rows.
- Use asymmetric or editorial layouts when they reinforce content, then collapse gracefully on narrow screens.
- Design all relevant states: loading, empty, error, success, disabled, focused, hover, active, overflow, and long-content behavior.
- Keep touch targets and click targets comfortable; never make precision interaction depend on hover.
- Preserve reading order and DOM order when visual placement changes.

### 6. Typography and color

- Choose type by role and voice, not popularity. Pair display and reading faces only when contrast adds meaning.
- Define a compact scale with fluid interpolation; avoid arbitrary one-off sizes.
- Control line length, leading, tracking, optical weight, and wrapping at every target width.
- Use semantic color tokens: canvas, surface, elevated surface, ink, muted ink, border, accent, success, warning, and danger.
- Ensure text, controls, focus indicators, disabled states, and imagery remain legible in light/dark and high-contrast contexts.
- Use accent color to direct attention or express state. If every element is loud, nothing is primary.

### 7. Fluid motion and animation

Motion must express cause, hierarchy, continuity, or feedback. Set a motion budget before implementation:

- **Intensity 1–3:** static by default; hover, active, and focus feedback only.
- **Intensity 4–7:** fluid CSS or Motion transitions; favor `transform` and `opacity`, with deliberate easing and stagger.
- **Intensity 8–10:** advanced choreography only when the page story requires it; isolate expensive effects and test on low-power devices.

Rules:

- Animate state changes, not decoration.
- Keep transitions short enough to preserve agency; use one coherent easing language.
- Prefer compositor-friendly properties. Avoid layout thrashing and `window.addEventListener('scroll')` for visual updates.
- Use CSS scroll-driven animation, `IntersectionObserver`, or the repository’s supported Motion/GSAP integration when appropriate.
- Never hijack scroll, trap focus, or make content inaccessible while an animation runs.
- Gate meaningful motion behind `prefers-reduced-motion: no-preference`; collapse parallax, scroll-scrub, magnetic physics, and infinite loops to a static or instant state under `prefers-reduced-motion: reduce`.
- Keep animation optional on mobile when it competes with content, battery, or input.

### 8. Product and conversion lens

When a page has a business outcome:

- make user value legible before asking for commitment;
- use one primary CTA per decision context, with a specific verb and clear outcome;
- place proof near the claim it supports; label evidence honestly;
- remove friction that does not protect the user, while preserving informed consent;
- design activation, empty, onboarding, upgrade, and cancellation states as part of the experience;
- measure success by user progress and sustained value, not clicks alone.

Revenue guidance is subordinate to trust, accessibility, and user control.

### 9. Implementation discipline

- Inspect and reuse existing tokens, primitives, assets, and dependencies before adding new ones.
- Match repository conventions for framework, styling, routing, state, and testing.
- Keep component APIs semantic and composable; avoid abstractions that serve one use.
- Use real assets or intentional placeholders with explicit dimensions; prevent layout shift.
- Keep visual effects progressive-enhancement friendly and provide contrast-safe fallbacks.
- Do not use Unicode characters as substitute UI icons when the codebase has an icon system.
- Do not ship console warnings, hydration mismatches, broken focus, or inaccessible interactive elements.

### 10. Verification gate

Before declaring a page or component complete, verify:

1. visual thesis, hierarchy, spacing rhythm, type, color, and responsive composition;
2. all interaction and content states, including long content and localization expansion;
3. keyboard order, visible focus, semantic landmarks, labels, contrast, target size, and screen-reader meaning;
4. reduced-motion behavior and animation cleanup;
5. performance: no unnecessary listeners, layout thrashing, oversized assets, or avoidable dependency;
6. console, typecheck, lint, targeted tests, and the repository’s full quality gate;
7. visual evidence at narrow, medium, and wide viewports when browser tooling exists.

Run a final anti-slop pass: remove one unnecessary effect, one redundant surface, and one generic pattern if doing so improves clarity. Keep any effect whose removal would damage meaning or orientation.

## Cross-runtime resolution

Canonical source: `~/Projects/IA/lemon-ai-hub/plugins/design-expert/SKILL.md`.

Preferred discovery:

- shared overlay: `~/.agents/skills/design-expert/`;
- Codex: `~/.agents/skills/design-expert/`, with `~/.codex/skills/` and `~/.codex-lemon-dev/skills/` as harness-specific fallbacks;
- OpenCode: `~/.config/opencode/skills/design-expert/`;
- Claude Code: `lemon-ai-hub` marketplace plugin; `~/.claude/skills/` is local-only fallback;
- Antigravity/Agy: `~/.antigravity/skills/design-expert/` or `~/.agy/skills/design-expert/`;
- Gemini-backed Antigravity: `~/.gemini/config/skills/design-expert/` when that overlay is active.

Keep one source of truth. Prefer symlinks or marketplace exposure over copied skill bodies. Resolve companion skills from the active overlay first, then the hub. If a companion is unavailable, preserve its contribution through this contract and report missing installation only when it blocks the requested work.