ui-standoutlisted

Pick STANDOUT, fit-for-purpose UI components per use-case instead of reusing the same mundane flows. A 3-layer method: query real component catalogs (astryx / shadcn / Aceternity) for candidates, reject AI-slop defaults with a 46-rule taste gate (harvested from impeccable), and justify the pick with design principles (hierarchy, spacing, type, color, Von Restorff standout). Ships a use-case -> component map so a checkout, dashboard, hero, onboarding, or empty-state screen gets a standout component, not a stock grid. Use this BEFORE building or choosing any UI component, screen, page, layout, form, or design system; when the user says a UI is bland/generic/mundane/"looks like every other app" and wants it to stand out; when scaffolding the Presentation layer of a web/SSR/static app; or when reviewing a built UI for slop. Not for backend/serverless-API/networking services (no UI) - and not for charts specifically (the dataviz skill owns those).
M4NUSH7/Niche-Claude-Code · ★ 1 · Web & Frontend · score 77

Install: claude install-skill M4NUSH7/Niche-Claude-Code

# UI Standout - pick fit-for-purpose components, not mundane defaults The goal: each app's UI stands out because the agent went through real component libraries and picked a standout component FOR THAT use-case - instead of reusing the same three-column feature grid and Inter-on-white every time. Global design tokens still carry across apps; the per-screen component choice is what varies. This is a THREE-LAYER method. No single source does the whole job - each layer answers one question, and the use-case -> component map (Layer 0) is this skill's own contribution that none of the sources supply. | Layer | Question | Reference (load on demand) | |---|---|---| | 0. Use-case -> component map | Which standout component fits THIS screen? | `references/component-map.md` | | 1. Component catalog | What can I pick, and how do I get it as owned source? | `references/component-map.md` (Layer 1 section) | | 2. Taste gate | Is this pick / build AI slop? | `references/taste-gate.md` (46 rules) | | 3. Principles | Why this, for this use-case? | `references/design-principles.md` (17 principles) | ## When this skill engages (scope gate) ONLY for UI-rendering archetypes: layered web app, SSR framework, static site. SKIP for serverless-API and networking-service - they have no Presentation layer. For charts/graphs/dashboed-metrics specifically, defer to the `dataviz` skill; this skill covers the surrounding component choices, not the chart internals. If the app has no design tokens yet,