# What Is the Difference Between Taste-Skill v1 and v2? A Complete Feature Breakdown

> Understand the difference between Taste-Skill v1 and v2. Explore v2's data-driven pipeline with brief inference and adjustable dials versus v1's static baseline for full feature clarity.

- Repository: [Leon Lin/taste-skill](https://github.com/Leonxlnx/taste-skill)
- Tags: comparison
- Published: 2026-06-06

---

**TLDR:** Taste-Skill v2 introduces an experimental, data-driven design pipeline with brief inference, three adjustable dials, and automatic design-system selection, while Taste-Skill v1 preserves the original static baseline with fixed values for backward compatibility.

The `taste-skill` repository by Leonxlnx is an "anti-slop" frontend skill that guides AI agents toward high-quality UI code generation. It ships two distinct versions that share a goal but differ sharply in execution. Understanding the difference between taste-skill v1 and v2 ensures you pick the correct install name and generation behavior for your project.

## Installation Names and Version Status

Both versions live in the same repository but expose different skill names. According to [`README.md`](https://github.com/Leonxlnx/taste-skill/blob/main/README.md), the default command now pulls the experimental rewrite:

- `design-taste-frontend` — Taste-Skill v2 (experimental, current default)
- `design-taste-frontend-v1` — Taste-Skill v1 (preserved for exact legacy behavior)

If you run the standard install without a version suffix, the v2 spec in [`skills/taste-skill/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md) overwrites any previous v1 file automatically. To stay on the original semantics, you must explicitly install `design-taste-frontend-v1` from [`skills/taste-skill-v1/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill-v1/SKILL.md).

## Design Workflow: Static Baseline vs. Dynamic Dials

The core philosophical split between the two versions centers on how design decisions are made.

### How v1 Handles Design Configuration

In [`skills/taste-skill-v1/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill-v1/SKILL.md), the original skill relies on **active baseline configuration** with fixed values. It sets static defaults for variance, motion intensity, and visual density, then applies them uniformly across generated components. This produces predictable, cookie-cutter output that does not adapt to project context.

### How v2 Adds Brief Inference and Tuneable Controls

Taste-Skill v2 replaces the static baseline with an explicit **brief inference** step—described in [`skills/taste-skill/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md) as "read the room." After inferring the brief, v2 injects three runtime dials:

- `DESIGN_VARIANCE` — drives grid complexity and layout diversity
- `MOTION_INTENSITY` — controls animation depth and timing
- `VISUAL_DENSITY` — governs spacing and component compactness

These dials enable conditional generation logic. For example, a component can switch between `grid-cols-1` and `grid-cols-2` based on the variance value emitted by the skill.

```tsx
"use client";
import { motion } from "motion/react";

export const Hero = ({ title }: { title: string }) => {
  // Dials 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>
      {/* …additional layout driven by `density` … */}
    </section>
  );
};

```

In v1, the same component would be generated with hard-coded constants and no branching layout logic.

## Design-System Mapping

Taste-Skill v2 includes a **decision table** that automatically selects an official design system based on the inferred brief. As documented in [`skills/taste-skill/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md), the skill can map requirements to Fluent UI, Material, Carbon, or other canonical libraries.

Taste-Skill v1 has no such mapping. It relies on generic Tailwind-based styling without automatic system injection. The v2 skill can emit conditional imports, whereas v1 leaves framework choices entirely to the agent.

```tsx
// Pseudo-code the v2 skill can emit based on the inferred brief
if (brief.includes("Material")) {
  // Pull in @material/web automatically
  import "@material/web";
}

```

## Motion Handling Differences

Animation defaults diverge between the versions. In [`skills/taste-skill/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md), v2 specifies **Motion** (formerly Framer Motion) via the `motion/react` import and supports optional GSAP skeletons for scroll-triggered effects.

The v1 spec in [`skills/taste-skill-v1/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill-v1/SKILL.md) still references Framer Motion but lacks the streamlined `motion/react` shortcut. Its motion defaults remain more static, and it does not include the canonical GSAP skeletons introduced in the rewrite.

## Anti-Slop Policy Coverage

Both versions enforce quality guardrails, but v2 dramatically expands the rule set. The v2 experimental skill in [`skills/taste-skill/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md) automatically enforces detailed constraints covering:

- Typography scale and hierarchy limits
- Color usage caps
- Layout diversity minimums
- Eyebrow text limits
- Bento-cell counts
- Motion-intensity checks

The original v1 skill ships a shorter static rule set. Many of the newer constraints—such as eyebrow caps and bento-cell counts—are absent from [`skills/taste-skill-v1/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill-v1/SKILL.md).

## Upgrade Path and Backward Compatibility

The repository maintains a seamless upgrade path. As noted in [`README.md`](https://github.com/Leonxlnx/taste-skill/blob/main/README.md), installing `design-taste-frontend` overwrites the v1 file with the v2 version, and **no code changes are required** in consuming projects.

If your pipeline depends on the exact generation behavior of the original skill, pin explicitly to the legacy install:

```bash

# v2 — current experimental default

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

# v1 — legacy baseline with fixed values

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

```

## Summary

- **Taste-Skill v2** is the experimental default in [`skills/taste-skill/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md). It adds brief inference, three tuneable dials, automatic design-system mapping, `motion/react` imports, and exhaustive anti-slop rules.
- **Taste-Skill v1** is the preserved baseline in [`skills/taste-skill-v1/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill-v1/SKILL.md). It keeps static fixed values, generic Tailwind styling, and a smaller rule set for projects that need legacy semantics.
- The install name determines which version you receive: `design-taste-frontend` for v2, `design-taste-frontend-v1` for v1.
- Upgrading from v1 to v2 requires no code changes; installing the default overwrites the skill file automatically.

## Frequently Asked Questions

### Can I install both taste-skill v1 and v2 in the same project?

No. Both versions use the same underlying skill slot, and installing `design-taste-frontend` overwrites the v1 file with the v2 spec. If you need exact legacy behavior, you must explicitly install `design-taste-frontend-v1` and avoid the default command.

### Will upgrading from v1 to v2 break my existing generated components?

No. According to [`README.md`](https://github.com/Leonxlnx/taste-skill/blob/main/README.md), no code changes are required when moving from v1 to v2. The upgrade simply swaps the skill definition file; previously generated components remain unchanged unless you regenerate them with the new v2 rules.

### Why does v2 recommend `motion/react` instead of `framer-motion`?

The v2 spec in [`skills/taste-skill/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md) adopts the newer Motion library branding and uses the `motion/react` import path. This reflects the upstream rename from Framer Motion to Motion and provides the latest animation primitives, whereas v1 still references the older naming without the streamlined import.

### Which version should new projects use?

New projects should default to `design-taste-frontend` (v2). It offers the richer, data-driven pipeline, broader anti-slop coverage, and automatic design-system mapping. Only choose `design-taste-frontend-v1` if you have a hard dependency on the original static baseline behavior.