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

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, 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 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.

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, 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 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.

"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, 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.

// 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, 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 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 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.

Upgrade Path and Backward Compatibility

The repository maintains a seamless upgrade path. As noted in 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:

# 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. 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. 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, 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 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.

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