agentleFS
thedigitalorganizerthedigitalorganizer/soloship/skills/frontend-design/SKILL.md

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

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

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
  1. Very specific:

    If you are running this skill in Codex, read ../references/codex-compatibility.md before following host-specific tool instructions.

    line 9
  2. Very specific:

    If docs/architecture/COMPONENTS.md exists, read it before creating or specifying UI components — reuse or extend an existing component on …

    line 18
  3. Distinctive:

    Commit to a BOLD aesthetic direction:

    line 29
  4. Distinctive:

    DO: Use a modular type scale with fluid sizing (clamp)

    line 50
  5. Distinctive:

    DON'T: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults

    line 52
  6. Distinctive:

    DON'T: Use monospace typography as lazy shorthand for "technical/developer" vibes

    line 53
  7. Distinctive:

    DON'T: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated

    line 54
  8. Distinctive:

    Commit to a cohesive palette.

    line 59
  9. Distinctive:

    DO: Use modern CSS color functions (oklch, color-mix, light-dark) for perceptually uniform, maintainable palettes

    line 61
  10. Distinctive:

    DON'T: Use gray text on colored backgrounds—it looks washed out.

    line 63
  11. Distinctive:

    DON'T: Use pure black (#000) or pure white (#fff)—always tint.

    line 64
  12. Distinctive:

    DON'T: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds

    line 65
  13. Distinctive:

    DON'T: Use gradient text for "impact"—especially on metrics or headings.

    line 66
  14. Distinctive:

    DON'T: Default to dark mode with glowing accents—it looks "cool" without requiring actual design decisions

    line 67
  15. Distinctive:

    Create visual rhythm through varied spacing—not the same padding everywhere.

    line 72
  16. Distinctive:

    DO: Create visual rhythm through varied spacing—tight groupings, generous separations

    line 74
  17. Distinctive:

    DO: Use fluid spacing with clamp() that breathes on larger screens

    line 75
  18. Distinctive:

    DO: Use asymmetry and unexpected compositions.

    line 76
  19. Distinctive:

    DON'T: Use identical card grids—same-sized cards with icon + heading + text, repeated endlessly

    line 79
  20. Distinctive:

    DON'T: Use the hero metric layout template—big number, small label, supporting stats, gradient accent

    line 80
  21. Distinctive:

    DON'T: Use the same spacing everywhere—without rhythm, layouts feel monotonous

    line 82
  22. Distinctive:

    DO: Use intentional, purposeful decorative elements that reinforce brand

    line 85
  23. Distinctive:

    DON'T: Use glassmorphism everywhere—blur effects, glass cards, glow borders used decoratively rather than purposefully

    line 86
  24. Distinctive:

    DON'T: Use rounded elements with thick colored border on one side—a lazy accent that almost never looks intentional

    line 87
  25. Distinctive:

    DON'T: Use sparklines as decoration—tiny charts that look sophisticated but convey nothing meaningful

    line 88
  26. Distinctive:

    DON'T: Use rounded rectangles with generic drop shadows—safe, forgettable, could be any AI output

    line 89
  27. Distinctive:

    DON'T: Use modals unless there's truly no better alternative—modals are lazy

    line 90
  28. Distinctive:

    DO: Use motion to convey state changes—entrances, exits, feedback

    line 97
  29. Very specific:

    DO: Use exponential easing (ease-out-quart/quint/expo) for natural deceleration

    line 98
  30. Distinctive:

    DON'T: Use bounce or elastic easing—they feel dated and tacky.

    line 101
  31. Distinctive:

    DO: Use progressive disclosure—start simple, reveal sophistication through interaction (basic options first, advanced behind expandable …

    line 108
  32. Distinctive:

    DO: Use container queries (@container) for component-level responsiveness

    line 117
  33. Distinctive:

    Critical quality check: If you showed this interface to someone and said "AI made this," would they believe you immediately?

    line 131

“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

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.

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.