frontend-design
Skill0 starsChanged 5 months 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. Generates creative, polished code that avoids generic AI aesthetics.
187 other projects use a version of this, 128 of them edited.
Adopted by
Most recently taken up by
- RostislavDugin/postgresustheir own version, first seen Nov 8, 2026
- databasus/databasustheir own version, first seen Nov 8, 2026
- ceilf6/FrontAgenttheir own version, first seen Nov 8, 2026
- maxtrigify/Ottotheir own version, first seen Nov 8, 2026
- rvdbreemen/OTGW-firmwareedited, first seen Nov 8, 2026
- open-slide/open-slideedited, first seen Nov 8, 2026
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.
yawningwhaleAISkillinstantly-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
yawningwhaleAISkillalbert-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
naman10parikhSkillecosystem-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
naman10parikhSkillfractal-delegation
Also in 5 projects that use this
julianoczkowskiSkillbrief-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
SeifBenayedSkillfile-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
Other versions187 projects use a version of this.
Word for word · 0
None found.
Edited · 128
- bytedance/deer-flow★ 85k29% same
- novuhq/novu★ 40k50% same
- Dokploy/dokploy★ 38k52% same
- 1weiho/open-slide★ 9.7k50% same
- open-slide/open-slide★ 9.7k50% same
- basketikun/infinite-canvas★ 9.5k50% same
- mfts/papermark★ 9.2k50% same
- papermark/papermark★ 9.2k50% same
- anbeime/skill★ 7.9k49% same
- midudev/preguntas-entrevista-react★ 7.8k50% same
118 more not listed
Wrote their own version · 59
- anthropics/skills★ 189ksame name
- anthropics/claude-plugins-official★ 46ksame name
- markmead/hyperui★ 12ksame name
- mengxi-ream/read-frog★ 10ksame name
- databasus/databasus★ 9.3ksame name
- RostislavDugin/postgresus★ 9.3ksame name
- vudovn/ag-kit★ 8.2ksame name
- vudovn/antigravity-kit★ 8.2ksame name
- BuilderIO/agent-native★ 7.6ksame name
- nolly-studio/cult-ui★ 6.9ksame name
49 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository55 other files it gives its agents.
- AGENTS.mdAGENTS.md
- scripts/AGENTS.mdAGENTS.md
- src/AGENTS.mdAGENTS.md
- .cursor/rules/publish-version-bump.mdcCursor rule
- .cursor/rules/release-version-sync.mdcCursor rule
- antigravitySkill
- auditSkill
- autoplanSkill
- bootstrapSkill
- brainstormSkill
- browseSkill
- ceo-reviewSkill
- clarifySkill
- cleanupSkill
- code-reviewSkill
- codexSkill
- component-inventorySkill
- context-restoreSkill
- context-saveSkill
- critiqueSkill
- cronSkill
- csoSkill
- cursorSkill
- debugSkill
- deepen-planSkill
- design-reviewSkill
- devex-reviewSkill
- document-reviewSkill
- eng-reviewSkill
- executing-plansSkill
- fableSkill
- finishSkill
- grill-meSkill
- grokSkill
- implementSkill
- learnSkill
- office-hoursSkill
- onboardSkill
- plan-design-reviewSkill
- planSkill
- polishSkill
- qaSkill
- reviewSkill
- shipfastSkill
- shipthoroughSkill
- simplifySkill
- specSkill
- statusSkill
- subagent-driven-developmentSkill
- test-driven-developmentSkill
- ui-auditSkill
- ui-ux-pro-maxSkill
- using-git-worktreesSkill
- verification-before-completionSkill
- writing-plansSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
33 rules. 0 are common, 30 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 181 edited versions we read keep these.
30
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 9
If you are running this skill in Codex, read ../references/codex-compatibility.md before following host-specific tool instructions.
- Very specific: line 18
If docs/architecture/COMPONENTS.md exists, read it before creating or specifying UI components — reuse or extend an existing component on …
- Distinctive: line 29
Commit to a BOLD aesthetic direction:
- Distinctive: line 50
DO: Use a modular type scale with fluid sizing (clamp)
- Distinctive: line 52
DON'T: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults
- Distinctive: line 53
DON'T: Use monospace typography as lazy shorthand for "technical/developer" vibes
- Distinctive: line 54
DON'T: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated
- Distinctive: line 59
Commit to a cohesive palette.
- Distinctive: line 61
DO: Use modern CSS color functions (oklch, color-mix, light-dark) for perceptually uniform, maintainable palettes
- Distinctive: line 63
DON'T: Use gray text on colored backgrounds—it looks washed out.
- Distinctive: line 64
DON'T: Use pure black (#000) or pure white (#fff)—always tint.
- Distinctive: line 65
DON'T: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds
- Distinctive: line 66
DON'T: Use gradient text for "impact"—especially on metrics or headings.
- Distinctive: line 67
DON'T: Default to dark mode with glowing accents—it looks "cool" without requiring actual design decisions
- Distinctive: line 72
Create visual rhythm through varied spacing—not the same padding everywhere.
- Distinctive: line 74
DO: Create visual rhythm through varied spacing—tight groupings, generous separations
- Distinctive: line 75
DO: Use fluid spacing with clamp() that breathes on larger screens
- Distinctive: line 76
DO: Use asymmetry and unexpected compositions.
- Distinctive: line 79
DON'T: Use identical card grids—same-sized cards with icon + heading + text, repeated endlessly
- Distinctive: line 80
DON'T: Use the hero metric layout template—big number, small label, supporting stats, gradient accent
- Distinctive: line 82
DON'T: Use the same spacing everywhere—without rhythm, layouts feel monotonous
- Distinctive: line 85
DO: Use intentional, purposeful decorative elements that reinforce brand
- Distinctive: line 86
DON'T: Use glassmorphism everywhere—blur effects, glass cards, glow borders used decoratively rather than purposefully
- Distinctive: line 87
DON'T: Use rounded elements with thick colored border on one side—a lazy accent that almost never looks intentional
- Distinctive: line 88
DON'T: Use sparklines as decoration—tiny charts that look sophisticated but convey nothing meaningful
- Distinctive: line 89
DON'T: Use rounded rectangles with generic drop shadows—safe, forgettable, could be any AI output
- Distinctive: line 90
DON'T: Use modals unless there's truly no better alternative—modals are lazy
- Distinctive: line 97
DO: Use motion to convey state changes—entrances, exits, feedback
- Very specific: line 98
DO: Use exponential easing (ease-out-quart/quint/expo) for natural deceleration
- Distinctive: line 101
DON'T: Use bounce or elastic easing—they feel dated and tacky.
- Distinctive: line 108
DO: Use progressive disclosure—start simple, reveal sophistication through interaction (basic options first, advanced behind expandable …
- Distinctive: line 117
DO: Use container queries (@container) for component-level responsiveness
- Distinctive: line 131
Critical quality check: If you showed this interface to someone and said "AI made this," would they believe you immediately?
“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.
Files
Host Compatibility
If you are running this skill in Codex, read ../references/codex-compatibility.md before following host-specific tool instructions. Claude Code should continue to use the Claude-specific tools and command wrappers described here.
<!-- Vendored from impeccable v1.0.0 (Paul Bakaus, Apache 2.0). See skills/vendored/impeccable/LICENSE and skills/vendored/impeccable/NOTICE.md. -->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.
Before Generating: Reuse Check (Soloship override)
<!-- concern:component-reuse -->If docs/architecture/COMPONENTS.md exists, read it before creating or
specifying UI components — reuse or extend an existing component on purpose
match, cite what you found, and apply the rule of three (see
references/component-inventory.md). This skill generates new UI — which
makes it the primary place duplicates are born. Before writing any new
component, state what the inventory (or a git grep for likely names) showed
and whether you are reusing, extending, or creating — then design boldly
within that decision.
Design Direction
Commit to a BOLD aesthetic direction:
- 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, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
- Constraints: Technical requirements (framework, performance, accessibility).
- Differentiation: What makes this UNFORGETTABLE? What's the one thing someone will remember?
CRITICAL: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work—the key is intentionality, not intensity.
Then implement working code that is:
- Production-grade and functional
- Visually striking and memorable
- Cohesive with a clear aesthetic point-of-view
- Meticulously refined in every detail
Frontend Aesthetics Guidelines
Typography
→ Consult typography reference for scales, pairing, and loading strategies.
Choose fonts that are beautiful, unique, and interesting. Pair a distinctive display font with a refined body font.
DO: Use a modular type scale with fluid sizing (clamp) DO: Vary font weights and sizes to create clear visual hierarchy DON'T: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults DON'T: Use monospace typography as lazy shorthand for "technical/developer" vibes DON'T: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated
Color & Theme
→ Consult color reference for OKLCH, palettes, and dark mode.
Commit to a cohesive palette. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
DO: Use modern CSS color functions (oklch, color-mix, light-dark) for perceptually uniform, maintainable palettes DO: Tint your neutrals toward your brand hue—even a subtle hint creates subconscious cohesion DON'T: Use gray text on colored backgrounds—it looks washed out; use a shade of the background color instead DON'T: Use pure black (#000) or pure white (#fff)—always tint; pure black/white never appears in nature DON'T: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds DON'T: Use gradient text for "impact"—especially on metrics or headings; it's decorative rather than meaningful DON'T: Default to dark mode with glowing accents—it looks "cool" without requiring actual design decisions
Layout & Space
→ Consult spatial reference for grids, rhythm, and container queries.
Create visual rhythm through varied spacing—not the same padding everywhere. Embrace asymmetry and unexpected compositions. Break the grid intentionally for emphasis.
DO: Create visual rhythm through varied spacing—tight groupings, generous separations DO: Use fluid spacing with clamp() that breathes on larger screens DO: Use asymmetry and unexpected compositions; break the grid intentionally for emphasis DON'T: Wrap everything in cards—not everything needs a container DON'T: Nest cards inside cards—visual noise, flatten the hierarchy DON'T: Use identical card grids—same-sized cards with icon + heading + text, repeated endlessly DON'T: Use the hero metric layout template—big number, small label, supporting stats, gradient accent DON'T: Center everything—left-aligned text with asymmetric layouts feels more designed DON'T: Use the same spacing everywhere—without rhythm, layouts feel monotonous
Visual Details
DO: Use intentional, purposeful decorative elements that reinforce brand DON'T: Use glassmorphism everywhere—blur effects, glass cards, glow borders used decoratively rather than purposefully DON'T: Use rounded elements with thick colored border on one side—a lazy accent that almost never looks intentional DON'T: Use sparklines as decoration—tiny charts that look sophisticated but convey nothing meaningful DON'T: Use rounded rectangles with generic drop shadows—safe, forgettable, could be any AI output DON'T: Use modals unless there's truly no better alternative—modals are lazy
Motion
→ Consult motion reference for timing, easing, and reduced motion.
Focus on high-impact moments: one well-orchestrated page load with staggered reveals creates more delight than scattered micro-interactions.
DO: Use motion to convey state changes—entrances, exits, feedback DO: Use exponential easing (ease-out-quart/quint/expo) for natural deceleration DO: For height animations, use grid-template-rows transitions instead of animating height directly DON'T: Animate layout properties (width, height, padding, margin)—use transform and opacity only DON'T: Use bounce or elastic easing—they feel dated and tacky; real objects decelerate smoothly
Interaction
→ Consult interaction reference for forms, focus, and loading patterns.
Make interactions feel fast. Use optimistic UI—update immediately, sync later.
DO: Use progressive disclosure—start simple, reveal sophistication through interaction (basic options first, advanced behind expandable sections; hover states that reveal secondary actions) DO: Design empty states that teach the interface, not just say "nothing here" DO: Make every interactive surface feel intentional and responsive DON'T: Repeat the same information—redundant headers, intros that restate the heading DON'T: Make every button primary—use ghost buttons, text links, secondary styles; hierarchy matters
Responsive
→ Consult responsive reference for mobile-first, fluid design, and container queries.
DO: Use container queries (@container) for component-level responsiveness DO: Adapt the interface for different contexts—don't just shrink it DON'T: Hide critical functionality on mobile—adapt the interface, don't amputate it
UX Writing
→ Consult ux-writing reference for labels, errors, and empty states.
DO: Make every word earn its place DON'T: Repeat information users can already see
The AI Slop Test
Critical quality check: If you showed this interface to someone and said "AI made this," would they believe you immediately? If yes, that's the problem.
A distinctive interface should make someone ask "how was this made?" not "which AI made this?"
Review the DON'T guidelines above—they are the fingerprints of AI-generated work from 2024-2025.
Implementation Principles
Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details.
Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices across generations.
Remember: Claude is capable of extraordinary creative work. Don't hold back—show what can truly be created when thinking outside the box and committing fully to a distinctive vision.
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
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.

