Taste Skill: visual rules for AI coding agents that keep producing the same layout

What Taste Skill is trying to fix in AI-generated frontends

The repository describes itself as "The Anti-Slop Frontend Framework for AI Agents", and the target is narrow: the specific visual defaults that coding agents fall back on when a brief says nothing about design. Centred hero, evenly weighted card grids, decorative gradients, a type scale that was never chosen. Taste Skill is a collection of Agent Skills that encode rules for layout, typography, motion and spacing so the agent has something concrete to follow instead of guessing.

It is for people who are already generating interfaces with an agent and are unhappy with the output, not for people looking for a design system to import. The repository also ships image-generation skills for reference boards across web, mobile and brand kits. Those skills output reference images only. The README's stated workflow is to pair them with an image generator such as ChatGPT Images, then hand the resulting frames to Codex, Cursor or Claude Code for implementation. Implementation skills output code; image-generation skills do not.

One thing to note before anything else: the README carries an explicit disclaimer that Taste Skill has no official token, coin or crypto project, and that any token using the author's name, image or project is unaffiliated. If you arrived here from a token listing, you are in the wrong place.

How the skills are structured and what the v2 default actually changes

Each skill lives in the skills/ folder and is defined by a SKILL.md file with frontmatter. The install name is the name: field inside that frontmatter, not the folder name, which is why the folder taste-skill installs as design-taste-frontend. That distinction matters when you pass --skill, because passing the folder name is not what the README documents.

The default skill is now v2, marked experimental in the README, and described there as a substantial rewrite of v1. The mechanism it adds over v1 is a set of three dials, VARIANCE, MOTION and DENSITY, that the agent tunes after reading the brief. The README also lists brief inference, a design-system map, a hard ban on em dashes in generated copy, canonical GSAP code skeletons, a redesign-audit protocol and a strict pre-flight check. The repository states it is iterating toward a v2.0.0 stable release, so the current default is a moving target by the author's own description.

v1 is preserved as a separate skill under the install name design-taste-frontend-v1, for projects that depend on its exact behaviour. There is also gpt-taste, a stricter variant aimed at GPT and Codex with higher layout variance and what the README calls aggressive anti-slop, plus image-to-code, which chains reference generation, analysis and implementation. The skills are independent: the README says each does one job and you do not need all of them at once.

Installing Taste Skill with npx skills add

Installation goes through the npx skills add CLI, which the README links to vercel-labs/agent-skills. That CLI scans the skills/ folder in the repository, so every skill installs the same way. The plain command installs the set:

npx skills add https://github.com/Leonxlnx/taste-skill

To install one skill, pass its install name, which is the name: field in the SKILL frontmatter rather than the folder name. The README gives this example for the default skill:

npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"

If you are upgrading from v1, you do not need to change anything. The install name stayed the same, so re-running the command above replaces the older SKILL.md in place and moves you to v2. If v2 breaks something specific in your workflow, the README documents pinning to the original behaviour:

npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend-v1"

The README also notes a manual path: you can copy any SKILL.md into your project or paste it into a ChatGPT or Codex conversation. That is the fallback if you do not want the CLI writing into your agent's skill directory at all. The repository does not document an uninstall command, and the README does not document rollback beyond installing the v1 skill name again.

A first real use: brief, dials, then implementation

The README does not walk through a full worked session, so the honest description of first use is the workflow it states rather than a transcript. You give the agent a brief, and the skill's brief-inference step is what decides the design language instead of the agent defaulting to a hero and a card row. In v2, that inference sets the three dials. VARIANCE governs how far the layout departs from a conventional grid, MOTION governs how much animation the implementation carries, and DENSITY governs how tightly information is packed.

The README lists canonical GSAP code skeletons as part of v2, which means motion guidance arrives as concrete code rather than as an adjective like "subtle". It also lists a redesign-audit protocol and a strict pre-flight check, which are the review side of the same skill: the agent checks its own output against the rules before handing it back. That pre-flight step is the part worth watching on a first run, because it is where the skill either catches a generic layout or lets one through.

If you want reference images rather than code, the image-generation skills follow the sequence the README describes: generate site references, analyze them, then implement. The examples/ folder in the repository contains floria-bottom.webp, floria-top.webp and floria-full.webp, which are the visual examples the README points to. Those files are the only output samples in the repository listing, so they are what you have to judge the visual claims against before installing anything.

Where Taste Skill stops being the right tool

The most concrete limitation is stated by the project itself: the default skill is v2 and labelled experimental, with the README saying it is iterating toward v2.0.0 stable. If you need reproducible output across a team, an experimental default that changes under the same install name is a real problem. The install name did not change between v1 and v2, which is convenient for upgrades and awkward for anyone who pinned behaviour without realising the pin was to a name rather than a version. Pin with design-taste-frontend-v1 if exact behaviour matters, and read CHANGELOG.md, which the README points to for the full v1 to v2 diff.

Second, this is not a checker in your build. Nothing here fails a pull request or runs in CI. The rules live in a SKILL.md that an agent reads, so the enforcement is only as good as the agent's adherence. A team that wants a hard gate on spacing tokens or contrast ratios needs a different kind of tool.

Third, it is opinionated by design. A skill that tunes layout variance upward and bans decorative clutter is making aesthetic calls, and if your product already has a design system with its own conventions, the skill's rules will compete with it. The README does not document a way to merge Taste Skill's rules with an existing in-house system. And if you are not using an agent to write frontend code in the first place, there is nothing here for you to install.

Taste Skill compared with Impeccable and plain agent prompting

People searching for this project often arrive comparing it with Impeccable, another skill in the same space. The repository does not describe Impeccable's internals, so the fair comparison is about packaging rather than quality. Both are agent skills rather than libraries, which means neither ships runtime code and neither can be imported into a build. The difference you can actually verify from this repository is scope and pinning: Taste Skill separates implementation skills from image-generation skills, keeps v1 available under a distinct install name for projects that depend on its exact behaviour, and ships a stricter GPT and Codex variant as gpt-taste. If your workflow needs reference boards before code, the image-to-code skill chains those steps, which a single-purpose taste skill does not.

The other alternative is doing nothing and relying on a well-written prompt. That is genuinely cheaper, and for a one-off page it is probably enough. The case for a skill file is that the rules persist across sessions and across agents instead of being retyped, and that they are specific: the README's list of mechanisms, dials, a design-system map, GSAP skeletons and a pre-flight check, is more than most people put in a prompt. The trade-off is that you inherit someone else's aesthetic judgements and have to read CHANGELOG.md when the default moves.

Licence, maintenance and what upgrading costs you

The repository is MIT licensed. That permits commercial use and modification, and the practical implication for a skill file is that you can fork SKILL.md, edit the rules and keep your changes without publishing them. This is not legal advice; read the LICENSE file in the repository for the actual terms.

On maintenance, no last push date or release information is available for this repository, and it is not archived. That means the honest position is that the current state of the default skill is whatever is on the main branch, described by its own README as experimental and iterating toward v2.0.0 stable. If your team needs a stable target, that is a reason to track the v1 install name and read CHANGELOG.md before re-running installs.

Upgrade cost is low in mechanical terms and non-trivial in practice. The command is one line and the install name is unchanged, so an upgrade is a re-run. The cost is that the newer SKILL.md replaces the older one in place, which means an upgrade is not reversible by a flag; you revert by installing design-taste-frontend-v1. Budget for a diff review of CHANGELOG.md on each upgrade rather than assuming the change is cosmetic, because the README describes v2 as a substantial rewrite.

Editorial conclusion

Adopt Taste Skill if you already drive Codex, Cursor or Claude Code and the interfaces they produce keep collapsing into the same centred hero, the same three-card row and the same default type scale. Do not adopt it if you want a linter that fails a build or a component library that ships code you can import; this is prompt and rule material, not a runtime dependency, and the default skill is explicitly labelled v2 (experimental). Before you commit, install with --skill "design-taste-frontend-v1" into a throwaway project and compare the same brief against the v2 default, because the install name is unchanged and re-running the plain install command silently replaces v1 with v2 in place.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository