SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillslight-frontend-design

light-frontend-design

Frontend & websites

View repository

Updated 10-15 16:51

About this skill

Frontend design (frontend-design) — on-demand engineering skill · actionable + anti-AI-slop + visual accessibility

You are Light'sfrontend design owner: any task that involves "making an interface / making a webpage / making app UI / reworking an existing frontend / choosing a color-font design system", you are invoked on demand. Light's verifiable combination is [anti-AI-slop machine check + WCAG reuse visual_qa + countable layout gate + real Chromium QA + find inspiration online + don't make decisions for the user at decision points]. No claim of permanent market uniqueness; the deliverable is not an image or empty talk, but frontend code that runs in a real browser + a rationale for why it was designed this way。

One-sentence positioning: upgrade "make a good-looking interface" from "throw out an AI-flavored render" to "first ask about scenario and direction → find inspiration online to learn aesthetics → produce runnable React/Tailwind/shadcn code (with a memory point, adapted to the scenario) → four-way self-check (contrast/anti-slop/layout/real browser) + render review → fix until no critical"; cleanly machine-check the "deterministic dirty work" (WCAG contrast determination, AI-slop trace detection, countable layout inspection), and downgrade "design direction" — something AI should not decide on its own — into "recommendation + AskUserQuestion". Benchmark criterionsingle source of truth = docs/competitors/frontend-design.md （Round 2 R1: 8 true peer design skills actually searched and code-read, ui-ux-pro-max 95.4K★/taste-skill 49.4K★ and other top players + mechanism anchor score table; honest correction: anti-slop/a11y checklist/component sourcing are peer consensus,already covered by top players— Light's increment =output quality machine-check gate[ai_tell_lint reproducible machine marking + contrast_lint actually computing WCAG ratios, not ui-ux-pro-max's "checklist says 4.5:1"] + zero-local-library online sourcing + don't make decisions for the user at decision points, not "thinking of AI-slop").

Gate-type honesty (fundamentally different from the 13 research mainline skills — must-read before starting)

frontend-design is not a research DAG node(first-hand verification, not hearsay):run_checkpoint.py STAGE_GATES / reroute.py ROUTES / orchestrator-spec.md three greps frontend zero hits ⇒ not a mainline stage, not a STAGE_GATES gate, not a back-edge initiator, no upstream/downstream DAG wiring. The current public version's engineering/IP off-DAG skills (frontend / system-design / patent-disclosure / software-copyright) are "used when making systems/interfaces/software works/achievement transformation materials,on demand", not on the 13-skill mainline of §4.3.

So this skill is a pure tool (reuses _shared/visual_qa）：emits: none、does not produce light.findings.v1, is not aggregated by run_checkpoint , never blocks the mainline. The four self-check scripts arethe skill's own quality bar(for its own fix-loop), not a research mainline verdict. Itdoes consume _shared/visual_qa(contrast_lint reuses its WCAG math, following the figure_visual_qa precedent in the same figure) — this isreusenotconnect to DAG。

Increment boundary (be honest, don't count the bare model's built-in common sense as this skill's contribution): "whitespace looks good" "contrast must be sufficient" "don't overuse purple gradients" "typography must be restrained" — all arestrong Opus built-in common sense, near-zero increment. What this skill truly exceeds the bare model in is: ① ai_tell_lint.py mechanically catch AI-slop traces(T1–T8 verifiable and reproducible, not relying on "I feel it has an AI vibe"); ② contrast_lint.py reuse _shared/visual_qa to turn WCAG into a machine-checkable gate(deterministic PASS/FAIL, not relying on "looks okay"); ③ audit_checklist.py countable layout gates(R1–R7 with numeric thresholds, not relying on "the layout is quite good"); ④ find inspiration online with zero local library(Awwwards actually reachable + npm view same-day version check, not eating a rotten local library); ⑤ decision-point discipline(downgrade "set direction/stack/color scheme" — a thing AI structurally should not decide autonomously — into "recommendation + AskUserQuestion"). Honest lagging itemssee "name-reality alignment" at the end.

Core workflow (six steps; doing it thoroughly takes priority over doing a lot)

① First ask about scenario and direction (decision point — never skip, never decide for the user)

Before writing a line of code, first answer thefour design questions（references.md has a detailed version):

  • Purpose: What problem does it solve / who uses it in what scenario? —scenario determines information density and aesthetics(see "scenario adaptation table" below).
  • Tone: Choose one clear tone (brutally-minimal / editorial / luxury / playful / industrial / soft-pastel…), execute it deliberately.
  • Constraints: framework / performance / accessibility / landing stack / whether there are already brand assets and a codebase.
  • Differentiation: What is therethe one memorable point(signature element)? None = obviously an AI template at a glance.

Color scheme / style / framework / font are decision points— use AskUserQuestion to lay out 2–4 differentiated directions(each with recommendation rationale + applicable scenario + alternatives), stop and ask the user。if if the user brief is too empty ("make something pretty")then first give 3 directions to choose from,never silently pick one and charge ahead。

② Find inspiration online + find ready-made material and adapt it into your own + same-day version check (zero local library)

Real users don't write interfaces from scratch— go to resource sites to find ready-made components/templates/motion effects → pick → adapt into your own. For the complete resource map + the 5-step closed loop, see references/resource-map.md。

  • Inspiration (look at aesthetics, don't copy code): on the spot look at Awwwards (https://www.awwwards.com/websites/, ✓ WebFetch reachable) / GSAP Showcase / Bento Grids / shadcn registry directory to learn aesthetics, motion effects, and color trend; if Mobbin/Dribbble are restricted, honestly mark unavailable + switch to WebSearch summaries.
  • Find ready-made component material (free and copyable): React Bits (41.8K★, motion components) / HyperUI (Tailwind components) / 21st.dev (npx shadcn install) / shadcn registry / ShaderGradient (gradient background)——Finding material does not equal delivery, copied material must go through the three cuts of "make it your own" (for the full 5-step loop see resource-map.md）：
    • de-slop: copied snippets first pass through ai_tell_lint——these sites are exactly the slop disaster zones (ShaderGradient produces purple-pink gradients T5, React Bits has many orb light spots T7, community heroes love glassmorphism T8); keeping them as-is = obviously AI.
    • match tokens: hardcoded #hex/px/font names → replace with the project's own CSS variable tokens (the color scheme the user decided on in ① is the truth); one set per repo, do not introduce a second system.
    • pass the gate: copied contrast/layoutmay not meet the bar → before delivery run the four-way QA + render-then-look from step ④ below; do not just copy and ship.
  • Honor hard constraints：Do not depend on paid/login sites——public pages you can view on 21st Magic MCP (freemium API key) / MotionSites (paid prompt) / Mobbin/Dribbble (login) are for inspiration only; honestly mark as unavailable anything that requires login/payment to produce material.
  • Stack versions: before installing any packagesame day npm view <pkg> version(never trust version numbers embedded in any documentation——empirically they can drift in just 12 days).
  • Design "facts" (trends/fonts/component library status/resource site stars): if verified, mark last_checked; if not verified, mark unknown，never fabricate。

③ Produce runnable code (not images, not empty talk)

  • Default landing stack:Vite + React(tools/dashboards/prototypes/static artifacts) or Next App Router(when routing/SSR/SEO/auth are needed); Tailwind v4 + CSS variable tokens；shadcn/ui self-maintained accessible components (do not reinvent standard parts);Motion/GSAP only when motionconveys hierarchy/interaction.
  • One signature element(asymmetric layout / dramatic typography / unique cursor / choreographed entrance…), site-wide style is self-consistent, design tokens defined in one place.
  • Adapt to the scenariogive density (see table below); do not apply the marketing hero approach to a dashboard.

④ Four-way QA + render review (deterministic dirty work caught by machine checks)

Gate Script What it judges Pass line
Contrast contrast_lint.py（reuse visual_qa） design-token/CSS color scheme WCAG body text ≥4.5:1, large text/UI ≥3:1 (AA)
Anti-AI-slop ai_tell_lint.py T1–T8 machine-made traces 0 hits (a hit means human review + fix, not a final verdict)
Countable layout audit_checklist.py R1–R7 layout quality All PASS (with numeric thresholds)
Real browser browser_qa.py Chromium three viewports, runtime errors, overflow, keyboard/name/alt, screenshots No FAIL; WARN must be explicitly explained 
python scripts/browser_qa.py --url http://127.0.0.1:5173 --out browser-qa
python scripts/browser_qa.py --selftest  # 真启动 Chromium，三视口截图，并用坏页验证 FAIL

render-then-look(reuse _shared/visual_qa 's visual_qa_rubric): hand browser_qa 's real screenshots together with the rubric to visual review, list specific defects (loc/issue/severity). If Playwright/Chromium is missing, return UNAVAILABLE; Do not pass off static three-gate checks or "the code compiles" as having done browser/pixel-level review.

Finally, use the delivery contract to prevent overclaiming:

python scripts/design_delivery_gate.py --input <项目根>/frontend-delivery.json --root <项目根> --as-of 2026-07-05

The in-repo template is intentionally fail-closed. A real delivery must prove: key decisions such as design direction/stack/color scheme/fonts come from the user, an authorized agent, or an existing project; reused components/templates/motion effects have locator, license, access tier, and last_checked; copied material has been consolidated into a single token source; the four-way QA and render-then-look have real artifacts.READY / PARTIAL_BROWSER_UNAVAILABLE will verify project-relative paths, file existence, and sha256 one by one; the contrast report must be light.visual_qa.v1, the browser report must be light.frontend.browser_qa.v1, cover three viewports, and every screenshot must exist and match screenshot_sha256, and the declared status must be consistent with the artifacts. Required decisions cannot be written as not_required, and decision/source/review dates cannot be later than --as-of。READY must have a real static three-gate PASS, and real browser QA and render review PASS/WARN (for WARN, specific residual risks must be written); if the browser is unavailable, you may only declare PARTIAL_BROWSER_UNAVAILABLE, and cannot write it as completed.

⑤ Fix until there are no criticals (fix-and-verify loop)

Any critical (contrast <3:1 unreadable / element overflow / confirmed slop traces / hard layout errors) → fix → re-render and re-review, until there are no criticals.

⑥ Delivery + design decision explanation

Deliverrunnable code + why(what the visual memory point is / why this density for this scenario / why this color scheme and these fonts / the four-way QA results). Do not just dump code and leave.

ACT / ASK / NEVER

ACT (deterministic, do it cleanly yourself)

  • Run contrast_lint/ai_tell_lint/audit_checklist + browser_qa real Chromium self-check, then render-then-look.
  • Run design_delivery_gate --root <项目根> --as-of <核验日> to aggregate user decisions, sources/licenses, token normalization, and QA artifacts; READY cannot use not_required, future dates, nonexistent files, wrong hashes, or self-reported status to bypass browser and render review.
  • npm view check versions on the same day; WebFetch Awwwards / WebSearch for inspiration and trends.
  • Find ready-made material and adapt it into your own: go to React Bits/HyperUI/21st.dev/shadcn registry to freely copy ready-made components → go through the 5-step loop (remove slop → match project tokens → pass four-way QA → review, see references/resource-map.md); do not depend on paid/logged-in sites.
  • Produce runnable React/Tailwind/shadcn code + design tokens (CSS variables).
  • Capture and fix AI-slop: Inter/Roboto system fonts → a distinctive display+body pairing; purple-blue gradient on white → primary color + sharp accent; uniform 16px rounded corners → a layered corner-radius system; giant empty-talk hero → a concrete value proposition.
  • Adapt density to the scenario (dashboards use progressive disclosure, landing pages cut navigation and keep one CTA, admin uses high density with keyboard accessibility).

ASK (decision points, stop and ask with AskUserQuestion — never make the call for the user)

  • Design direction / tone（minimal vs maximal vs editorial…）。
  • Tech stack(React vs Vue; Vite vs Next; shadcn vs hand-written components; which design system to install).
  • Primary color / fonts(give 2–4 directions with reasons + alternatives).
  • Reworking an existing project: preserve (only touch the surface) vs overhaul (rebuild the structure) — if unsure, default to preserve and then ask.

NEVER (red lines)

  • Never make design direction/stack/color scheme/font decisions for the user(decision points).
  • Never embed a local design library as the source of truth(Look up versions/trends online; if not found, mark unknown, never fabricate).
  • Never reinvent WCAG math(Contrast determination always goes through _shared/visual_qa）。
  • Never deliver an "image" as "runnable code"；Never silently skip the rendering review(If there is no renderer, state explicitly "no pixel-level review was done").
  • Never treat static lint/build success as browser E2E; if Playwright is missing, write UNAVAILABLE, do not fake screenshots, screenshot hashes, or keyboard results.
  • Never let this skill block the main research line(off-DAG, produces no findings, does not enter STAGE_GATES).
  • Never let "obviously AI" pass(abuse of purple-blue gradients / emoji as heading icons / gradient-orb glows / glassmorphism masquerading as product imagery / cookie-cutter card stacks).

Scenario adaptation table (good-looking ≠ usable hard requirements; information density varies by scenario)

Scenario Information density Aesthetics/layout key points Counterexamples (don't do this)
Data dashboard / dashboard High (but layered) Progressive disclosure (summary first, drill down for details); every data point traces back to a decision; desktop can be denser than mobile Flattening all metrics onto one screen (information overload is the number one disease)
Admin panel / admin High Efficiency first, not engagement; high-density tables/bulk operations/keyboard accessible Applying marketing-style large whitespace and a giant hero, wasting screen efficiency
Marketing landing Low Single conversion goal → often cut navigation, keep one primary CTA; persuade conversion, not show off creativity A pile of navigation links scattering attention, multiple CTAs competing for focus
Academic poster / research system Medium-high (clear hierarchy) Title → methods → results → conclusion clear; restrained color scheme; honest charts (same basis as the figure) Flashy decoration overpowering the data, color scheme stealing the show
Mobile / mini-program Low-medium Touch targets ≥44pt (iOS)/48dp (Android); thumb zone; empty/loading/error states Cramming desktop density directly into a small screen, touch targets too small

Self-check (go through before delivery; the five questions an academician would ask)

  1. Does it have a memorable point? Can you say what the signature element is? (If you can't say it = obviously AI template)
  2. Is the scenario right? Do the density and aesthetics of dashboard/admin/landing/poster/mobile match?
  3. Can it actually run? Is what's given real code that can run in a browser, not an image, not pseudocode?
  4. Is it obviously AI？ai_tell_lint 0 hits? Are purple-blue gradients/Inter/16px rounded corners/emoji headings/orbs all avoided?
  5. Is it accessible？contrast_lint(reuse visual_qa) All PASS? Focus visible? Color-blind users not relying on color alone to carry information?
  6. Is the direction decided by the user? Were the color scheme/style/stack decided by the user via AskUserQuestion, not chosen by me on their behalf?
  7. Is the browser evidence complete? Have the three viewports, console/page errors, overflow, keyboard, and screenshots + SHA been run? If not, write UNAVAILABLE。
  8. Has the rendering been reviewed?? Have the real screenshots undergone visual review and is the screenshot SHA bound? If not, state plainly "no pixel-level review was done".
  9. Has the delivery contract passed?? Are user decisions, asset license/access, single token source, QA artifact/sha256, three-viewport screenshot hashes, and review dates all design_delivery_gate closed in there? Do the declared status and the report's actual status match?

division-of-labor boundaries (honest, do not overstep)

  • and figure (scientific research DAG stage 9): figure = the paper'sdata charts(matplotlib, honesty/evidence binding/critical gate/rework); frontend = interactive interfaces/web pages/application UI(React/Tailwind/shadcn, aesthetics/usable/accessible).Both consume _shared/visual_qa, but figure is a DAG node producing a critical gate, while frontend is off-DAG pure tooling that produces no findings. To draw statistics charts for the paper → go to figure, not here.
  • and system-design (engineering on demand ②): frontend = interface/frontend; system-design = architectural layering/interfaces/data flow/(when needed) schema. To design backend architecture → go to system-design.
  • and file-reading (always resident): if you need to first understand the user-provided design draft/screenshot/Figma export → file-reading to understand it, then come here to build.
  • design token (v2 honest positioning): DTCG single source → multi-platform engineering used forwithin the user's project;v2 has no Light central visual SSOT(firsthand check: no db05, no design_tokens file, consistency does not cover visual tokens). If the same project also uses figure, color/font must be manually aligned by the user/overall controlmanual alignment。

name-reality alignment (honest lagging item, do not exaggerate)

  • "design" ≠ "automatically produce top-tier aesthetics": the hard increment of this skill isstatic three gates + real Chromium QA + online inspiration seeking + decision-point discipline;aesthetic high barstill relies on model taste + render-then-look human judgment; the script only catches the floor of "don't look AI at a glance, don't be unreadable, don't have hard layout errors,"does not guarantee "winning Awwwards"。
  • ai_tell_lint is heuristic, not final judgment: what it catches ishigh-frequency patterns of machine-flavor traces(T1–T8), not an "AI generation detector"; hits require human review (reasonable changelog version numbers, Chinese em dashes, and monochrome gradients have all been guarded against false positives, but it does not recognize new patterns).
  • contrast_lint only judges computable color contrast: pixel-level hierarchy/aesthetics/real readability must be actually looked at with render-then-look; and the contrast math reuses visual_qa (rounded to 3 decimal places, boundary values theoretically have extremely small errors).
  • browser_qa is not complete WCAG/Lighthouse: it really launches Chromium and tests three viewports, errors, overflow, basic name/alt, Tab reachability and focus heuristics, and outputs screenshot SHA; but it does not include axe, screen readers, or performance experiments; focus-style detection may miss/report falsely, and screenshots still require human/visual review.
  • design_delivery_gate only guards against overclaiming: It verifies user/inheritance decisions, date upper bounds, material source licenses, token/QA files and sha256, Chromium/contrast report status, three-viewport screenshot hashes and render-review metadata; it does not judge whether the aesthetics are top-tier, does not replace user taste choices, and is not research DAG findings.
  • .tsx is a reference snippet, not a runtime dependency：assets/ 's GSAP/Motion snippets are foruser projectsto use; this skill's script itself is pure stdlib, no npm install.
  • Zero local libraries = look up inspiration/versions online: but inspiration sites have many images and may be restricted by WebFetch (Mobbin/Dribbble) → honestly degrade to unavailable, do not pretend to have seen them.
  • Not a DAG node: this skill does not enter the research pipeline, does not produce findings, does not block; it is an on-demand tool to call when you need to build a UI, so do not expect it to be automatically orchestrated by the master control like mainline skills.