# Taste Skill's upgrade command is the same command you already ran > Taste Skill is a repository of portable agent skills that give coding agents visual rules and review checks, installed by piping a GitHub URL into the npx skills add CLI. The mechanics are worth reading closely: the default skill is now an experimental v2 whose install name never changed, folder names never match install names, and half the pipeline expects you to supply an image generator and a coding agent of your own. **Leonxlnx/taste-skill** — Taste Skill gives coding agents concrete visual rules and review checks for avoiding generic layouts, weak typography, and decorative UI clutter. - Repository: https://github.com/Leonxlnx/taste-skill - Website: https://tasteskill.dev - Stars: 91,183 · Forks: 6,197 - Language: JavaScript - License: MIT - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/leonxlnx-taste-skill ## The upgrade command is byte-for-byte the command you already ran The default skill has a new major shape, and the way you get it is invisible in the command line. The install name is design-taste-frontend for both the original and the rewrite, and the README says so directly: the install name did not change, so no script updates are needed, and the newer SKILL.md replaces the older one in place. So this line does two different things depending on when you run it: ``` npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend" ``` Run it in March and you get v1. Run the identical line today and you get what the README calls v2, a substantial rewrite that is marked experimental and described as actively iterating toward v2.0.0 stable. There is no version argument to add and no tag in the URL. For a team this is the failure mode to plan around. Two developers on the same documented command can be running materially different instruction sets, and nothing in either one's session tells them so. The repository has no GitHub releases to compare against, so the escape hatch is a different install name, not a version pin. ## Pinning to v1 means changing the install name, not adding a version If you depend on the exact behaviour of v1, the documented route is a second skill that still exists in the repository, taste-skill-v1, installed under a different name: ``` npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend-v1" ``` The README is explicit about when to reach for it: use it only if the v2 default breaks something specific in your workflow. The v1 row in the skills table carries the same instruction, describing it as the original v1 of taste-skill, preserved for projects depending on its exact behaviour. Two things follow. First, pinning is a rename rather than a version constraint, so any automation you write has to know both names and treat them as two different targets, not as two versions of one. Second, the full v1 to v2 diff lives in CHANGELOG.md, and there is a separate changelog linked from the front page at tasteskill.dev/changelog. Reading that diff is the only way to find out what the rewrite changed, because the install command gives you no way to ask. ## Every folder name is different from its install name The README flags this before the table: install a single skill by its install name, which is the name field inside the SKILL frontmatter, not the folder name. Then it shows that the two disagree in every visible case. The folder taste-skill installs as design-taste-frontend. taste-skill-v1 installs as design-taste-frontend-v1. gpt-tasteskill installs as gpt-taste. image-to-code-skill installs as image-to-code. redesign-skill installs as redesign-existing-projects. soft-skill installs as high-end-visual-design. The mapping is a rename six times out of six, which means the convention is not a pattern you can infer, it is a lookup. The README says the install name column is the exact value you pass to --skill, which is the right instruction, and the reason it needs saying is that the obvious guess is wrong every time. For anyone scripting this, the consequence is concrete. A script that reads the skills/ directory and builds the --skill argument from folder names will pass a string that does not exist, and it will fail in a way that looks like a typo rather than a documented convention. Read the frontmatter or copy the table. ## Half the skills emit images you have to generate somewhere else The skills table splits the set into two kinds, and the README states the difference in one line: implementation skills output code, image-generation skills output reference images only. The image-generation half is described elsewhere as skills for reference boards covering web, mobile, and brand kits, with the workflow being to pair them with ChatGPT Images or similar generators and then hand the frames to Codex, Cursor, or Claude Code for implementation. The image-to-code skill is the same shape described end to end: generate site references, analyze them, then implement the frontend to match. So the repository is not a closed pipeline. It supplies written instructions at both ends and depends on you to supply a generator in the middle and a coding agent at the finish. Nothing in it renders a design, and nothing in it runs. The handoff between the reference frames and the implementation is manual and described in prose, so a change to the design language between the two steps is caught by whoever is looking. For a reader budgeting effort, that is the real cost. The skill set shortens the brief an agent works from, and it does not remove the need for a generator, an agent, and a review pass over the result. ## The v2 default is three dials and a banned character, not a method Read what the default skill is described as doing and the composition is worth noting. It reads the brief and infers the design language, then tunes three dials, VARIANCE, MOTION, and DENSITY. Alongside that it carries a design-system map, a hard em-dash ban, canonical GSAP code skeletons, a redesign-audit protocol, and a strict pre-flight check. Two of those are unusually concrete for a design guideline. A character prohibition is a checkable rule that can be verified on output without judgement. Canonical code skeletons for GSAP are a fixed shape to copy rather than a description to interpret. Those two parts of the skill are testable in a way the rest of the design language is not. The three dials are the part to watch. They are inputs, and the skill infers the design language from the brief rather than asking the reader to supply it, which means the variance and density of what comes out are decided by defaults the README does not print. On top of that the row is labelled v2 experimental and still iterating toward v2.0.0 stable, so the defaults themselves may move. If output consistency across runs matters to you, that is a knob to check rather than assume. ## Three install surfaces, and only one of them has an update path The supported route is a package from npm pointed at a GitHub repository, using the npx skills add CLI that the README links to vercel-labs/agent-skills. That command scans the skills/ folder, which is why every skill in the table, code and image-generation alike, installs the same way. Alongside it there are two other surfaces with different properties. The repository has a .claude-plugin/ directory at the top level, which is a packaging path for a plugin loader. And the README offers a third option with no machinery at all: you can also copy any SKILL.md into your project or paste it into ChatGPT or Codex conversations. That third option is the one to think about. A copied SKILL.md is a snapshot with nothing watching it, so it drifts from the upstream the moment the upstream changes, and the drift is invisible because the file still looks complete. The npx route at least re-runs. The top level also has a skill.sh and a scripts/ directory, so there is shell tooling in the repository that the install command does not use. Pick one surface and use it consistently across a project. Three copies in three places is three set of instructions that will disagree. ## A token disclaimer and five sponsor rows sit above the skills table The front page opens with a sponsor block before it reaches anything about design rules. Kimi from Moonshot AI is thanked with a note about 2.8T parameters, native vision, and a 1-million-token context window, followed by an offer of 10% bonus API credits on a first purchase. The sponsor table then lists Fluxion AI with a claim of saving up to 70% compared with official API pricing and $3 in credits for signing up through the link, plus interfaces.dev, React Bits, IMG.LY, and Sent.dm. Then there is the disclaimer, which is unusual enough to quote: Taste Skill has no official token, coin, or crypto project, and any token using the author's name, image, or project is unaffiliated and not endorsed. A disclaimer like that is written by somebody who has seen it happen, and that is a fact about the project's visibility rather than about its design. It also means the name is a namespace other people will reach for. If you encounter a Taste Skill token, the repository is telling you it is not this project. The practical consequence for a reader is navigation. Five commercial rows and a credit offer come before the install command, and the skills table that defines the actual product is further down. The examples directory, meanwhile, holds three webp frames of a single design, examples/floria-top.webp, floria-full.webp, and floria-bottom.webp, so the visible proof of output is screenshots rather than runnable code. ## Conclusion Taste Skill suits someone who already drives a coding agent through Codex, Cursor, or Claude Code and wants a written design brief rather than a component library. It does not suit anyone expecting a package to install, a renderer to run, or a stable default, because the repository ships instructions rather than an application, half the skills need a separate image generator, and the default skill is labelled experimental. Before installing, read CHANGELOG.md for the v1 to v2 diff, decide whether you want the default or the pinned v1 install name, and remember that a manually copied SKILL.md has no update path. ## FAQ ### How do I use Taste-skill? Run npx skills add https://github.com/Leonxlnx/taste-skill, which uses the npx skills add CLI to scan the skills/ folder and install every skill, code and image-generation alike. Pass --skill with an install name to install just one of them. ### What is Leon's Taste-skill skill? It is a set of portable Agent Skills for coding agents, covering layout, typography, motion, and spacing, plus image-generation skills for reference boards such as web, mobile, and brand kits. The repository is MIT licensed and calls itself the Anti-Slop Frontend Framework for AI Agents. ### how to install taste skill in claude code Use npx skills add https://github.com/Leonxlnx/taste-skill to install everything, or add --skill with the install name such as design-taste-frontend for a single skill. You can also copy any SKILL.md into your project, and the repository ships a .claude-plugin/ directory at its top level. ### what is taste skill Taste Skill gives coding agents concrete visual rules and review checks aimed at generic layouts, weak typography, and decorative UI clutter. It is a repository of skills where each one does a single job, rather than a library or an application you run. ### taste skill alternative The README does not name an alternative. It describes variants of its own set instead, including a stricter GPT and Codex variant installed as gpt-taste, and the preserved original installed as design-taste-frontend-v1 for projects that depend on the exact v1 behaviour. ## Sources - [Official documentation](https://tasteskill.dev) - [Official README](https://github.com/Leonxlnx/taste-skill#readme) - [Project repository](https://github.com/Leonxlnx/taste-skill) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/leonxlnx-taste-skill