What Is the Difference Between Taste-Skill v2 and v1?

Taste-Skill v2 is an experimental rewrite that adds a data-driven design pipeline with brief inference, three tunable dials, automatic design-system selection, and expanded anti-slop constraints, while v1 is the preserved original baseline with static defaults for legacy projects.

Taste-Skill is an anti-slop frontend skill that guides AI agents toward high-quality UI code. The Leonxlnx/taste-skill repository maintains two versions of the core design skill to support different project needs. Understanding the difference between Taste-Skill v2 and v1 helps you choose the right install target for your workflow.

Installation Names and Version Status

The two versions are distinguished by their skill install names and their maturity level. The repository treats them as separate install targets with distinct front-matter names.

• Taste-Skill v2 uses the install name design-taste-frontend and is the current default. It is labeled as an experimental rewrite.
• Taste-Skill v1 uses the install name design-taste-frontend-v1 and is kept explicitly for backward-compatibility.

As noted in the README.md, installing the default design-taste-frontend package will overwrite any previous v1 installation with the v2 version. If your project depends on the exact behavior of the original skill, you must pin to design-taste-frontend-v1.

Core Design Workflow: Dynamic Dials vs. Static Baseline

The most significant architectural difference lies in how each version handles design parameters at generation time. Where v1 applies static defaults, v2 derives runtime values from an inferred brief.

v2: Brief Inference and Three Tunable Dials

According to skills/taste-skill/SKILL.md, v2 introduces an explicit brief inference step that lets the skill "read the room" before generating code. It then exposes three dial controls that drive layout, animation, and density:

• DESIGN_VARIANCE — controls layout variation
• MOTION_INTENSITY — controls animation depth
• VISUAL_DENSITY — controls component density

These dials are not static. They influence conditional generation logic, such as switching between single-column and multi-column layouts based on the variance value.

In skills/taste-skill/SKILL.md#1-the-three-dials, these controls are defined as the primary mechanism for shaping UI output. Agents read the dials at generation time to resolve spacing, motion duration, and grid complexity.

// v2 example – a client component that reads the dials
"use client";
import { motion } from "motion/react";

export const Hero = ({ title }: { title: string }) => {
  // Dials are injected by the skill at generation time
  const variance = 8;   // DESIGN_VARIANCE
  const motionLevel = 6; // MOTION_INTENSITY
  const density = 4;    // VISUAL_DENSITY

  return (
    <section className={`grid ${variance > 6 ? "grid-cols-2" : "grid-cols-1"} gap-8`}>
      <motion.h1
        initial={{ opacity: 0, y: 30 }}
        animate={{ opacity: 1, y: 0 }}
        transition={{ duration: motionLevel * 0.1 }}
        className="text-4xl md:text-6xl font-geist tracking-tight"
      >
        {title}
      </motion.h1>
      {/* …other layout driven by `density` … */}
    </section>
  );
};

v1: Fixed Baseline Configuration

By contrast, skills/taste-skill-v1/SKILL.md#1-active-baseline-configuration defines a static baseline only. The same component generated by v1 would use fixed values for variance, motion, and density without conditional layout logic. The original skill applies a one-size-fits-all default rather than adapting to a project brief.

Automatic Design-System Mapping (v2 Only)

Taste-Skill v2 includes a decision table in skills/taste-skill/SKILL.md#2-brief-→-design-system-map that automatically selects an official design system based on the inferred brief. For example, if the brief mentions Material Design, the skill can target Material Web components; if it points to Microsoft tooling, it may select Fluent UI.

The v1 skill has no such mapping. It relies on generic Tailwind-based styling without automating the choice between systems like Carbon, Material, or Fluent UI.

// Pseudo-code that the skill could emit based on the brief
if (brief.includes("Material")) {
  // Pull in @material/web automatically
  import "@material/web";
}

Motion Handling and Library Imports

The two versions also differ in their recommended motion libraries. Taste-Skill v2 updates its motion stack to use Motion (formerly Framer Motion) through the motion/react import path. It also provides optional canonical GSAP skeletons for scroll-triggered effects, as documented in skills/taste-skill/SKILL.md#3-default-architecture-&-conventions.

Taste-Skill v1 still references Framer Motion but does not provide the newer motion/react shortcut. Its motion defaults remain more static and less integrated with the dial system.

Anti-Slop Policies and Constraints

The anti-slop rule set grew significantly in v2. In skills/taste-skill/SKILL.md#4-design-engineering-directives, v2 enforces detailed constraints automatically during generation. These include typography limits, color discipline, layout diversity caps, eyebrow limits, bento-cell counts, and motion-intensity checks.

The v1 skill contains a shorter set of rules. Many of the newer constraints—such as eyebrow caps and density-specific layout checks—are absent from skills/taste-skill-v1/SKILL.md.

Upgrade Path and Versioning Philosophy

The repository structures its releases around two distinct philosophies. Taste-Skill v2 is experimental and iterating quickly, introducing new concepts such as liquid glass, magnetic micro-physics, and canonical GSAP skeletons. It is intended to become the stable default in future releases.

Taste-Skill v1 is a stable snapshot preserved for exact behavior. Projects that need the original semantics can remain on v1 indefinitely by pinning the install target.

To upgrade from v1 to v2, install the default skill name. No code changes are required because the package simply overwrites the skill file. To remain on v1, explicitly lock the install target.

# v2 – the current default (experimental)

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

# v1 – lock to the original behaviour

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

Summary

• Taste-Skill v2 (design-taste-frontend) is the experimental default with a dynamic design pipeline.
• Taste-Skill v1 (design-taste-frontend-v1) is the static, frozen baseline for legacy compatibility.
• v2 adds brief inference, three tunable dials (DESIGN_VARIANCE, MOTION_INTENSITY, VISUAL_DENSITY), automatic design-system selection, and modern motion/react imports.
• v1 relies on fixed baseline values, generic Tailwind styling, and a smaller anti-slop rule set.
• Upgrading from v1 to v2 requires no code changes, but pinning to v1 requires an explicit install name.

Frequently Asked Questions

What is the main difference between Taste-Skill v2 and v1?

The main difference is that v2 is a dynamic, experimental skill. It infers a project brief and tunes three dials to control layout, motion, and density. In contrast, v1 is a static baseline with fixed configuration values and no automatic design-system mapping.

How do I install Taste-Skill v2 instead of v1?

Run the install command with the skill name design-taste-frontend. This targets the v2 rewrite by default and will overwrite any prior v1 installation in the project.

Can I stay on Taste-Skill v1 for an existing project?

Yes. Explicitly install the skill using the name design-taste-frontend-v1. This pins the original behavior and prevents the experimental v2 rules from replacing your current skill file.

Does upgrading from v1 to v2 require refactoring my codebase?

No. According to the repository's README.md, installing design-taste-frontend overwrites the skill file but does not require changes to your existing code. The v2 improvements apply to future generations driven by the skill.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}