Taste Skill: The Anti-Slop Frontend Skill Library

Taste Skill (Leonxlnx/taste-skill) is an MIT-licensed library of 13 Agent Skills that load frontend design rules into a coding agent before it writes markup. The default skill, design-taste-frontend, infers a design direction from the brief, sets three dials, and bans common AI-generated UI patterns. It targets landing pages, portfolios, and redesigns, not dashboards.

This page is for frontend developers who generate marketing pages with Claude Code, Codex, or Cursor, and for tech leads who have to decide whether that output can merge. The situation: the agent’s landing page works, but it has the purple gradient, three identical feature cards, a 001 · Capabilities eyebrow, and a fake dashboard built from styled div elements. Nobody on the team can say what “less generic” means in a pull request review.

As of 2026-09-26, Leonxlnx/taste-skill has 90.2k GitHub stars (read on GitHub). skills.sh lists 520,147 installs of design-taste-frontend, a SECONDARY figure from the third-party LinklyAI/best-skills scrape of the same date; re-read it on skills.sh before quoting it. This page was checked against commit ce26fc2 on main (2026-09-26), the skills CLI 1.7.0, Claude Code 2.1.285, and codex-cli 0.157.1.

What you’ll walk away with from Taste Skill

• A pinned, project-scope install for Claude Code, Codex, and Cursor, and the one naming trap that makes installs silently do nothing.
• Which of the 13 skills to install for greenfield pages, redesigns, and image-first work.
• Three copy-paste prompts: a build that stops for your approval of the direction, an evidence-only review, and a redesign that cannot touch routes or analytics.
• A shell gate and a Playwright spec that check the skill’s hard rules in CI, so nobody reads the CSS line by line.
• Recovery steps for the ways Taste Skill fights your stack, your house style, and your other design skills.

Install Taste Skill in Claude Code, Codex, or Cursor

Taste Skill is a set of SKILL.md files, not an MCP server, a model, or a CLI. It installs through the skills CLI. The repository has no release tags, so pin a commit SHA: the default skill is labelled “v2 (experimental)” and its maintainers say refinements “may land in any v2 experimental release”.

Claude Code

# Terminal, project root. Pin the commit you reviewed.
npx skills add "Leonxlnx/taste-skill#ce26fc25c0e5e8cab638f883de62d9a86ee5e45b" \
  --skill design-taste-frontend -a claude-code

The CLI writes the file to .agents/skills/design-taste-frontend/SKILL.md, symlinks it into .claude/skills/, and records the source, ref, and hash in skills-lock.json. Invoke it with /design-taste-frontend, or let Claude load it when the request matches its description.

The repository also ships a Claude Code marketplace. The plugin carries all 13 skills under one namespace, so use it only if you want the whole bundle:

/plugin marketplace add Leonxlnx/taste-skill
/plugin install taste-skill@taste-skill

Codex

# Terminal, project root
npx skills add "Leonxlnx/taste-skill#ce26fc25c0e5e8cab638f883de62d9a86ee5e45b" \
  --skill design-taste-frontend -a codex

Codex reads project skills from .agents/skills/. Invoke the skill with a $ mention, for example $design-taste-frontend build the pricing page. The repository has no Codex plugin manifest (checked at ce26fc2), so install with the skills CLI or copy the SKILL.md folder into .agents/skills/ by hand.

Cursor

# Terminal, project root
npx skills add "Leonxlnx/taste-skill#ce26fc25c0e5e8cab638f883de62d9a86ee5e45b" \
  --skill design-taste-frontend -a cursor

The CLI writes Cursor’s project copy to .agents/skills/. Cursor’s agent loads it when the request matches its description. Cursor’s documentation was unreachable when this page was checked, so confirm the install (and how to invoke it explicitly) by asking the agent which skills it can see.

To install for all three agents at once, pass -a claude-code codex cursor. Commit .agents/skills/, .claude/skills/, and skills-lock.json, and add the drift check from the skills team workflow so a hand edit or an unreviewed update fails CI.

The install name is not the folder name

The default skill lives in skills/taste-skill/ but installs as design-taste-frontend. With --skill taste-skill, the CLI 1.7.0 finds no match, prints the list of valid names, and installs nothing. Run npx skills add Leonxlnx/taste-skill --list to see the install names.

Context cost. Only each skill’s name and description sit in context until the skill is used. When design-taste-frontend loads, it brings a 1,206-line, roughly 87 KB file (12,800 words) with it. In Claude Code, run /context before and after invoking it to see what it costs your session. For the plugin route, claude plugin details taste-skill prints the projected token cost.

Which of the 13 Taste Skill variants should you install?

Install one skill per job. Two skills from this bundle loaded on the same request give the agent two procedures to reconcile.

Install name (--skill)	Output	Reach for it when
design-taste-frontend	Code	The default: a new landing page, portfolio, or marketing site
design-taste-frontend-v1	Code	You depend on the pre-v2 behaviour exactly
redesign-existing-projects	Code	An existing site needs modernising, audit first
gpt-taste	Code	You want stricter GSAP motion and more layout variance, tuned for GPT models
high-end-visual-design	Code	The direction is already “soft”: calm, premium, spring motion
minimalist-ui	Code	The direction is editorial, Notion or Linear style
industrial-brutalist-ui	Code	The direction is Swiss type, hard contrast, rigid grids
full-output-enforcement	Code	The agent keeps leaving placeholder comments instead of finished code
stitch-design-taste	Rules, optional DESIGN.md	You design in Google Stitch and want its rules, or a DESIGN.md export
image-to-code	Images, then code	You want reference frames generated, analysed, then implemented
imagegen-frontend-web	Images only	You need website comps, one image per section
imagegen-frontend-mobile	Images only	You need iOS or Android screen concepts in phone mockups
brandkit	Images only	You need logo, palette, and type boards

gpt-taste makes the model simulate a seeded random.choice() (the seed comes from the prompt’s length) to pick layouts, so different briefs get different layouts. The draw is simulated by the model, not executed, so do not rely on it for reproducible output either way.

How does design-taste-frontend decide what to build?

The default skill is a pipeline the agent runs in order. Section numbers below are the skill’s own, so you can point the agent at them.

1. Brief inference (§0). The agent reads page kind, vibe words, references, audience, and constraints, then writes a one-line “Design Read”. If the brief is ambiguous, it asks one question instead of guessing.

2. Three dials (§1). DESIGN_VARIANCE, MOTION_INTENSITY, and VISUAL_DENSITY, each 1 to 10, gate every layout, motion, and density decision. The baseline is 8 / 6 / 4. The skill infers values from the brief (a trust-first or public-sector brief drops to 3-4 / 2-3 / 4-5; an agency or Awwwards brief rises to 9-10 / 8-10 / 3-4) and you override them in the conversation, not by editing the file.

3. Design-system map (§2). A brief that reads as Material, Fluent, Carbon, Polaris, Atlassian, Primer, GOV.UK, USWDS, Bootstrap, Radix, shadcn, or Tailwind gets the official package. An aesthetic such as bento, brutalism, or glassmorphism gets web standards, and the skill labels Apple’s Liquid Glass as a web approximation rather than an official package.

4. Generate against the stack defaults (§3: React or Next.js, Tailwind v4, Motion from motion/react) and the bans in §9.

5. Final pre-flight check (§14). A checklist of 62 items that must all pass before the agent calls the work done: consistency locks, contrast, hero limits, reduced motion, and “motion claimed = motion shown”.

§13 puts dashboards, admin panels, data tables, multi-step forms, code editors, native mobile, and real-time collaboration UIs out of scope. On those, the skill tells the agent to say so, point to the right tool (Fluent or Carbon for dashboards, TanStack Table or AG Grid for tables, Monaco for editors), and apply only its marketing-page rules where they fit.

What does the Taste Skill ban list forbid?

Section 9, “AI Tells”, is why teams install the skill. A representative slice:

• Visual: neon outer glows, pure #000000, oversaturated accents, gradient text on large headings, custom cursors, and the “AI purple” default unless the brand is purple.
• Layout: three equal feature cards in a row, border-t plus border-b on every row of a long list, and the same layout family repeated (the pre-flight asks for at least four families across eight sections).
• Content: “John Doe” names, “Acme” brands, 99.99% numbers, filler verbs such as “Elevate” and “Seamless”, section-number eyebrows (001 · Capabilities), BETA labels in the hero, scroll cues, and city-and-weather strips.
• Fakery: product UI built from div rectangles to look like a screenshot, and decorative photo credits for stock images.

It also imposes locks: one accent colour, one corner-radius system, and one page theme with no mid-page light and dark flips. The hero headline stays within two lines, the subtext within 20 words, the primary call to action above the fold, and the navigation on one line no taller than 80px.

The em-dash ban is absolute

§9.G bans the em dash and the en dash as a separator anywhere a visitor can read them: headings, body, captions, button labels, and alt text. The skill calls it “the single most-violated Tell”, and one dash fails the pre-flight. §9.G allows no exceptions, so a brief-level override may not hold; keep the skill off surfaces whose voice needs dashes (for example, do not invoke it for /blog) and exclude those paths from taste-gate.sh (see when Taste Skill fights your house style).

Build a landing page with Taste Skill, from brief to merged pull request

This is the loop the skill fits into: agree on a direction, build, verify with machines, review against evidence, then ship. The human decision happens once, at the direction, and not at every line of CSS.

1. Write the brief with the facts the skill cannot infer. Audience, the one action the page must drive, brand colour and fonts, and any reference sites. For a larger surface, run the four-artifact design-to-code pipeline first and hand its design contract to the agent.

2. Build with an approval stop. The prompt below makes the agent commit to a Design Read and dial values before it writes code, so a product or design owner approves the direction in one message.

3. Run the deterministic gate and the Playwright spec from the next section. Fix every failure before review.

4. Review in a fresh session with the evidence-only prompt. A reviewer that did not write the page checks the pre-flight items against files and screenshots, not against the author’s claims.

5. Merge on green CI plus the owner’s look at the screenshots at desktop and mobile widths.

Copy-paste prompt: build a landing page with an approval stop

Use the design-taste-frontend skill. Build the landing page for Ledgerline, a
bookkeeping tool for independent restaurants, in app/(marketing)/page.tsx.
Audience: restaurant owners, not accountants. The only conversion goal is
"Start free trial". Brand accent is #1F6F5B; keep our existing Geist font.

Before writing any code:
1. Give me your one-line Design Read (§0.B).
2. State the three dial values you chose and why, if they differ from 8/6/4.
3. Name the design system from §2 you will use, or say it is an aesthetic.
4. List every new dependency you would add, with its install command.
Then stop and wait for my approval.

After I approve: build the page, give the primary CTA data-testid="primary-cta",
run the §14 pre-flight, and report each item as PASS or FAIL with the file and
line that proves it. Do not mark an item PASS without evidence.

How do you verify Taste Skill output without reading every line?

The pre-flight is the agent grading its own work. Treat it as a claim to check, not as proof. Several of the skill’s hard rules are mechanical, so a script can enforce them.

A source gate. Save this as scripts/taste-gate.sh and run it in CI and in the agent’s loop. It exits non-zero on any finding:

#!/usr/bin/env bash
# scripts/taste-gate.sh: deterministic checks for Taste Skill's hard rules.
# Usage: scripts/taste-gate.sh [dir ...]   (default: src)
set -u
dirs=("${@:-src}")
inc=(--include='*.tsx' --include='*.jsx' --include='*.ts' --include='*.js'
     --include='*.html' --include='*.mdx' --include='*.vue' --include='*.svelte' --include='*.astro')
fail=0
check() {  # $1 = label, $2 = extended regex
  if grep -rnE "${inc[@]}" -- "$2" "${dirs[@]}"; then
    echo "FAIL: $1" >&2; fail=1
  fi
}
for d in "${dirs[@]}"; do [ -d "$d" ] || { echo "FAIL: no such dir $d" >&2; exit 2; }; done
check "em or en dash in shipped text (§9.G)"      '—|–'
check "raw scroll listener (§5.D)"                 "addEventListener\(['\"]scroll"
check "h-screen (use min-h-[100dvh] for full-height sections, §3.E)" '(^|[^-])\bh-screen\b'
check "section-number eyebrow (§9.F)"              '\b0{1,2}[0-9] ?(·|/) ?[A-Za-z]'
exit "$fail"

The dash check also flags dashes in code comments. Keep comments dash-free in the marketing directory, or point the script at the components that render copy. The h-screen check flags every h-screen, including sidebars and modals, so point the script at the marketing directory only.

A rendered-page spec. Source greps miss text that arrives from a CMS. This Playwright spec (with @playwright/test and @axe-core/playwright) checks what a visitor sees at two widths:

tests/landing.taste.spec.ts

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

for (const viewport of [{ width: 1440, height: 900 }, { width: 390, height: 844 }]) {
  test(`landing page meets Taste Skill rules at ${viewport.width}px`, async ({ page }) => {
    await page.setViewportSize(viewport);
    await page.goto('/');

    const text = await page.locator('body').innerText();
    const alts = await page.locator('img').evaluateAll((imgs) => imgs.map((i) => i.getAttribute('alt') ?? '').join(' '));
    expect(text + alts).not.toMatch(/[–—]/); // §9.G

    const cta = await page.getByTestId('primary-cta').boundingBox(); // hero: CTA above the fold
    expect(cta).not.toBeNull();
    expect(cta!.y + cta!.height).toBeLessThanOrEqual(viewport.height);

    const a11y = await new AxeBuilder({ page }).withTags(['wcag2a', 'wcag2aa']).analyze();
    expect(a11y.violations).toEqual([]);

    await expect(page).toHaveScreenshot(`landing-${viewport.width}.png`, { fullPage: true });
  });
}

Create the baselines once with npx playwright test --update-snapshots and commit them. Otherwise the first CI run fails with “snapshot doesn’t exist”. The screenshots become the review artifact. For the wider practice, see end-to-end testing, accessibility testing, and catching slop before merge. To let the agent look at its own running page between iterations, add agent-browser.

Who signs off. The product or design owner approves the Design Read and dials before the build and the screenshots after it. CI owns the gate script, the spec, and the accessibility scan. The reviewer session owns the evidence check. Nobody signs off on “it looks less generic” without a screenshot in the pull request.

Copy-paste prompt: evidence-only review of a Taste Skill page

You are reviewing, not building. Do not edit any file.
Read the design-taste-frontend skill's §9 and §14, then review the diff of this
branch against main for the marketing page.

For each §14 item that applies, output one line:
PASS | FAIL | CANNOT VERIFY - item - evidence (file:line, or the screenshot name
in tests/landing.taste.spec.ts-snapshots/, or the diff in test-results/ on failure)
Rules: the author's own pre-flight report is not evidence. An item with no file
or screenshot behind it is CANNOT VERIFY, not PASS. List every FAIL first, then
every CANNOT VERIFY, and stop. Do not suggest redesigns.

Redesign an existing site without breaking routes or analytics

For an existing site, install redesign-existing-projects, or use §11 of the default skill. Both start by detecting the mode (Greenfield, Preserve, or Overhaul) and auditing before any change. §11.F lists what never changes silently: URL structure, primary navigation labels, form field names and order, the logo or wordmark, and legal or consent copy. §11.C adds anchor IDs and the section IDs that analytics depends on.

Those rules live in the agent’s context, not in your CI. Back them with checks: a route list diffed against main, your analytics event names asserted in an end-to-end test, and characterization tests on the forms before the agent touches them.

Copy-paste prompt: preserve-mode redesign

Use the redesign-existing-projects skill in Preserve mode on the pages under
app/(marketing)/. First, write the audit (brand tokens, IA, patterns to keep,
patterns to retire, and your dial reading of the current site) to
docs/redesign-audit.md and stop for my review.

Hard limits: do not change any route, nav label, form field name or order,
element id, data-testid, analytics event name, logo, or legal copy. Apply the
modernisation levers in order (typography, spacing, colour, motion) and stop
after the first lever that meets the brief. At the end, list every file you
changed and confirm that `git diff main --stat -- app/api` is empty.

When Taste Skill fights your house style or your stack

The skill is opinionated, and its bans apply “unless the brief explicitly asks for them”. That sentence is the override channel: state exceptions in the brief or in the project instructions the agent always reads, and leave the installed SKILL.md untouched. An edited copy fails the drift check and disappears on the next update.

## Frontend design exceptions (read with the design-taste-frontend skill)
- Icons: we use lucide-react already. Do not add a second icon library.
- Font: Inter is the brand font. Do not replace it.
- Stack: Vue 3 + Nuxt. Ignore the React-specific parts of §3 and §5.

The skill has no non-React path; on Vue or Svelte, expect to restate the stack in each brief and review §5 motion code by hand.

Put this block in CLAUDE.md for Claude Code, AGENTS.md for Codex, and a project rule for Cursor. The skill’s own text supports the icon, font and dependency lines: Inter is discouraged by default but allowed on explicit request, lucide-react is allowed when the user asks or the project already depends on it, and §3.F tells the agent to check package.json before adding any library.

When Taste Skill goes wrong, and how to recover

Traps with Taste Skill

• Wrong install name. --skill taste-skill installs nothing. Use design-taste-frontend.
• Unpinned installs drift. There are no git tags, and v2 changes in place. Pin a commit SHA and review the SKILL.md diff when you move the pin.
• The plugin is the whole bundle. taste-skill@taste-skill brings all 13 skills. Use the skills CLI for one.
• Two design skills on one request. Taste Skill and Impeccable each carry a full procedure. Pick one per project.
• Skills run with the agent’s permissions. The skills CLI prints this warning after every install. Review what you pin, as described in skill supply-chain security.

The page still looks templated. The agent skipped §0 and used the baseline dials. Ask for the Design Read and dial values explicitly (the build prompt does this), and reject a reply that repeats 8 / 6 / 4 without a reason from the brief.

The pre-flight says PASS, but the page has em dashes. The report is self-graded. Run scripts/taste-gate.sh and the Playwright spec, paste the failures back to the agent, and ask for fixes only on the listed lines.

New dependencies appear in package.json. The skill’s defaults include GSAP, Motion, and specific icon libraries. Add your stack to the project exceptions, and ask the agent to list dependencies before it installs any (step 4 of the build prompt).

The agent restyles your dashboard. The request matched the skill’s description, but §13 puts dashboards out of scope. Say “do not use the design-taste-frontend skill for this” in the prompt, or keep the skill at project scope in the marketing app only.

Motion is claimed but nothing moves, or everything moves. The pre-flight requires real animation above MOTION_INTENSITY 4 and prefers-reduced-motion support above 3. Lower the dial to 3 in the conversation for a static page, and test with reduced motion enabled in the browser.

Taste Skill, Impeccable, or the four-artifact pipeline?

	Taste Skill	Impeccable	Four-artifact pipeline
Shape	13 skill files	One skill with named commands, plus a deterministic detector	A gated workflow with four versioned artifacts
Best at	Generating a new marketing surface that does not look templated	Refining UI you already have, in your own design system	Taking a product surface from intent to verified code
Learns your system?	No, it imposes a direction unless the brief overrides it	Yes, from PRODUCT.md and DESIGN.md	Produces a design contract as one of its artifacts
Machine check	None shipped; add the gate and spec above	npx impeccable detect in CI	Screenshot and accessibility gates from the contract

Use Taste Skill for a new landing page or portfolio. Use Impeccable when the UI exists and you want named refinements and a detector. Use the pipeline for product surfaces where states, tokens, and sign-off matter more than first-pass polish, and let either skill handle the build step inside it.

Where to go next with Taste Skill

Installing and managing skills Pin, commit, and drift-check skills for a whole team, across Claude Code, Codex, and Cursor.

Four-artifact design-to-code pipeline Direction, prototype, design contract, and code with proof: the workflow Taste Skill's build step fits into.

Impeccable The refine-what-exists alternative, with a deterministic detector for CI.

Best frontend skills Pair a design skill with framework skills so the agent also writes current React or Next.js.

Catching slop before merge Detectors and review prompts for the tells of generated code, beyond one skill's ban list.