skills/frontend/ui-excellence/SKILL.md
Polished, distinctive UIs that don't look like generic AI output. Visual hierarchy, typography, color, spacing, animation, empty/loading states, responsive, dark mode. Apply to any user-facing interface.
npx skillsauth add devjarus/coding-agent ui-excellenceInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Build interfaces that look designed, not generated. The biggest tell of AI-built UI is sameness — same spacing, same colors, same layout. This skill fights that.
Every screen needs a clear reading order. The user's eye should land on the most important thing first.
Size creates hierarchy:
Page title: text-3xl font-bold (largest = most important)
Section header: text-xl font-semibold (mid = structure)
Body text: text-base (standard = content)
Caption/meta: text-sm text-muted (smallest = supporting)
Don't make everything the same size. If your card title, description, and metadata are all 16px, nothing stands out.
Contrast creates focus:
text-foreground)text-muted-foreground)text-muted-foreground/50)max-w-prose or max-w-2xl. Wall-to-wall text is unreadable.Use a system, not random hex values:
/* Semantic color tokens — adapt to light/dark automatically */
--background /* page bg */
--foreground /* primary text */
--muted /* subtle bg (cards, code blocks) */
--muted-foreground /* secondary text */
--primary /* buttons, links, active states */
--destructive /* errors, delete actions */
--border /* dividers, card edges */
Rules:
Consistent spacing scale:
4px (1) — tight: between icon and label
8px (2) — compact: between related items
12px (3) — default: between form fields
16px (4) — comfortable: between sections
24px (6) — loose: between major blocks
32px (8) — spacious: page padding
48px (12) — dramatic: hero sections
Rules:
p-4 not p-[17px].Don't show a blank page. Show:
┌─────────────────────────────────┐
│ │
│ [illustration] │
│ │
│ No projects yet │
│ Create your first project │
│ to get started. │
│ │
│ [ Create Project ] │
│ │
└─────────────────────────────────┘
text-destructive), not red text on red backgroundPurposeful motion only. Every animation should answer "why does this move?"
prefers-reduced-motion. Remove transforms, keep opacity./* Good default transition */
transition: all 150ms ease-out;
/* Entrance animation */
@keyframes enter {
from { opacity: 0; transform: translateY(8px); }
to { opacity: 1; transform: translateY(0); }
}
grid-cols-1 md:grid-cols-2 lg:grid-cols-3overflow-x-hidden on body if needed.brightness(0.9) or contrast(1.1) filter on dark.When the evaluator has to fall back to HTML inspection (no Playwright), shadcn components provide stable data-attributes that make presence-verification reliable without a browser. Useful when you need to prove "the Sidebar primitive is actually rendered" from curl output alone.
Common data-attributes to grep for:
data-sidebar="sidebar|header|content|footer|rail|trigger" and data-slot="sidebar-wrapper|sidebar-inset|sidebar-container"data-slot="dialog-content|dialog-overlay|dialog-title" (when open — may require scraping after an interaction)data-slot="dropdown-menu-content", data-state="open|closed"data-slot="tabs-list|tabs-trigger|tabs-content", data-state="active|inactive"class="...inline-flex...h-9...") rather than data-attr; less reliable for verificationExample fallback verification:
curl -s http://localhost:3000/ -o /tmp/home.html
grep -c 'data-sidebar="sidebar"' /tmp/home.html # should be >= 1 if Sidebar rendered
grep -c 'data-slot="sidebar-wrapper"' /tmp/home.html # should be >= 1
This can't verify visual styling or interaction — only structural presence. Pair with explicit "human 30-second eyeball" notes in review.md for pixel-level things (dark mode FOUC, layout, animations).
testing
Multi-source research method — decompose a question, fan out parallel investigators, interleaved-think each result, verify claims adversarially, synthesize a cited answer. Use for breadth-heavy research, stack comparisons, "which approach wins" questions.
testing
Decide when to use unit vs integration vs e2e tests, and when to mock vs use the real thing per dependency. Dependency injection is the enabler — without it you end up monkey-patching imports. Apply when writing tests of any kind.
development
Test-driven development process — write failing test, implement to pass, refactor. Use when implementing any feature or fixing bugs.
development
Patterns for sharing types, API contracts, and validation schemas between frontend and backend. Use when multiple domains consume the same data shapes to prevent contract drift.