home / skills / vadimcomanescu / codex-skills / frontend-design
This skill helps you craft production-grade frontend interfaces with a distinctive aesthetic, robust accessibility, and a clear design system using
npx playbooks add skill vadimcomanescu/codex-skills --skill frontend-designReview the files below or copy the command above to add this skill to your agents.
---
name: frontend-design
description: "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."
---
# 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.
This skill helps you create distinctive, production-grade frontend UI with a bold, intentional aesthetic direction, purposeful layouts, meaningful motion, and strong accessibility. I prefer React + Next.js (TypeScript) but can deliver vanilla HTML/CSS/JS when that fits prototypes or standalone embeds. The goal is a single clear point-of-view, scoped changes, and maintainable deliverables ready for shipping.
I start by asking up to four targeted questions about users, location/stack, router/component constraints, and hard design or performance limits. Then I propose 2–3 aesthetic directions, lock a single signature move, define tokens (color/type/shape/motion), build semantic structure, add motion adhering to prefers-reduced-motion, and finish with QA for accessibility and performance. Deliverables include changed files, a short design thesis, and validation commands.
Do you always introduce a new design system?
No. I reuse existing tokens/components unless you request a new global system; changes are scoped and minimal by default.
Which stack is preferred for production work?
Next.js with TypeScript (App Router) is preferred for production routes and design system work; React TS is second, vanilla for demos.