Taste Skills Are the New Design Tokens

Design tokens solved the atom. Taste skills solve the molecule.

Design tokens fixed a generation of problems. Before tokens, every button had its own hex code. Every spacing value was picked by vibes. Every shadow was a magic number. Tokens gave us one place to encode the atomic decisions.

But tokens stop at the atom. They tell you that color.background.primary is #FBFBF9. They do not tell you when to use it, what never to pair it with, or what the result should feel like.

Taste skills pick up where tokens stop.

---

The shape of the shift

For 10 years the design system conversation was about making values reusable. Tokens, variants, component APIs. All focused on the same question: how do we stop picking new values every time we build a screen?

The answer was: extract the values, name them, reference them.

The same thing is now happening one layer up. The question has changed to: how do we stop re-explaining our taste every time we open a new AI tool?

The answer is the same shape: extract the taste, name it, reference it.

---

What tokens solved (and did not)

Tokens solved five problems:

1. Arbitrary values disappeared. Nobody picks #3B82F6 anymore. They reference color.brand.primary.
2. Onboarding got faster. New designers learned the system, not a scatter of hex codes.
3. Theming became real. Light mode, dark mode, and branded themes became configuration instead of rebuilds.
4. Audits became possible. You can check for unauthorized colors programmatically.
5. Handoff tightened. Designers and engineers worked from the same source of truth.

But tokens did not solve:

1. When to use which token. A token tells you color.background.surface exists. It does not tell you when to reach for it.
2. What never to combine. A token does not know that your accent color should never touch a gradient.
3. What the output should feel like. Tokens are values, not opinions.
4. How to review generated output. A token is not an audit.
5. Anti-patterns. Tokens say what is allowed. They do not say what is forbidden.

The gap between “what values exist” and “how those values should be used” has always been held in designers’ heads. Tokens assumed a human would fill that gap.

AI does not fill that gap. It fills it with the statistical average of the internet.

---

Why this matters now

Two things changed at the same time:

1. AI tools generate UI from prompts. A huge amount of design work is now being produced by tools that only read text.
2. Those tools have no access to your design judgment unless you write it down.

If you do not write it down, the tools use their default. Their default is the internet average. That is why every AI site looks the same.

The next generation of design systems has two halves:

• The token half, for atomic values (colors, type, spacing, radius, shadow).
• The taste half, for the judgment that decides how those values combine.

Design systems that only ship the token half will lose the taste war. Design systems that ship both will produce AI output that looks like the brand, even when a junior designer or a PM is the one running the prompt.

---

The parallel between tokens and taste skills

Criterion	Design tokens What values exist	Taste skills How they combine
Scope	Atomic values	Composition logic + anti-patterns
Format	JSON, YAML, CSS vars	Markdown (SKILL.md)
Consumed by	Code, Figma, Style Dictionary	Claude Code, Cursor, AI tools
Unit of reuse	One value	One rule or one audit
Versioned	Git	Git
Audited via	Linters, Figma variables	/taste-audit and related skills
Answers	What values exist?	How should they combine?

Both layers are codified. Both are reusable. Both are version-controlled. Both have a defined consumer. Both have an audit story.

The difference: tokens tell you what. Taste skills tell you how, when, and never.

---

What a taste skill encodes that a token cannot

A token can say:

• color.background.primary = #FBFBF9
• spacing.section.large = 120px
• motion.duration.fast = 150ms

A taste skill can say:

• “When the brief says premium, do not default to dark + gold + serif.”
• “Only one gradient per page, and only if it is the single visual accent.”
• “Never animate hero content. Hero is always static.”
• “No buzzwords: leverage, unlock, empower, supercharge.”
• “At least one element on every page must feel non-default. State which one.”

Tokens are nouns. Taste skills are verbs. You need both.

---

How a design system evolves into a taste system

A typical design system today ships:

• A token file (Core, Themes, Layout)
• A component library (with documented props and variants)
• Usage guidelines (written in Notion or Mintlify)
• A Figma library
• Some linting rules

A design system for the AI era adds:

• A root CLAUDE.md that encodes global design standards in plain language
• A set of skills in ~/.claude/skills/ for common audits: taste, motion, anti-patterns, copy tone
• A machine-readable anti-pattern list
• A /generate-component skill that wraps the system’s component conventions into a prompt
• A /brand-audit skill for agency or consulting deliverables

The second layer lives alongside the first. The tokens still work. The components still ship. But the whole system is now readable and enforceable by AI tools.

---

The consulting and hiring implications

Three things shift when taste becomes a skill instead of a heuristic.

1. Taste becomes auditable

For 20 years, “has good taste” was an unfalsifiable claim. You either had it or you did not. Portfolios were the only way to check.

When taste is encoded as rules and scorecards, it becomes checkable. A hiring manager can read your ~/.claude/skills/taste/SKILL.md and see the shape of your judgment.

A client can read your brand taste skill and see how specific you are about their standards.

2. Taste becomes a product

A well-tuned taste skill is a shippable artifact. You can sell it. Ship it as a template. Include it as a consulting deliverable. Use it as the backbone of a course.

This is why I believe the next design-systems offer is not a Figma library plus documentation. It is a Figma library, documentation, AND a set of skills that make the system enforceable by AI tools.

3. Taste becomes leverage

One well-tuned taste skill applied across every project you touch produces more consistent output in less time than a human reviewing each page by hand.

For solo consultants, that is leverage that did not exist a year ago. For agencies, that is a new product line. For design-system leads, that is a new artifact in the deliverable stack.

---

What to build first

If you already have a design system:

1. Extract the top 10 rules from your documentation. Put them in a root CLAUDE.md in the system’s repo.
2. Write a /brand-audit skill that audits generated output against those 10 rules.
3. Ship the skill in your system repo. Teach your team to invoke it.

If you do not have a design system yet:

1. Follow the Build Your Own Taste Skill workshop.
2. Use the resulting ~/.claude/skills/taste/SKILL.md as your personal default on every project.
3. When a client or project needs different rules, create a project CLAUDE.md that extends or overrides your personal taste.

Either path lands in the same place: a codified, versioned, AI-readable encoding of your design judgment.

---

The bigger bet

Design tokens are 10 years old as a concept. They became a standard because the problem they solved (arbitrary values everywhere) was real and the solution (extract + name + reference) generalized cleanly.

Taste skills are at the start of the same arc. The problem they solve (AI output uses the internet’s taste unless you override it) is real. The solution (extract + name + reference the judgment) generalizes the same way.

The design systems that win the next 5 years will not be the ones with the most components. They will be the ones with the most complete taste encoding, so that every agent, every prompt, every generation produces output that feels like the brand, even when no designer is in the room.

Exercise

Extract ten taste rules from your current system and ship them as a skill

60 min

1. Pull ten real rules out of your existing docs

   Open your design system documentation (Notion, Mintlify, Zeroheight, wherever it lives). Find ten actual rules that currently live as prose. Rules like “buttons always use the accent token, never a raw hex”, “danger is reserved for destructive actions, never generic errors”, “hero sections stay static”. Paste them into a fresh markdown file as a numbered list. Do not rewrite them. Use your existing language.

   • Ten rules, each a single sentence
   • Every rule is a decision you have already made, not an aspiration
   • At least three rules include a “never” clause (taste is mostly about what to forbid)
   • Someone reading them could audit a generated page against each one

2. Turn the list into a working /brand-audit skill

   Save the file as ~/.claude/skills/brand-audit/SKILL.md. Add frontmatter: name: brand-audit, description: Audit generated UI against my brand's ten taste rules. Use when reviewing AI-generated pages or components. Add an opening line: “Review the most recent generation against the rules below. For each violation, name the rule number, quote the offending element, and propose a fix.” Paste the ten rules beneath. Run /brand-audit on a recent Claude Code generation.

   • /brand-audit triggers the skill (not a generic response)
   • The output references specific rules by number (“violates rule 3”) and specific elements (“the hero CTA uses a raw hex”)
   • At least one violation was caught that you had not noticed by eye
   • The skill took less than ten minutes to build and can now be reused on every project