Builds production-quality, accessible, responsive user-facing UIs. Use when building or modifying interfaces and pages, creating components, implementing layouts, meeting WCAG accessibility requiremen
Install
Use withClaudeCursorCodex
The file stays in the publisher's repository. PlugMCP does not host or rewrite it.
Builds production-quality, accessible, responsive user-facing UIs. Use when building or modifying interfaces and pages, creating components, implementing layouts, meeting WCAG accessibility requirements, managing state, or when the output needs to look and feel production-quality rather than AI-generated.
name: frontend-ui-engineering
description: Builds production-quality, accessible, responsive user-facing UIs. Use when building or modifying interfaces and pages, creating components, implementing layouts, meeting WCAG accessibility requirements, managing state, or when the output needs to look and feel production-quality rather than AI-generated.
Frontend UI Engineering
Overview
Build production-quality user interfaces that are accessible, performant, and visually polished. The goal is UI that looks like it was built by a design-aware engineer at a top company — not like it was generated by an AI. This means real design system adherence, proper accessibility, thoughtful interaction patterns, and no generic "AI aesthetic."
Local state (useState) → Component-specific UI state
Lifted state → Shared between 2-3 sibling components
Context → Theme, auth, locale (read-heavy, write-rare)
URL state (searchParams) → Filters, pagination, shareable UI state
Server state (React Query, SWR) → Remote data with caching
Global store (Zustand, Redux) → Complex client state shared app-wide
Avoid prop drilling deeper than 3 levels. If you're passing props through components that don't use them, introduce context or restructure the component tree.
Design System Adherence
Reference-led UI quality
When the product needs a distinct visual direction, collect evidence before choosing a layout:
Search a trusted reference catalogue or use references supplied by the product team.
Study two or three relevant screens. Record decisions about hierarchy, density, navigation, controls, responsive behavior, and interaction states.
Turn those decisions into a short design contract before implementation. Name the screen's job, primary action, required states, responsive rules, and patterns to reject.
Rebuild the useful structure in the product's own components, tokens, content, and visual language. Never copy another product's branding, proprietary text, imagery, or exact layout.
Use references as evidence, not as templates. If references are unavailable, document the assumptions and verify the result against the product's existing design system.
Avoid the AI Aesthetic
AI-generated UI has recognizable patterns. Avoid all of them:
AI Default
Why It Is a Problem
Production Quality
Purple/indigo everything
Models default to visually "safe" palettes, making every app look identical
Use the project's actual color palette
Excessive gradients
Gradients add visual noise and clash with most design systems
Flat or subtle gradients matching the design system
Rounded everything (rounded-2xl)
Maximum rounding signals "friendly" but ignores the hierarchy of corner radii in real designs
Consistent border-radius from the design system
Generic hero sections
Template-driven layout with no connection to the actual content or user need
Content-first layouts
Lorem ipsum-style copy
Placeholder text hides layout problems that real content reveals (length, wrapping, overflow)
Realistic placeholder content
Oversized padding everywhere
Equal generous padding destroys visual hierarchy and wastes screen space
Consistent spacing scale
Stock card grids
Uniform grids are a layout shortcut that ignores information priority and scanning patterns
Purpose-driven layouts
Shadow-heavy design
Layered shadows add depth that competes with content and slows rendering on low-end devices
Subtle or no shadows unless the design system specifies
Spacing and Layout
Use a consistent spacing scale. Don't invent values:
/* Use the scale: 0.25rem increments (or whatever the project uses) */
/* Good */ padding: 1rem; /* 16px */
/* Good */ gap: 0.75rem; /* 12px */
/* Bad */ padding: 13px; /* Not on any scale */
/* Bad */ margin-top: 2.3rem; /* Not on any scale */
Typography
Respect the type hierarchy:
h1 → Page title (one per page)
h2 → Section title
h3 → Subsection title
body → Default text
small → Secondary/helper text
Don't skip heading levels. Don't use heading styles for non-heading content.
Color
Use semantic color tokens: text-primary, bg-surface, border-default — not raw hex values
Ensure sufficient contrast (4.5:1 for normal text, 3:1 for large text)
Don't rely solely on color to convey information (use icons, text, or patterns too)
Accessibility (WCAG 2.1 AA)
Every component must meet these standards:
Keyboard Navigation
// Every interactive element must be keyboard accessible
<button onClick={handleClick}>Click me</button> // ✓ Focusable by default
<div onClick={handleClick}>Click me</div> // ✗ Not focusable
<div role="button" tabIndex={0} onClick={handleClick} // ✓ But prefer <button>
onKeyDown={e => {
if (e.key === 'Enter') handleClick();
if (e.key === ' ') e.preventDefault();
}}
onKeyUp={e => {
if (e.key === ' ') handleClick();
}}>
Click me
</div>
ARIA Labels
// Label interactive elements that lack visible text
<button aria-label="Close dialog"><XIcon /></button>
// Label form inputs
<label htmlFor="email">Email</label>
<input id="email" type="email" />
// Or use aria-label when no visible label exists
<input aria-label="Search tasks" type="search" />
Focus Management
// Move focus when content changes
function Dialog({ isOpen, onClose }: DialogProps) {
const closeRef = useRef<HTMLButtonElement>(null);
useEffect(() => {
if (isOpen) closeRef.current?.focus();
}, [isOpen]);
// Trap focus inside dialog when open
return (
<dialog open={isOpen}>
<button ref={closeRef} onClick={onClose}>Close</button>
{/* dialog content */}
</dialog>
);
}
Meaningful Empty and Error States
// Don't show blank screens
function TaskList({ tasks }: { tasks: Task[] }) {
if (tasks.length === 0) {
return (
<div role="status" className="text-center py-12">
<TasksEmptyIcon className="mx-auto h-12 w-12 text-muted" />
<h3 className="mt-2 text-sm font-medium">No tasks</h3>
<p className="mt-1 text-sm text-muted">Get started by creating a new task.</p>
<Button className="mt-4" onClick={onCreateTask}>Create Task</Button>
</div>
);
}
return <ul role="list">...</ul>;
}
All interactive elements are keyboard accessible (Tab through the page)
Screen reader can convey the page's content and structure
Responsive: works at 320px, 768px, 1024px, 1440px
Loading, empty, error, success, and permission states handled when applicable
Follows the project's design system (spacing, colors, typography)
The rendered result passes a final UI-specific finish-gate review
No accessibility warnings in dev tools or axe-core
How do I install frontend-ui-engineering?
Download skills/frontend-ui-engineering/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does frontend-ui-engineering live?
The publisher keeps it at https://github.com/addyosmani/agent-skills.
Which agents can use frontend-ui-engineering?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.