Bunny Honey ClubBunny Honey/blog
Subscribe
← back to indexblog / claude / the-taste-skill-md-system-enforcing-design-rules-with-ai
Claude

The taste-skill.md system: enforcing design rules with AI

I got tired of AI tools ignoring my design system. So I wrote a single file — taste-skill.md — that teaches v0 and Claude my ai design system prompt rules.

A
ArthurFounder, Bunny Honey Club AI
publishedNov 14, 2025
read6 min
The taste-skill.md system: enforcing design rules with AI

A year ago I got fed up. Every AI tool I used produced interfaces that looked like they had been assembled by someone who had seen a website once. Generic spacing. Generic type. The same three shades of gray. I wrote a single Markdown file

A year ago I got fed up. Every AI tool I used produced interfaces that looked like they had been assembled by someone who had seen a website once. Generic spacing. Generic type. The same three shades of gray. I wrote a single Markdown file called taste-skill.md, handed it to v0 and Claude and Cursor, and within a week the output went from "acceptable for a landing page demo" to "close enough that my designer noticed." This is that file, why it works, and the rules I keep breaking when I don't use it.

The problem in one sentence

AI tools have no taste. They have average taste. The model saw a million websites and is producing the median one. That median is exactly the thing I don't want to ship.

The solution most people reach for is a design-system package. That's the right answer for production code. It's the wrong answer for the generation step. The model isn't going to read a Figma file or a multi-package monorepo. It's going to read whatever is in front of it and guess.

So I wrote what I wanted it to read.

What taste-skill.md looks like

It's three hundred lines. Short prose, no headers that try to be clever. It is written in the voice of me correcting a junior designer, because that voice is what the model responds to.

# taste-skill
 
Start with black. Background is #0a0a0a. Text is #f2efe8. Accent is one color,
picked per project, never more. If you find yourself reaching for a third
accent, the second accent is wrong.
 
Don't round everything. Pills for buttons (radius 999). Cards at 10px. Images
at 10px. Nothing in between. If you're typing radius: 6 or 16, stop.
 
Type: Outfit display, Geist sans body, Geist mono for labels. One size bigger
than feels right, one size smaller than feels loud. Don't use Inter. Don't use
Poppins. Don't use whatever you reach for by reflex.
 
Leave space. The line between "clean" and "sparse" is the line between "looks
good" and "looks AI-generated." Lean sparse.

That's the first fifteen lines. The rest is in the same voice. No bullet lists except where bullet lists are the right thing. No code blocks except where they illustrate a decision I've already made.

The model reads this and produces markedly better work. It also produces consistent work across tools, which is the part I underestimated. The same file in v0 and Claude Code yields interfaces that look like they come from the same designer, because in a sense they do.

1file
~300lines
designer approval rate vs. no file
0external dependencies

Why prose beats rules

The first version was a rules list. "Radius: 10px for cards." "Accent: one color per project." "Spacing: multiples of 4."

It didn't work. The model obeyed the letter and violated the spirit. Cards came back at radius 10 and looked wrong because the button next to them was radius 12. Every rule I added spawned a new violation.

The version that works is prose with reasoning. "Pills for buttons (radius 999). Cards at 10. Images at 10. Nothing in between." The nothing in between is the part that made the rest of the file actually land. I'm not listing allowed values; I'm describing the shape of the choice.

The model, I've learned, is bad at rule systems and good at narrative. Give it a story about taste and it picks up the underlying logic. Give it a spreadsheet and it plays field-match.

The "never do this" section

Half of taste-skill.md is negative instructions. Things I don't want to see, written plainly.

## Never do this
 
Do not center-align body text. Do not use purple as an accent unless the
project literally is about something purple. Do not put an icon in every
button. Do not use a carousel. If you're about to suggest a carousel,
propose three things in a row instead.
 
Do not suggest dark mode if the project is already dark. This is not a toggle.
The design is dark. Stop adding a sun icon to the header.
 
Do not use the word "elegant" or "sleek" in any label on the page. Those are
what marketers use when they didn't have anything real to say.

The never-do section is a heuristic I'd never put in a public design system, because in a public context it reads as rude. To the model, it's a gift. It collapses hundreds of pages of training data into do not.

Rude to the model, kind to the final output. I'm fine with the trade.

How I pin it in practice

In Claude Code: the file lives in the repo at /taste-skill.md and the CLAUDE.md references it. Every session reads it.

In v0: I paste the first chunk into the first message of a new project and tell the model to re-read it before every major change. v0's memory across a conversation is good enough that this sticks for the session.

In Cursor: I put it in .cursor/rules/ and it applies per-project. This has been the most reliable of the three. Cursor's rules surface is designed for exactly this.

For a one-off page built in Lovable or Bolt: I paste it with a blunt preface — "This is taste-skill.md. Follow it. Don't override it with your default style." It mostly works. Their system prompts sometimes fight mine. I've shipped around the conflict more than I'd like.

What I don't put in the file

Brand. Colors and typography that belong to a specific client project go in a brand.md next to the design system taste file. taste-skill.md is about me — about my defaults, what I reach for, what I flinch at. Brand is about the project.

Mixing them produced a mess. The model couldn't tell which constraints were non-negotiable (brand) and which were mine to override on a specific engagement (taste). Split the files. Read both. The model handles the composition.

Copy rules also don't live here. I've got a separate voice.md for writing style, which is about tone rather than layout. taste-skill is aggressively visual — spacing, type, radius, accent. That narrowness keeps it small.

The meta-skill trick

Claude Code supports "skills" — bundled prompts the model can invoke. I used to publish taste-skill as a skill. I stopped. A skill is good when the model can choose to invoke it. For something that should apply all the time, putting it in the system context is more reliable than hoping the model picks it up.

So taste-skill.md is no longer a skill. It's just a file the model reads on startup. The word "skill" in the name is residual; I kept it because the file's job is still to teach the model a skill it doesn't have.

It's not that it looks like me. It's that it looks like it was made by someone who has opinions. That's a much higher bar than most AI output clears.

my designer, looking at a v0 output generated with the file loaded

What this bought me

Speed, mostly. I can now start a project with v0, iterate in Claude Code, polish in Cursor, and ship without a visual review from my designer blocking the path. The designer still reviews; she just doesn't gate.

The second thing it bought me was consistency across tools. Before taste-skill.md, a v0 page and a Claude-generated landing looked like they had been done by different people. Now they don't. The tools become a pipeline with a shared aesthetic instead of a stack of slightly-incompatible styles.

The third thing, which I hadn't expected: writing the file made my actual taste clearer. I'd been working from feel for years. Having to put the rules in prose forced me to say out loud what I'd been doing silently. That clarity carries into the designer conversations too.

The three-month file

taste-skill.md is not a static artifact. Mine is on version fourteen. Every few months I throw out sections that stopped mattering and add new ones for things I've noticed I hate. A file that hasn't changed in a year is either too abstract to be useful or describing a taste that stopped evolving.

If you're building yours: write the first draft in one sitting. Ship it. Use it for a month. Notice every time the model does something you'd have corrected in a design review, and add a line to prevent the next one. By month three you have a file that actually looks like you. By month six it's the thing you wish you'd written a year ago.

— filed underClaudeDesignTooling
— share
— keep reading

Three more from the log.