← ClaudeAtlas

frontend-design-qualitylisted

Use when implementing or revising any frontend UI – landing pages, marketing sites, portfolios, app screens, dashboards, or components – and when choosing layout, typography, color, spacing, motion, or styling. Enforces a design-read first, real design systems, anti-slop discipline, accessibility, and a pre-flight visual audit so the interface does not look templated or AI-generated.
bartoszarendt/agenticloop · ★ 2 · Web & Frontend · score 71
Install: claude install-skill bartoszarendt/agenticloop
# Frontend design Good UI is not a default aesthetic applied on top of code. It is a decision made before the first line: read the brief, pick a direction that fits the audience, then build it without the tells that mark output as machine-generated. This skill is the engineer's domain reference for any task that changes how a feature looks, feels, moves, or is interacted with. The workflow authority is still the Agentic Loop: scope from the task record, build under [[tdd-implementation]], prove it under [[verification-evidence]], and accept under [[review-and-accept]]. Stack assumptions below (React/Tailwind/Motion) are defaults. When the target project uses a different stack, keep the principles and translate the mechanics. ## 1. Read the brief before generating Most weak UI comes from jumping to a default look instead of reading the room. Before any markup, infer and state a one-line **design read**: > "Reading this as: <page or surface kind> for <audience>, with a <vibe> language, leaning toward > <design system or aesthetic family>." Signals to read: surface kind (landing, portfolio, dashboard, app screen, redesign), vibe words the user used, reference URLs or products named, the audience (the audience picks the aesthetic, not your taste), existing brand assets, and quiet constraints (accessibility-critical, public-sector, regulated, trust-first) that override aesthetic preference. If the read genuinely diverges, ask **one** clarifying question. If you can infer co