Design and Frontend Skills

General-purpose leads

Skill	Pick it when	Avoid it when
`$impeccable`	You want one broad workflow for creating, auditing, polishing, adapting, or hardening a real frontend. Best default for product UI.	The task is backend-only or only needs a narrow reference lookup.
`$frontend-design`	You want aesthetic direction — typography, visual choices with authorship — for new UI or a reshape. Upstream narrowed it to guidance, so pair it with a lead that writes the code.	An established design must be preserved precisely, or you expect it to produce the finished implementation itself.
`$design-taste-frontend`	You want an opinionated anti-template landing page, portfolio, or redesign.	You require its old behavior; use `$design-taste-frontend-v1` only for compatibility.
`$hallmark`	You want a greenfield design or audit focused on removing generic AI-design tells.	Another broad design workflow already owns the same phase.
`$ui-ux-pro-max`	You need searchable styles, palettes, type pairings, charts, accessibility, or stack patterns. Treat it as an advisor.	You expect it alone to own a complete product-design process.
`$emil-design-eng`	A working interface needs high-craft component, motion, and micro-detail judgment.	Product structure is still unresolved.
`$make-interfaces-feel-better`	You need targeted polish: hover states, shadows, borders, type, icons, alignment, or micro-interactions. It now offers a quick pass and a full review — say which.	You need a full redesign.

Pick one visual direction

$minimalist-ui: warm, editorial, flat, and restrained.
$industrial-brutalist-ui: mechanical, Swiss, terminal-like, and data-heavy.
$high-end-visual-design: premium agency typography, spacing, surfaces, and motion.
$gpt-taste: experimental editorial layout and advanced GSAP-heavy motion.
$apple-design: physical motion, gestures, translucent materials, and Apple-like restraint — for the web.
$design (Claude Code only): Apple's own platform design language for native apps — Liquid Glass, SF Symbols, haptics, game feel, UX writing. Ships in the apple-skills plugin; pick it for real SwiftUI/UIKit surfaces, and $apple-design when the target is a browser.
$brandkit: brand systems, identity boards, logos, and premium mockups—not application implementation.
$stitch-design-taste: generate a semantic DESIGN.md for Google Stitch workflows.

Images and visual-first implementation

Skill	Use it for
`$imagegen` (Codex only)	A direct raster asset such as a photo, illustration, texture, sprite, mockup, or cutout.
`$imagegen-frontend-web`	Separate, consistent visual references for website sections. It generates images, not code.
`$imagegen-frontend-mobile`	Consistent mobile screen concepts. It generates images, not code.
`$image-to-code`	A visual-first workflow that generates references and continues through implementation.
`$codex-imagegen`	The same raster assets as `$imagegen`, driven from Claude Code through the Codex CLI, with the generated-image cache pruned afterwards. It needs the `codex` CLI installed; without it, nothing here runs.

Borrow an existing site's design

$extract-design-md: point it at a URL for a compact, portable DESIGN.md: tokens, typography, spacing, component style, and brand feel. Pick it when visual identity is enough — to brief one page, compare sites, or reuse a design spec — and not when you need component anatomy or interaction states. It samples real pages with /playwright-cli and validates the result rather than guessing from screenshots.
$extract-design-system: point it at a URL to capture both tokens and a component catalog — button anatomy, card variants, hover and focus states, section patterns — into .design_systems/<domain>-<date>/. Pick it when new pages must look native to that brand, not merely share its palette. It drives a real browser through /playwright-cli, so that has to be installed.
$design-system-to-skill: package one of those full extracted bundles as an auto-triggering per-brand skill, so later work reaches for it without being pointed at the folder. It consumes $extract-design-system output; it cannot produce one.

All three describe an existing brand faithfully. Reach for a visual direction above instead when the design is yours to invent.

Motion: choose by stage

Stage	Skill
You can describe an effect but do not know its name	`$animation-vocabulary`
The UI lacks motion and you want candidate opportunities	`$find-animation-opportunities`
You need to settle how the motion should feel before building it	`$motion-design`
You are designing or building interactions	`$design-motion-principles`
Existing motion needs a prioritized improvement plan	`$improve-animations`
Existing animation code needs a strict review	`$review-animations`

$motion-design and $design-motion-principles both answer "animate this", so separate them by what is still undecided. Reach for $motion-design when the emotional target, brand motion personality, or choreography across a scene is still open, or when the work runs through Lottie or Rive — it is renderer-agnostic and carries the Disney principles, timing tables, and personality archetypes. Reach for $design-motion-principles once the intent is settled and you are building or auditing a specific web component, since it applies named practitioners' techniques to HTML, CSS, React, and Framer Motion and disclaims translating to Lottie or Rive. Direction first, craft second; one lead per phase either way.

GSAP

Library reference, not motion judgment. The stage skills above decide what should move and whether it feels right; these decide how to write it once GSAP is the chosen library. Reach for them only after that choice is made — each one is written to recommend GSAP when no library is specified, so they will not help you compare it against CSS, Motion, or Web Animations.

Skill	Pick it when	Avoid it when
`$gsap-core`	Writing tweens: `gsap.to`, `from`, `fromTo`, easing, stagger, `matchMedia` for responsive and reduced-motion.	You want animation principles rather than API calls; use `$design-motion-principles`.
`$gsap-timeline`	Sequencing several animations, using the position parameter, nesting, or controlling playback.	A single tween is enough; stay in `$gsap-core`.
`$gsap-scrolltrigger`	Scroll-linked motion: pinning, scrub, triggers, refresh after layout changes.	The motion is not driven by scroll position.
`$gsap-plugins`	Using a named plugin — Flip, SplitText, Draggable, Observer, ScrollSmoother, MorphSVG, CustomEase.	Core tweens or ScrollTrigger already cover the task.
`$gsap-react`	Animating in React or Next.js: `useGSAP`, refs, `gsap.context()`, cleanup on unmount.	The project is Vue or Svelte; use `$gsap-frameworks`.
`$gsap-frameworks`	Animating in Vue, Nuxt, Svelte, or SvelteKit: lifecycle hooks, scoped selectors, cleanup.	The project is React; use `$gsap-react`.
`$gsap-utils`	Reaching for `gsap.utils` helpers: `clamp`, `mapRange`, `random`, `snap`, `toArray`, `wrap`, `pipe`.	You are not already inside GSAP; these are library helpers, not general utilities.
`$gsap-performance`	Diagnosing jank, dropped frames, or layout thrashing in existing GSAP animations.	Nothing is built yet; performance work needs animations to measure.

Focused frontend work

$prototype: build several genuinely different UI versions behind a live picker.
$redesign-existing-projects: upgrade an existing interface while preserving behavior.
$web-design-guidelines: audit accessibility and general web-interface conventions.
$pick-ui-library: select an appropriate frontend library for one concrete UI need.

Do not stack broad leads by default. Use /pick-skills when two of them look equally plausible; it resolves the overlaps this guide lists but does not settle.