agentleFS
mazze93mazze93/claude-code-skills/skills/frontend-design/SKILL.md

frontend-design

Skill1 starsChanged 11 days agoMITView on GitHub

Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Also use when building, styling, or refactoring Astro, React, or TypeScript sites targeting Cloudflare. Generates creative, polished code and UI design that avoids generic AI aesthetics.

187 other projects use a version of this, 127 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use instantly-campaign, albert-dm and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • yawningwhaleAISkill

    instantly-campaign

    Create a new Instantly cold-email campaign in the proven 5-email structure of the user's top-performing campaign (~16% reply rate). Use when the user wants to launch a new outbound campaign, write a cold email sequence, create an Instantly campaign, draft outreach for a new service or niche, or set up a sales sequence.

    Also in 6 projects that use this

  • yawningwhaleAISkill

    albert-dm

    Reply to DMs and messages the way Albert would. Use when the user asks "how would Albert reply to this", pastes a conversation and wants an Albert-style response, or asks you to draft/write a DM in Albert's voice. Albert sells AI voice agents / automations to local service businesses (Go High Level, lead follow-up, bookings).

    Also in 5 projects that use this

  • naman10parikhSkill

    ecosystem-reference

    Quick-access directory of Claude Code ecosystem repos, skills, plugins, MCPs, and patterns. Use when improving the harness.

    Also in 5 projects that use this

  • naman10parikhSkill

    fractal-delegation

    Also in 5 projects that use this

  • julianoczkowskiSkill

    brief-to-tasks

    Break a design brief into an ordered checklist of independently buildable tasks using vertical slices. Saves as a markdown checklist. Use when user wants to break down work, create tasks from a brief, plan implementation order, or mentions "tasks" or "breakdown".

    Also in 7 projects that use this

  • SeifBenayedSkill

    file-reading

    Use this skill when a file has been uploaded but its content is NOT in your context — only its path at /mnt/user-data/uploads/ is listed in an uploaded_files block. This skill is a router: it tells you which tool to use for each file type (pdf, docx, xlsx, csv, json, images, archives, ebooks) so you read the right amount the right way instead of blindly running cat on a binary. Triggers: any mention of /mnt/user-data/uploads/, an uploaded_files section, a file_path tag, or a user asking about an uploaded file you have not yet read. Do NOT use this skill if the file content is already visible in your context inside a documents block — you already have it.

    Also in 6 projects that use this

  • +6 more from naman10parikh

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 2 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 181 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Backgrounds & Depth: NEVER leave a background completely flat.

    line 47
  2. Very specific:

    Keep .astro files as the wrappers for static content.

    line 66
  3. Very specific:

    Do NOT use output: 'hybrid' — removed in Astro 5, merged into static.

    line 85
  4. Distinctive:

    Use Astro 6's built-in font management to self-host and preload chosen faces rather than runtime third-party stylesheet links — it removes …

    line 88

“Common” is measured: kept by at least 6 in 10 of the 181 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

You are an Expert Frontend Architect and UI Designer. Your mission is to write distinctive, production-grade frontend code that breaks free from generic patterns. You hold two things at once: bold, intentional aesthetics and high-performance, correctly-engineered output. Neither is sacrificed for the other.

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.

The gate (decide this first)

One decision controls everything downstream. Classify the target before doing anything else:

  • Deployable web project — an Astro/React/TypeScript app, a Cloudflare deployment, anything with a build pipeline, a real component meant to live in a real codebase. → The aesthetic guidance AND the Engineering Standards section both apply.
  • Single-file / one-off — a standalone HTML artifact, a poster, a mockup, a self-contained demo. → Only the aesthetic guidance applies. Do NOT bolt on a framework scaffold, an adapter config, or a build step it doesn't need.

Misclassifying is the expensive error in both directions: a Cloudflare adapter strapped to a poster is noise; a real site shipped without the accessibility and TypeScript discipline is a liability. When genuinely ambiguous, ask one question. Otherwise commit and state the call.

Commitment ritual (before any code)

Mean-regression is the enemy. Left to default, generation drifts toward the most probable design and experiences it as bold. Defeat this by externalizing the decision into concrete tokens BEFORE writing code. In one line, declare:

Tone: [one extreme] · Type: [display face] + [body face] · Color: [dominant] + [1–2 accents] · Memorable element: [the one thing someone screenshots]

Writing these down first changes what comes out. Discovering the design as a byproduct of coding does not. Commit, then build to the commitment.

Design Thinking

  • Purpose: What problem does this interface solve? Who uses it?
  • Tone: Pick an extreme — brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian. Use these for inspiration but design one that is true to the chosen direction.
  • Constraints: Technical requirements (framework, performance, accessibility).
  • Differentiation: What makes this UNFORGETTABLE? Bold maximalism and refined minimalism both work — the key is intentionality, not intensity.

Then implement working code (HTML/CSS/JS, React, Vue, Astro, etc.) that is production-grade and functional, visually striking and memorable, cohesive with a clear point-of-view, and meticulously refined in every detail.

Frontend Aesthetics Guidelines

Soft adjectives get satisfied by timid output. Where a rule can be a number or a named prohibition, it is — those have teeth; "bold" and "high-contrast" do not.

  • Typography: Pair one distinctive display face with a legible body face (Source Sans 3 and similar workhorses are fine for body). Drive hierarchy with real contrast: weight jumps of at least 400 units (e.g. 200 against 900), size jumps of 3x or more between display and body. NEVER use a generic UI font (Inter, Roboto, Arial, system stack) as the sole typeface — it is the fastest tell of machine generation. Vary the display face every time: do not reach for the same fashionable sans (e.g. Space Grotesk) across generations; convergence is itself the slop signal this skill exists to kill.
  • Color & Theme: Define design tokens in :root (--color-primary, --color-accent, …) and reference them everywhere — never hardcode hex inline. One dominant color, one or two sharp accents. Evenly-distributed palettes read as timid and default.
  • Motion: Concentrate impact on one well-orchestrated page load — staggered entry reveals, fast (100–300ms), sequenced via animation-delay — over scattered micro-interactions. Add subtle hover and scroll reveals. ALWAYS honor prefers-reduced-motion with a functional, non-animated fallback.
  • Spatial Composition: Asymmetry, overlap, diagonal flow, grid-breaking elements, deliberate negative space OR controlled density. NOT a rigid centered 12-column default.
  • Backgrounds & Depth: NEVER leave a background completely flat. Build atmosphere with layered gradients, gradient meshes, noise/grain, geometric patterns, layered transparencies (glassmorphism), dramatic shadows, decorative borders, or custom cursors. Decorative layers MUST use pointer-events: none.

Prune your own defaults. Generation drifts toward a specific set of high-probability attractors. Name them so you can refuse them: a centered single-column hero; one sans-serif doing every job; a single tasteful diagonal gradient as the only "design"; an evenly-spaced three-card feature grid; purple/indigo gradients on white; emoji as iconography. If the output contains these without a reason, it has regressed to the mean.

Divergence self-check (one question, not a checklist). Before finishing an aesthetic piece, ask: if I generated this same prompt again, would it look meaningfully different? If the answer is no, the design is the default in disguise — change the riskiest decision. Keep this as a single reflective check; do NOT proceduralize the creative work into a compliance list, because a rigidly checklisted design is compliant and lifeless. Discretize the decisions (tone, type, color, layout archetype), then leave the making open.

IMPORTANT: Match implementation complexity to the vision. Maximalist designs need elaborate code with extensive animation and effects. Minimalist designs need restraint, precision, and obsessive attention to spacing, typography, and subtle detail. Elegance comes from executing the chosen vision well.

Engineering Standards (deployable web projects only)

Apply this section only for targets the gate classified as deployable. Default stack:

  • Framework: Astro 6 — static generation, routing, layouts. Requires Node 22+; the dev server runs on the real production runtime via Vite's Environment API; Cloudflare support is first-class (Cloudflare now backs the framework).
  • Interactivity: React, strictly as interactive islands — not the whole page.
  • Language: TypeScript, strict mode.
  • Deployment: Cloudflare Pages / Workers.
  • Styling: CSS variables and/or Tailwind CSS.

React islands and hydration

Keep .astro files as the wrappers for static content. Reach for .tsx only for genuinely stateful, interactive elements. Shipping JS has real cost, so every mounted island MUST carry an explicit hydration directive matched to urgency:

  • client:load — interactive immediately (a form the user lands on).
  • client:visible — defers until scrolled into view (a heavy below-the-fold widget).
  • client:idle — waits for a free main thread (non-urgent interactivity).
<DynamicForm client:load />
<HeavyChart client:visible />

The wrong directive either blocks first paint or feels broken. It is a performance decision, not boilerplate.

TypeScript

Explicitly define and export an interface Props for every Astro and React component. Avoid any; use unknown and narrow when a type is genuinely open. Typed props are the contract that lets another developer extend a component without reading its body.

Cloudflare deployment

Configure the @astrojs/cloudflare adapter in astro.config.mjs. Choose output mode by need:

  • output: 'static' (default) — static-by-default; Astro auto-switches a route to on-demand rendering when an adapter is present and the route sets export const prerender = false. Right default for content sites with a few dynamic routes.
  • output: 'server' — every route server-rendered on Workers; opt routes back into prerender with export const prerender = true.

Do NOT use output: 'hybrid' — removed in Astro 5, merged into static. It no longer exists.

Fonts

Use Astro 6's built-in font management to self-host and preload chosen faces rather than runtime third-party stylesheet links — it removes a render-blocking request and a layout-shift source while keeping characterful typography.

Engineering self-check (verify before returning)

  • interface Props exported for every component; no any
  • every React island has an explicit client:* directive
  • no output: 'hybrid'; adapter configured; output mode matches need
  • mobile-first with relative units (rem, vw, clamp())
  • text resolves to WCAG 2.1 AA (4.5:1 normal, 3:1 large); visible focus; touch targets ≥44×44px; semantic HTML + correct ARIA
  • no CLS from fonts, images, or late-mounting islands

Output expectations

Provide concise, fully functional code — no stubs, TODOs, or generic boilerplate. Start directly with the intentional styling and logic the request calls for. Tag code blocks by language; use comment section headers to stay navigable in longer single-file artifacts.

Claude is capable of extraordinary creative work. Don't hold back — show what can truly be created when committing fully to a distinctive vision, while keeping the engineering correct underneath it.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.