Taste Skill Frontend Design Framework for AI Coding Agents

Created by Leon Lin (Leonxlnx) - https://github.com/leonxlnx

Overview

The Taste Skill frontend framework is an open-source set of Agent Skills that gives AI coding agents explicit design judgment before they write interface code. Leon Lin, who publishes on GitHub as Leonxlnx, maintains it in the Leonxlnx/taste-skill repository under the MIT license, and the project's README calls it "The Anti-Slop Frontend Framework for AI Agents." Each skill is a SKILL.md file: YAML frontmatter with a name and a description, followed by Markdown instructions the agent reads when the task matches.

The problem it targets is familiar to anyone who has asked an agent for a landing page. The code runs, and the page looks like every other generated page: a centered hero over a gradient, three equal feature cards, Inter on slate, and a purple accent. Anthropic's frontend team describes the cause as distributional convergence, where a model drifts toward the safe choices that dominate its training data, and names Inter, purple gradients and minimal animation as the usual result (Anthropic, Improving frontend design through Skills). Taste Skill answers that with written rules the agent must apply and then check.

The default skill, install name design-taste-frontend, is the core of the repository. In its current v2 form (marked experimental) it starts with brief inference: before any code, the agent reads the page type, the vibe words in the request, any references, the audience and constraints such as accessibility or regulation, then states a one-line "design read." It then sets three dials that gate every later decision, DESIGN_VARIANCE, MOTION_INTENSITY and VISUAL_DENSITY, each on a scale of 1 to 10 (taste-skill SKILL.md). A trust-first public-sector brief gets low variance and low motion. An agency portfolio gets high values on both.

The rest of the default skill is concrete. It maps briefs to real design systems (Material, Fluent, Carbon, Polaris, GOV.UK, USWDS, shadcn/ui) and tells the agent to install the official package instead of imitating it. It sets typography, color and layout directives, lists "AI tells" to avoid, bans the em dash outright, requires reduced-motion handling, includes a redesign protocol that audits before touching anything, and ends with a pre-flight checklist the agent must pass before it hands work back. The CHANGELOG records that v2 is a substantial rewrite and that the original is kept as design-taste-frontend-v1 for projects that depend on its exact behavior.

Around the default skill sit variants that each do one job. gpt-taste is a stricter version aimed at GPT and Codex. redesign-existing-projects audits an existing codebase and fixes it in place. high-end-visual-design, minimalist-ui and industrial-brutalist-ui apply a chosen visual direction. full-output-enforcement stops an agent from truncating code with placeholders. stitch-design-taste targets Google Stitch, and three image-generation skills produce reference boards for web, mobile and brand kits. The README states plainly that you do not need all of them at once.

The scope is narrower than many summaries suggest. The default skill says it is built for landing pages, portfolios and redesigns, and its "Out of Scope" section lists dashboards, data tables, multi-step forms, code editors, native mobile and realtime collaboration UIs. For those it points to Fluent, Carbon, Atlassian or Polaris instead. A team that wants density rules for an admin console has to write them itself or reach for a design system.

Independent coverage frames the project the same way. A Developers Digest piece describes the repository as packaging "frontend design judgment into installable skills" and argues that such files work best as a review checklist, a style contract and a calibration artifact (Developers Digest). That reading shapes this method: install the skill, adapt it to your own brand, and make the agent prove it followed the rules.

Core Principles

Read the brief before choosing a look

The default skill makes the agent classify the request before it writes a line of markup: page kind, audience, vibe words, references and quiet constraints. The one-line design read makes that classification visible, so a reviewer can reject a wrong direction in seconds instead of after a full build. Skipping it is how a public-sector service ends up with glassmorphism. The skill also limits clarifying questions to one, and only when the read genuinely diverges.

Name the defaults you reject

Positive guidance such as "use good typography" leaves the model free to fall back on its average. Taste Skill spends much of its length on specific bans: purple glow gradients, three equal feature cards, generic names like "John Doe", fake product screenshots built from styled divs, section-number eyebrows and the em dash (taste-skill SKILL.md). A named ban gives the agent a boundary it can check, and a reviewer a pattern they can search for. Each ban ships with an override path for briefs that genuinely call for the banned pattern.

Tune with dials, not with rewrites

Variance, motion and density are set per project from the brief, with presets for common page types. Every layout and animation rule in the skill is conditioned on those values, so one file serves both a calm editorial site and a kinetic agency page. Overrides happen in conversation; the skill tells the agent not to ask users to edit the file for a one-off change. The result is fewer forks of the same rules.

Use real systems when the brief calls for them

When a brief reads as Material, Fluent, Carbon, GOV.UK or another established system, the skill tells the agent to install the official package and keep to one system per project. When the brief is an aesthetic such as bento, brutalism or editorial, it tells the agent to build with web standards and label the result honestly. This stops the agent from recreating a design system's CSS by hand and drifting from it.

Accessibility and performance are release gates

The skill makes contrast checks on every button and form field mandatory, requires dark mode for consumer pages, restricts animation to transform and opacity, and requires prefers-reduced-motion handling for anything with a motion dial above 3. Those rules line up with published guidance: WCAG sets a 4.5:1 minimum contrast for body text (W3C, Contrast Minimum), and web.dev recommends keeping animation on the compositor (web.dev animations guide). A page that looks good and fails these checks is not finished.

The agent verifies its own output

The default skill ends with a long pre-flight checklist, and it states that the output is not done if any box cannot be honestly ticked. That turns taste from a hope into a review step the agent performs before a human looks. Anthropic's authoring guidance recommends the same feedback-loop pattern of validating, fixing and repeating (Skill authoring best practices). Human review still matters, but it starts from a cleaner draft.

Rules are portable text

Every skill in the repository is plain Markdown in the open Agent Skills format, so the same file works in any agent that reads SKILL.md (Agent Skills specification). Switching from one coding agent to another does not mean rewriting the rules. Keeping them in version control next to the code also means changes get reviewed like code.

What the Repository Contains

The list and install names come from the repository README. The repository also keeps design-taste-frontend-v1, image-to-code and stitch-design-taste.

Steps

1. Collect a baseline Before installing anything, ask your agent for the pages you actually ship, such as a landing page, a pricing section and a portfolio grid, with no design skill loaded. Save the output and screenshots. List the generic patterns you see: centered hero, equal cards, default fonts, missing hover and focus states, pure black, a stray purple accent. This list tells you which rules matter most for your product and gives you something to compare against later. Anthropic's authoring guidance recommends exactly this order: run the agent without the skill, record the failures, then write or adopt instructions (Skill authoring best practices).

2. Install the default skill in project scope Run npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend" from the repository root, which uses the skills CLI to copy the file into your agent's skills directory. Project scope keeps the rules in version control where the whole team gets them. Confirm the agent can see the skill, for example with /skills in Claude Code. Read the file end to end before trusting it: it is a long document and Anthropic advises auditing any third-party skill before use (Agent Skills overview).

3. Check the scope against your surfaces The default skill is for landing pages, portfolios and redesigns and says so in its "Out of Scope" section. If the work is a dashboard, a data table or a multi-step form, keep the skill for your marketing surfaces and use a real design system or your own rules for the product UI. Add redesign-existing-projects if you are improving a site that already exists. Add a style variant only when the visual direction is already decided. Loading every skill at once gives the agent conflicting instructions.

4. Adapt the rules to your brand Open the installed SKILL.md and change what does not fit: fonts you license, your accent color, your corner-radius scale, your motion library. The project docs describe the file as fully editable (Taste Skill docs). Keep the bans that match your baseline failures and remove ones that contradict your brand, such as a serif rule when your wordmark is a serif. Record each change in a commit message so the next person knows why it differs from upstream.

5. Generate with an explicit design read and dials Prompt the agent with a real brief and ask it to state its design read and dial values before coding. Correct the read if it is wrong; this is the cheapest point to change direction. Then let it build, and require it to run the pre-flight checklist and report any box it could not tick. Treat an unticked box as a bug, not a style preference.

6. Review against the same rules Compare the result with your baseline from step 1, pattern by pattern. Run Lighthouse for performance and accessibility (Lighthouse overview), check both light and dark mode, and toggle reduced motion. Search the markup for the patterns the skill bans. When something slips through twice, write it into the skill as a named ban so the agent catches it next time.

7. Track upstream and re-baseline The v2 default is marked experimental, and the CHANGELOG says its sections may keep changing until a stable release (CHANGELOG). Re-run the install to pull updates, then diff them against your local edits instead of overwriting them. If you depend on exact behavior, pin design-taste-frontend-v1 or vendor your adapted copy. Repeat the baseline comparison after each update so you notice regressions.

How to Use Taste Skill in Everyday Prompts

Once design-taste-frontend is installed, you mostly use Taste Skill by writing a normal UI request. The agent loads the skill when the task matches the description in the file's frontmatter, and you then steer it through the design read and the dials. This section covers the prompting loop after setup. For installation and adaptation, see the steps above.

How do you trigger the skill?

You trigger it by asking for frontend work the skill is written for, such as a landing page, a portfolio or a redesign. The agent reads the SKILL.md instructions when the request matches the skill's description (taste-skill SKILL.md). If you have several design skills installed, or the agent seems to ignore it, name design-taste-frontend in the prompt so there is no doubt about which rules apply. A request for a dashboard or data table falls outside the skill's stated scope, so do not expect it to engage well there.

What should the prompt include?

A good prompt gives the agent the inputs its brief inference already looks for: the page type, a few vibe words, any reference sites, the audience, and hard constraints such as accessibility or regulation. Thin prompts force the agent to guess, and a guessed design read is where generic output creeps back in. A useful prompt shape looks like this:

Using design-taste-frontend, build a pricing section for a B2B security product.
Audience: IT leads at mid-size companies. Vibe: calm, precise, trustworthy.
Reference: our existing homepage. Constraint: must meet WCAG AA contrast.
Before writing code, state your design read and dial values, then wait for my confirmation.

Asking the agent to wait after the design read is the cheapest review point in the whole loop. You correct direction in one line instead of after a full build.

How do you adjust a dial for one request?

You adjust a dial by saying so in the conversation, not by editing the skill file. The default skill tells the agent to handle one-off overrides in chat (taste-skill SKILL.md). Phrase the change in terms of the dial, for example "keep variance as proposed but drop motion intensity for this section", so the agent applies the rules that key off that value, including reduced-motion handling. Reserve file edits for changes that should hold across the whole project.

How do you tell the skill actually ran?

The clearest sign is that the agent states a one-line design read and dial values before coding and reports its pre-flight checklist at the end. If neither appears, the skill probably did not load, and you should confirm it is visible to the agent before continuing. A second sign is in the output itself: banned patterns such as purple glow gradients, three equal feature cards or placeholder names like "John Doe" should be absent. When they show up anyway, ask the agent which checklist item it skipped rather than fixing the markup by hand, so the gap gets named.

Is tasteskill the same thing?

Yes, "tasteskill" usually refers to the same project, whose documentation lives on the Taste Skill docs site alongside the Leonxlnx/taste-skill repository. Several unrelated repositories reuse the name, so check the owner before installing.

Taste Skill Examples

Three typical ways to use the design-taste-frontend skill are a trust-first landing page for a public service, a high-motion agency portfolio, and an audit-first redesign of a marketing site that already exists. Each example follows the same loop: brief, design read, dials, build, then the pre-flight check. The details come from the default skill as the page describes it. The teams and outcomes below are made up.

A public-sector service landing page

Illustrative scenario: a small team asks the agent for a landing page where residents renew a permit. The agent's one-line design read names a government service for a broad public audience, with accessibility as a hard constraint. Because the brief reads as an established system, the agent proposes the official GOV.UK or USWDS package rather than hand-built CSS, and sets low variance and low motion. The reviewer confirms the read before any code is written, which is the cheapest point to correct direction. The build then goes through the pre-flight checklist: contrast on every button and form field, reduced-motion handling, and a search of the markup for banned patterns such as purple glow gradients or three equal feature cards. If the agent had proposed glassmorphism or a kinetic hero, the design read would have exposed the mismatch in seconds.

A kinetic agency portfolio

Illustrative scenario: a design studio wants a portfolio that feels bold and expressive. The design read names an agency portfolio aimed at prospective clients, so the agent sets high variance and high motion and builds with web standards, labelling the aesthetic honestly instead of claiming a design system. Motion stays on transform and opacity, and because the motion dial is high, prefers-reduced-motion handling is required rather than optional. When the studio wants one section calmer than the rest, it says so in the conversation and does not edit the skill file for a one-off change. The reviewer checks light and dark mode, toggles reduced motion, and rejects any placeholder names or fake product screenshots built from styled divs.

Redesigning an existing marketing site

Illustrative scenario: a team inherits a generated site with a centered hero over a gradient, Inter on slate and a stray purple accent. It loads redesign-existing-projects alongside the default skill, and the agent audits before changing anything, listing the generic patterns it finds and the fixes it proposes. URLs, nav labels and form field names stay protected, so the redesign does not break links or analytics. The team approves the audit, the agent fixes the site in place instead of rewriting it, and every pattern that slips through twice becomes a new named ban in the team's adapted copy of the skill.

What an out-of-scope request looks like

Illustrative scenario: the same team then asks for an admin dashboard with data tables. The default skill's Out of Scope section excludes that surface, so the right move is to keep Taste Skill for the marketing pages and build the dashboard on a system such as Fluent, Carbon, Atlassian or Polaris. Forcing the landing-page rules onto dense product screens is a sign the skill is being used outside its design.

When to Use

• Your team builds marketing pages, landing pages or portfolios with an AI coding agent and the output keeps landing on the same generic look. This is the use case the default skill was written for.
• You are redesigning an existing site and want the agent to audit before it changes anything. The redesign protocol and the redesign-existing-projects skill both require an audit first and protect URLs, nav labels and form field names.
• You have no designer reviewing every pull request and need a written quality bar the agent applies on its own. The pre-flight checklist gives developers a concrete list to hold the agent to.
• Several people or several agents generate UI for the same product. One version-controlled skill keeps their defaults aligned instead of each prompt carrying its own taste.
• You want accessibility and performance rules enforced at generation time. Contrast, reduced motion and compositor-only animation are hard rules in the skill rather than review comments.

When Not to Use

• The surface is a dashboard, admin panel, data table or multi-step form. The default skill lists these as out of scope and recommends established design systems for them.
• You already ship from a mature design system with enforced components. Taste Skill's aesthetic bans can fight your system; a short skill that points the agent at your own components is a better fit.
• You are building a throwaway prototype where appearance does not matter yet. The skill is long, and loading it adds instructions the agent has to weigh on every UI task.
• Nobody on the team will read and adapt the file. The default rules encode one maintainer's taste, and applying them unexamined can override brand decisions you have already made.