← Back to registry
Skill

frontend-design

"Create distinctive, production-grade frontend UI with a bold, intentional aesthetic direction, purposeful layouts, meaningful motion, and strong accessibility. Prefer React + Next.js (TypeScript), but support vanilla HTML/CSS/JS when appropriate."

Categorydesign
Last updated2026-01-19
View on GitHub
Install

One-line setup

Copy and run this in your terminal to install the skill. Re-run to reinstall and update an existing install.

npx codex-skills-registry@latest --skill=design/frontend-design --yes

Frontend Design

Build memorable, functional interfaces with a clear point-of-view (no generic templates). Commit to one aesthetic direction, define tokens, ship accessible + responsive UI, and keep changes scoped.

Preferred Targets (choose the best fit)

  1. Next.js (TypeScript): preferred for production app/marketing routes and design system work.
  2. React (TypeScript): preferred for SPA/component libraries outside Next.js.
  3. Vanilla HTML/CSS/JS: great for static demos, prototypes, and standalone embeds.

Quick Start (do this first)

  1. Ask up to 4 questions:
    • What user and job-to-be-done (what should feel “easy” after the change)?
    • Where does it live (component/route) and what stack? Prefer Next.js/React; vanilla is fine for standalone pages or prototypes.
    • In Next.js: assume App Router (app/). Any server/client constraints?
    • Any hard constraints (brand tokens, light/dark, motion limits, must-keep UI parts, perf budgets)?
  2. Pick an aesthetic direction + one signature move. If vague, propose 2–3 options from references/aesthetic-playbook.md.
  3. Define tokens (type, palette, spacing, radius, shadows, motion). Keep accents to 1–2.
  4. Build structure first (semantic markup + layout), then motion, then polish + QA.

Guardrails (avoid footguns)

  • Keep scope tight: redesign only what the user asked for.
  • Reuse existing tokens/components if working in an existing repo; do not introduce a new global styling system unless requested.
  • Match complexity to the vision: refined minimalism needs restraint; maximalism needs deliberate structure (not random decoration).
  • Respect prefers-reduced-motion for all animations.
  • Avoid “AI slop” defaults. If the repo already uses a generic font, keep it unless the user explicitly wants new typography.
  • Enforce token semantics: error/success/warning colors are for meaning, not decoration; keep contrast accessible in light/dark.
  • Default to shipping code that is easy to maintain: small components, clear hierarchy, minimal dependencies.
  • Don’t add new packages (animation libs, UI kits, icon sets) unless the user explicitly asks or the repo already uses them.
  • Default to one primary CTA per view; demote the rest (secondary/tertiary) to avoid competing actions.

Workflow

1) Commit to a direction

  • Declare: aesthetic direction, palette mood, type pairing, and the signature move.
  • Write a 1–2 sentence design thesis that explains the hierarchy and vibe.
  • Use references/anti-patterns.md to avoid predictable layouts and cliched palettes.

1b) Design system rules (strict vs flexible)

  • Strict: semantic color meaning, readable type ramp, reduced motion, visible focus, and “human-in-control” for AI actions (undo/apply/confirm).
  • Flexible: brand accent hue, surface “temperature” in dark mode, and density preset (compact vs comfy).
  • When to read more: load references/tokens-and-semantics.md when defining tokens and references/ai-native-ui-patterns.md when adding AI surfaces.

1a) React/Next.js coding guidance (read when implementing)

  • React fundamentals: keep components pure; prefer event handlers over Effects for user-driven work; follow the Rules of Hooks.
  • Next.js App Router: keep Client Components small; use Server Components by default; mark "use client" only where you need state, effects, or browser APIs.
  • Data fetching: prefer server-side fetch and explicit cache/revalidate controls; avoid unnecessary client-side effects for data.
  • When to read more: load references/react-next-best-practices.md before writing complex React logic or introducing new data fetching patterns.

2) Plan tokens and layout (before details)

  • Define CSS variables (or a theme object) for:
    • Color: background/surface/ink/muted/accent(+optional accent2)
    • Type: display/body/mono, size scale, line-height
    • Shape: radius scale and border rules
    • Depth: shadow and outline rules
    • Motion: durations + easing + reveal stagger step
  • Lay out the page/component skeleton and content hierarchy.
  • Reference references/implementation-patterns.md for patterns and QA.

3) Implement (ship code, not moodboards)

  • Start with semantic structure and accessible interactions (keyboard + focus states).
  • Build macro layout with Grid; micro layout with Flexbox.
  • For Next.js/React, keep components small and composable; prefer CSS Modules or the repo’s existing styling approach.
  • Use “link for navigation, button for actions” to keep semantics and keyboard behavior correct.
  • Apply the signature move sparingly but decisively (one memorable thing, not ten).
  • Add motion as orchestration (one strong page-load + a few micro-interactions), not random flourishes.

3a) Next.js implementation notes (when applicable)

  • App Router only: assume app/ routing (not pages/).
  • Server vs Client: default to Server Components; add "use client" only for interactive islands.
  • Data + state: keep data fetching on the server when possible; keep client state local and purposeful.
  • Performance: avoid layout shift (stable heights, predictable grids); keep blur/shadows paint-friendly on mobile.
  • Platform primitives: prefer next/link for navigation and next/image for real images when available.
  • Fonts: if changing typography in Next.js, prefer next/font to avoid FOIT/FOUT surprises.
  • Styling: keep it consistent—CSS Modules, Tailwind, or the existing system; don’t introduce a new one without asking.

3b) Content + states (don’t ship empty shells)

  • Define loading, empty, and error states for any data-driven UI.
  • Keep copy tight and purposeful; avoid placeholder lorem unless asked.
  • Preserve existing product terminology unless the user requests copy changes.

4) Polish and QA

  • Responsive pass: collapse grids, maintain padding, preserve CTA prominence on mobile.
  • Accessibility pass: landmarks, one h1, labels, contrast, focus order, skip link when relevant.
  • Performance pass: avoid expensive shadows on mobile, keep animation paint-friendly, avoid large images.

Definition of Done

  • Layout looks intentional at mobile + desktop breakpoints (no cramped type, no orphan CTAs).
  • Focus states are visible, tab order is logical, and motion respects prefers-reduced-motion.
  • Tokens are centralized (CSS variables/theme), and the signature move is present but not overused.

Deliverables (how to present results)

  • List files changed and what they do.
  • Explain the aesthetic direction + signature move (1–2 sentences).
  • Provide commands to validate (use the repo’s conventions; common ones include npm run dev, npm run lint, npm test).

Bundled Resources

  • references/aesthetic-playbook.md: strong directions, type+color cues, signature moves.
  • references/implementation-patterns.md: layout/motion/a11y patterns for vanilla + React.
  • references/anti-patterns.md: quick “don’t do this” checklist to avoid generic output.
  • references/react-next-best-practices.md: React + Next.js coding guidelines (hooks, effects, server/client, data fetching).
  • references/tokens-and-semantics.md: token semantics, type ramp, dark mode, and density rules (strict vs flexible).
  • references/ai-native-ui-patterns.md: copilot panels, citations, disclosures, and human-in-the-loop UI patterns.
  • assets/vanilla-starter/: runnable vanilla starter you can copy + retheme via CSS variables.
  • assets/react-component-starter/: small React component + CSS module skeleton to retheme.
  • assets/nextjs-app-router-starter/: minimal Next.js App Router page + tokens you can copy and retheme.