| name | taste-skill |
| description | High-agency frontend design system for distinctive premium UI with anti-slop layout, motion, typography, and engineering rules. |
Taste Skill
Use this skill when you need a strong frontend point of view, not a safe default.
The goal is not "pretty enough." The goal is a frontend that feels intentional, premium, and hard to confuse with generic LLM output.
1. Active Baseline Configuration
DESIGN_VARIANCE: 8
1 = symmetric and quiet, 10 = asymmetric and experimentalMOTION_INTENSITY: 6
1 = nearly static, 10 = cinematic and highly reactiveVISUAL_DENSITY: 4
1 = airy gallery, 10 = dense cockpit
Treat these as working dials, not fixed constants.
- Do not ask the user to edit this file.
- Adapt the dials to the brief. If the user wants calmer output, lower them. If the user wants bolder output, raise them.
- Use the dials to drive layout, animation, spacing, and card usage.
2. Required Working Model
Before coding, establish three things:
- Visual thesis
One sentence for mood, material, and energy.
- Layout thesis
What makes the page memorable: asymmetry, crop, white space, stacked motion, split hero, bento rhythm, etc.
- Interaction thesis
Two or three motions that materially change the feel of the interface.
Then implement real code. Do not stop at design commentary.
- Do not leave "TODO: add animation here" style placeholders.
- Do not output fake code snippets for components that are supposed to be shipped.
- Do not ask for permission to make obvious design decisions once the brief is clear.
3. Architecture and Dependency Rules
Unless the user explicitly asks for something else, prefer React or Next.js.
Dependency verification
Before importing any third-party package:
- check
package.json
- if the package is missing, state the exact install command before using it
- never assume
framer-motion, lucide-react, zustand, or any font package is already installed
React and Next.js rules
- Default to server-safe structure in Next.js.
- Keep global state out of server components.
- If motion or highly interactive behavior is required, isolate it in a focused client component.
- Do not spread animation logic across an entire tree when one leaf component can own it.
Styling rules
- Use Tailwind for most styling unless the project clearly uses something else.
- Check whether the project is Tailwind v3 or v4 before writing config-sensitive code.
- Do not use v4 patterns in a v3 project.
Icon rules
- Prefer
@phosphor-icons/react or @radix-ui/react-icons when the project supports them.
- Keep icon stroke weight consistent across the page.
Hard bans
- No emojis in code, markup, UI copy, or alt text.
- No
h-screen heroes on mobile-sensitive layouts. Use min-h-[100dvh].
- No flexbox percentage math when grid solves the layout more cleanly.
4. Design Engineering Directives
LLMs drift toward familiar, overused UI patterns. Correct for that proactively.
Typography
- Default headline energy: large, tight, decisive.
- Avoid generic font stacks like Inter, Arial, Roboto, and raw system defaults when the brief calls for premium or creative work.
- Favor distinctive but disciplined display fonts such as Geist, Outfit, Cabinet Grotesk, or Satoshi.
- For dashboards and software UI, serif display choices are banned.
- Pair a strong display face with a quieter supporting face or mono.
Color
- Use a restrained neutral base plus one main accent.
- Keep accent saturation controlled.
- Avoid the default AI purple/blue glow aesthetic.
- Do not mix warm and cool gray systems randomly.
Layout
If DESIGN_VARIANCE > 4:
- do not center the entire hero by default
- avoid "headline + two buttons + card grid" as the first screen
- prefer split-screen, offset content, asymmetric negative space, anchored media, or broken-grid composition
Surfaces and cards
- Cards are not the default.
- Use cards only when elevation communicates hierarchy or interaction.
- For denser dashboards, prefer dividers, border rhythms, and spacing over endless card mosaics.
- If removing a card keeps the meaning intact, remove it.
Forms and states
Every serious surface needs full interaction coverage:
- loading state
- empty state
- error state
- success state
- tactile active state
For forms:
- label above input
- helper text optional but useful
- error text below input
- consistent vertical spacing
5. Motion System
Motion should create presence and hierarchy, not noise.
If MOTION_INTENSITY <= 3:
- limit motion to entrance, hover, and small affordance shifts
If MOTION_INTENSITY > 5:
- add continuous micro-interactions
- stagger reveals
- use spring-based motion
- make at least one interaction feel physically responsive
Preferred motion patterns
- staggered entrances
- layout transitions
- hover-aware buttons
- scroll-linked depth shifts
- type or shimmer loops for active interfaces
- floating or breathing status details
Magnetic interaction rule
If you build cursor-reactive magnetic behavior:
- do not use React
useState for per-frame cursor updates
- prefer motion values or equivalent render-loop-safe primitives
Motion quality bar
- no linear-by-default motion
- no gratuitous infinite animation without purpose
- no animation that only decorates and does not improve rhythm, focus, or affordance
6. Materiality and Visual Texture
When the design calls for glass or translucent layers:
- go beyond raw
backdrop-blur
- add a subtle inner border
- add a restrained inner highlight or inset shadow
Use atmosphere intentionally:
- gradient meshes
- noise overlays
- soft vignettes
- layered transparency
- controlled shadows
But:
- keep grain and noise on fixed overlays, not scrolling containers
- do not turn every section into a special effect
7. Performance Guardrails
Premium UI that performs badly is still bad UI.
- Animate
transform and opacity, not top, left, width, or height.
- Keep expensive effects off large scrolling surfaces.
- Avoid z-index spam.
- Memoize perpetual motion islands when needed.
- If using GSAP or Three.js for a special scene, isolate it. Do not mix heavy motion systems in the same component tree casually.
8. Pattern Library
Reach for a small number of stronger ideas instead of many weak ones.
Good first-view patterns
- split hero with anchored text and one dominant media plane
- asymmetrical bento section with varied tile weights
- editorial landing page with oversized type and sparse support copy
- product UI with calm structure, almost no decorative chrome, and a single strong accent
Good motion ideas
- sticky stack
- hover-aware directional fill
- shimmer skeletons that match final geometry
- typewriter or command-input loop
- coverflow or horizontal stream with clear narrative purpose
- floating toolbar or shared element transition
Patterns to avoid by default
- centered SaaS hero with floating dashboard mockup
- stat strip under every hero
- logo cloud as filler
- purple gradient on white
- card grid as the answer to every section
- random mixed font personalities
9. Delivery Standards
When using this skill, the implementation should leave the user with:
- real working code
- a clear visual thesis
- consistent motion language
- responsive behavior that survives desktop and mobile
- dependency calls called out if packages are missing
Do not:
- narrate the taste system instead of applying it
- fall back to generic component-library defaults
- leave unfinished sections because the "main idea" is done
10. Pre-flight Checklist
Before finalizing, check the result against this list:
- Is there one clear visual idea in the first viewport?
- Does the typography feel chosen rather than defaulted?
- Is the accent palette disciplined?
- Would this still look deliberate if all shadows were removed?
- Are cards being used because they are necessary, not because they are easy?
- Are motion choices noticeable but controlled?
- Are loading, empty, error, and active states covered where relevant?
- Is mobile stability handled, especially viewport height and overflow?
- Did you verify external dependencies before importing them?
- Does the output feel like a designed interface rather than assembled components?
