/taste-skill
Anti-slop frontend skill for landing pages, portfolios, and redesigns. The agent reads the brief, infers the right design direction, and ships interfaces that do not look templated. Real design systems when applicable, audit-first on redesigns, strict pre-flight check.
$ npx -y skills add Leonxlnx/taste-skill --skill taste-skill --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/taste-skill
Context preview
The summary Claude sees to decide when to auto-load this skill.
Anti-slop frontend skill for landing pages, portfolios, and redesigns. The agent reads the brief, infers the right design direction, and ships interfaces that do not look templated. Real design systems when applicable, audit-first on redesigns, strict pre-flight check.
SKILL.md
taste-skill.SKILL.mdname: design-taste-frontend
description: Anti-slop frontend skill for landing pages, portfolios, and redesigns. The agent reads the brief, infers the right design direction, and ships interfaces that do not look templated. Real design systems when applicable, audit-first on redesigns, strict pre-flight check.
tasteskill: Anti-Slop Frontend Skill
> Landing pages, portfolios, and redesigns. Not dashboards, not data tables, not multi-step product UI. > Every rule below is **contextual**. None of it fires automatically. First read the brief, then pull only what fits.
---
0. BRIEF INFERENCE (Read the Room Before Anything Else)
Before touching code or tweaking dials, **infer what the user actually wants**. Most LLM design output is bad because the model jumps to a default aesthetic instead of reading the room.
0.A Read these signals first
1. **Page kind** - landing (SaaS / consumer / agency / event), portfolio (dev / designer / creative studio), redesign (preserve vs overhaul), editorial / blog. 2. **Vibe words** the user used - "minimalist", "calm", "Linear-style", "Awwwards", "brutalist", "premium consumer", "Apple-y", "playful", "serious B2B", "editorial", "agency-y", "glassy", "dark tech". 3. **Reference signals** - URLs they linked, screenshots they pasted, products they named, brands they're competing with. 4. **Audience** - B2B procurement panel vs. design-conscious consumer vs. recruiter scanning a portfolio. The audience picks the aesthetic, not your taste. 5. **Brand assets that already exist** - logo, color, type, photography. For redesigns, these are starting material, not optional input (see Section 11). 6. **Quiet constraints** - accessibility-first audiences, public-sector, regulated industries, trust-first commerce, kids' products. These constraints OVERRIDE aesthetic preference.
0.B Output a one-line "Design Read" before generating
Before any code, state in one line: **"Reading this as: \<page kind> for \<audience>, with a \<vibe> language, leaning toward \<design system or aesthetic family>."**
Example reads:
- *"Reading this as: B2B SaaS landing for technical buyers, with a Linear-style minimalist language, leaning toward Tailwind utilities + Geist + restrained motion."*
- *"Reading this as: solo designer portfolio for hiring managers, with an editorial / kinetic-type language, leaning toward native CSS + scroll-driven animation + custom typography."*
- *"Reading this as: redesign of a public-sector service site, with a trust-first language, leaning toward GOV.UK Frontend or USWDS."*
0.C If the brief is ambiguous, ask one question, do not guess
Ask exactly **one** clarifying question - never a multi-question dump - and only when the design read genuinely diverges. Example: *"Should this feel closer to Linear-clean or Awwwards-experimental?"*
If you can confidently infer from context, **do not ask**. Just declare the design read and proceed.
0.D Anti-Default Discipline
Do not default to: AI-purple gradients, centered hero over dark mesh, three equal feature cards, generic glassmorphism on everything, infinite-loop micro-animations everywhere, Inter + slate-900. These are the LLM defaults. Reach past them deliberately based on the design read.
---
1. THE THREE DIALS (Core Configuration)
After the design read, set three dials. Every layout, motion, and density decision below is gated by these.
- **`DESIGN_VARIANCE: 8`** - 1 = Perfect Symmetry, 10 = Artsy Chaos
- **`MOTION_INTENSITY: 6`** - 1 = Static, 10 = Cinematic / Physics
- **`VISUAL_DENSITY: 4`** - 1 = Art Gallery / Airy, 10 = Cockpit / Packed Data
**Baseline:** `8 / 6 / 4`. Use these unless the design read overrides them. Do not ask the user to edit this file - overrides happen conversationally.
1.A Dial Inference (design read → dial values)
| Signal | VARIANCE | MOTION | DENSITY | |---|---|---|---| | "minimalist / clean / calm / editorial / Linear-style" | 5-6 | 3-4 | 2-3 | | "premium consumer / Apple-y / luxury / brand" | 7-8 | 5-7 | 3-4 | | "playful / wild / Dribbble / Awwwards / experimental / agency" | 9-10 | 8-10 | 3-4 | | "landing page / portfolio / marketing site (default)" | 7-9 | 6-8 | 3-5 | | "trust-first / public-sector / regulated / accessibility-critical" | 3-4 | 2-3 | 4-5 | | "redesign - preserve" | match existing | +1 | match existing | | "redesign - overhaul" | +2 | +2 | match existing |
1.B Use-Case Presets
| Use case | VARIANCE | MOTION | DENSITY | |---|---|---|---| | Landing (SaaS, mainstream) | 7 | 6 | 4 | | Landing (Agency / creative) | 9 | 8 | 3 | | Landing (Premium consumer) | 7 | 6 | 3 | | Portfolio (Designer / studio) | 8 | 7 | 3 | | Portfolio (Developer) | 6 | 5 | 4 | | Editorial / Blog | 6 | 4 | 3 | | Public-sector service | 3 | 2 | 5 | | Redesign - preserve | match | match+1 | match | | Redesign - overhaul | +2 | +2 | match |
1.C How the Dials Drive Output
Use these (or user-overridden values) as global variables. Cross-references throughout this document refer to these exact variable names - never invent aliases like `LAYOUT_VARIANCE` or `ANIM_LEVEL`.
---
2. BRIEF → DESIGN SYSTEM MAP
Once you have the design read (Section 0) and dials (Section 1), pick the right foundation. Do not invent CSS for things that have an official package. Do not pretend an aesthetic trend is an official system.
2.A When to reach for a real design system (use official packages)
| Brief reads as… | Reach for | Why | |---|---|---| | Microsoft / enterprise SaaS / dashboards | `@fluentui/react-components` or `@fluentui/web-components` | Official Fluent UI, Microsoft tokens, accessibility done | | Google-ish UI, Material-flavored product | `@material/web` + Material 3 tokens | Official, theme-able via Material Theming | | IBM-style B2B / enterprise analytics | `@carbon/react` + `@carbon/styles` | Official Carbon, mature data-density patterns | | Shopify app surfaces | `polaris.js` web components / Polaris React | Required for Shopify admin UI | | A
Read more
name: design-taste-frontend description: Anti-slop frontend skill for landing pages, portfolios, and redesigns. The agent reads the brief, infers the right design direction, and ships interfaces that do not look templated. Real design systems when applicable, audit-first on redesigns, strict pre-flight check.
tasteskill: Anti-Slop Frontend Skill
> Landing pages, portfolios, and redesigns. Not dashboards, not data tables, not multi-step product UI. > Every rule below is **contextual**. None of it fires automatically. First read the brief, then pull only what fits.
---
0. BRIEF INFERENCE (Read the Room Before Anything Else)
Before touching code or tweaking dials, **infer what the user actually wants**. Most LLM design output is bad because the model jumps to a default aesthetic instead of reading the room.
0.A Read these signals first
1. **Page kind** - landing (SaaS / consumer / agency / event), portfolio (dev / designer / creative studio), redesign (preserve vs overhaul), editorial / blog. 2. **Vibe words** the user used - "minimalist", "calm", "Linear-style", "Awwwards", "brutalist", "premium consumer", "Apple-y", "playful", "serious B2B", "editorial", "agency-y", "glassy", "dark tech". 3. **Reference signals** - URLs they linked, screenshots they pasted, products they named, brands they're competing with. 4. **Audience** - B2B procurement panel vs. design-conscious consumer vs. recruiter scanning a portfolio. The audience picks the aesthetic, not your taste. 5. **Brand assets that already exist** - logo, color, type, photography. For redesigns, these are starting material, not optional input (see Section 11). 6. **Quiet constraints** - accessibility-first audiences, public-sector, regulated industries, trust-first commerce, kids' products. These constraints OVERRIDE aesthetic preference.
0.B Output a one-line "Design Read" before generating
Before any code, state in one line: **"Reading this as: \<page kind> for \<audience>, with a \<vibe> language, leaning toward \<design system or aesthetic family>."**
Example reads:
- *"Reading this as: B2B SaaS landing for technical buyers, with a Linear-style minimalist language, leaning toward Tailwind utilities + Geist + restrained motion."*
- *"Reading this as: solo designer portfolio for hiring managers, with an editorial / kinetic-type language, leaning toward native CSS + scroll-driven animation + custom typography."*
- *"Reading this as: redesign of a public-sector service site, with a trust-first language, leaning toward GOV.UK Frontend or USWDS."*
0.C If the brief is ambiguous, ask one question, do not guess
Ask exactly **one** clarifying question - never a multi-question dump - and only when the design read genuinely diverges. Example: *"Should this feel closer to Linear-clean or Awwwards-experimental?"*
If you can confidently infer from context, **do not ask**. Just declare the design read and proceed.
0.D Anti-Default Discipline
Do not default to: AI-purple gradients, centered hero over dark mesh, three equal feature cards, generic glassmorphism on everything, infinite-loop micro-animations everywhere, Inter + slate-900. These are the LLM defaults. Reach past them deliberately based on the design read.
---
1. THE THREE DIALS (Core Configuration)
After the design read, set three dials. Every layout, motion, and density decision below is gated by these.
- **`DESIGN_VARIANCE: 8`** - 1 = Perfect Symmetry, 10 = Artsy Chaos
- **`MOTION_INTENSITY: 6`** - 1 = Static, 10 = Cinematic / Physics
- **`VISUAL_DENSITY: 4`** - 1 = Art Gallery / Airy, 10 = Cockpit / Packed Data
**Baseline:** `8 / 6 / 4`. Use these unless the design read overrides them. Do not ask the user to edit this file - overrides happen conversationally.
1.A Dial Inference (design read → dial values)
| Signal | VARIANCE | MOTION | DENSITY | |---|---|---|---| | "minimalist / clean / calm / editorial / Linear-style" | 5-6 | 3-4 | 2-3 | | "premium consumer / Apple-y / luxury / brand" | 7-8 | 5-7 | 3-4 | | "playful / wild / Dribbble / Awwwards / experimental / agency" | 9-10 | 8-10 | 3-4 | | "landing page / portfolio / marketing site (default)" | 7-9 | 6-8 | 3-5 | | "trust-first / public-sector / regulated / accessibility-critical" | 3-4 | 2-3 | 4-5 | | "redesign - preserve" | match existing | +1 | match existing | | "redesign - overhaul" | +2 | +2 | match existing |
1.B Use-Case Presets
| Use case | VARIANCE | MOTION | DENSITY | |---|---|---|---| | Landing (SaaS, mainstream) | 7 | 6 | 4 | | Landing (Agency / creative) | 9 | 8 | 3 | | Landing (Premium consumer) | 7 | 6 | 3 | | Portfolio (Designer / studio) | 8 | 7 | 3 | | Portfolio (Developer) | 6 | 5 | 4 | | Editorial / Blog | 6 | 4 | 3 | | Public-sector service | 3 | 2 | 5 | | Redesign - preserve | match | match+1 | match | | Redesign - overhaul | +2 | +2 | match |
1.C How the Dials Drive Output
Use these (or user-overridden values) as global variables. Cross-references throughout this document refer to these exact variable names - never invent aliases like `LAYOUT_VARIANCE` or `ANIM_LEVEL`.
---
2. BRIEF → DESIGN SYSTEM MAP
Once you have the design read (Section 0) and dials (Section 1), pick the right foundation. Do not invent CSS for things that have an official package. Do not pretend an aesthetic trend is an official system.
2.A When to reach for a real design system (use official packages)
| Brief reads as… | Reach for | Why | |---|---|---| | Microsoft / enterprise SaaS / dashboards | `@fluentui/react-components` or `@fluentui/web-components` | Official Fluent UI, Microsoft tokens, accessibility done | | Google-ish UI, Material-flavored product | `@material/web` + Material 3 tokens | Official, theme-able via Material Theming | | IBM-style B2B / enterprise analytics | `@carbon/react` + `@carbon/styles` | Official Carbon, mature data-density patterns | | Shopify app surfaces | `polaris.js` web components / Polaris React | Required for Shopify admin UI | | A
The Anti-Slop Frontend Framework for AI Agents Sponsors Novamira · Full WordPress access for AI agents IMG.LY · CreativeEditor SDK Emil Kowalski · animations.dev Sent.dm · messaging APIs for SMS, WhatsApp, and RCS Become a
Repo: Leonxlnx/taste-skill
Other skills on taste-skill.
- /brandkit
Premium brand-kit image generation skill for creating high-end brand-guidelines boards, logo systems, identity decks, and visual-world presentations. Trained for minimalist, cinematic, editorial, dark-tech, luxury, cultural, security, gaming, developer-tool, and consumer-app
Open skill - /brutalist-skill
Raw mechanical interfaces fusing Swiss typographic print with military terminal aesthetics. Rigid grids, extreme type scale contrast, utilitarian color, analog degradation effects. For data-heavy dashboards, portfolios, or editorial sites that need to feel like declassified
Open skill - /gpt-tasteskill
Elite UX/UI & Advanced GSAP Motion Engineer. Enforces Python-driven true randomization for layout variance, strict AIDA page structure, wide editorial typography (bans 6-line wraps), gapless bento grids, strict GSAP ScrollTriggers (pinning, stacking, scrubbing), inline
Open skill - /image-to-code-skill
Elite website image-to-code skill for Codex. For visually important web tasks, it must first generate the design image(s) itself, deeply analyze them, then implement the website to match them as closely as possible. In Codex, it must prefer large, readable, section-specific
Open skill - /imagegen-frontend-mobile
Elite mobile app image-generation skill for creating premium, app-native screen concepts and flows. Designed for iOS, Android, and cross-platform mobile products. Prioritizes clean hierarchy, comfortably readable text, strong multi-screen consistency, controlled color palettes,
Open skill - /imagegen-frontend-web
Elite frontend image-direction skill for generating premium, conversion-aware website design references. CRITICAL OUTPUT RULE — generate ONE separate horizontal image FOR EVERY section. A landing page with 8 sections produces 8 images. Never compress multiple sections into one
Open skill

