← ClaudeAtlas

frontend-ui-engineeringlisted

Guides frontend UI development with component hierarchy, separation of concerns, accessibility as requirement, and performance awareness. Framework-agnostic, detects stack from project. Triggers chrome-devtools for verification. Use when building UI, frontend development, creating components, UI engineering, component architecture, building pages, or when working on frontend code.
Saturate/agents · ★ 0 · Web & Frontend · score 63
Install: claude install-skill Saturate/agents
# Frontend UI Engineering Build components that are reusable, accessible, and performant. Don't make one big file with everything in it. ## Progress Checklist - [ ] Detect framework and existing patterns - [ ] Design component hierarchy - [ ] Separate data fetching from presentation - [ ] Handle all states (loading, error, empty) - [ ] Ensure accessibility - [ ] Check performance impact - [ ] Verify with chrome-devtools (if URL available) ## Step 0: Detect Framework ```bash # Check what we're working with cat package.json 2>/dev/null | grep -E "react|vue|svelte|angular|next|nuxt|astro" ls src/components/ app/components/ components/ 2>/dev/null | head -10 ``` Match the project's existing component patterns, naming conventions, and file organization. ## Step 1: Component Hierarchy Build at the right level of abstraction. Small, reusable pieces compose into larger ones: - **Tokens / Primitives**: Colors, spacing, typography, icons. Design system foundation. - **Base Components**: Buttons, inputs, cards, modals. Generic, no business logic. - **Composite Components**: Forms, data tables, navigation. Combine base components. - **Features / Views**: Full sections with business logic, data fetching, routing. - **Pages / Layouts**: Top-level composition, page structure. Rules: - Each component does one thing - If a component file is > 200 lines, it probably does too much - Reuse existing components before creating new ones - Don't create abstractions for things used only onc