I build a lot of side projects with AI coding tools. Mostly Claude Code. A few months ago I noticed something that kept bugging me. Every site I shipped looked the same. Same indigo gradient. Same default font. Same rounded cards with the same soft shadow.
Then I started noticing it on other people's projects too. Demo days, launch posts, screenshots on social media. The indigo gradient is everywhere. It is basically a uniform at this point.
This is not really the AI's fault. When you do not give a model a design direction, it picks the average of the internet. And the average of the internet is a Tailwind starter template with an indigo gradient and Inter. The model is doing exactly what it was trained to do. The problem is that nobody told it what you actually want.
So I built tastemaker. It is a skill for Claude Code, and it also works with Cursor, Windsurf, and Codex. The idea is simple: lock the design system before the AI writes a single line of UI.
Full disclosure before we go further: I built this. I am a solo builder. It is free and open source under the MIT license. I am posting it here because I want honest feedback, not because I have anything to sell you. There is nothing to buy.
Taste first, code second
A skill is just a folder of instructions the AI reads before it starts working. tastemaker forces a design decision step at the beginning, with real constraints, instead of letting the model improvise the look as it goes.
When you start a UI project with it installed, this is what gets locked before any code exists:
- A palette. 5 presets, each matched to a mood. Not random hex codes. Combinations that were picked to work together.
- Fonts. 24 curated Google Font pairings. A display font and a body font that actually belong on the same page.
- Real assets. Illustrator-grade illustrations, recolored to your palette. No gray placeholder boxes. No generic stock photo energy.
- A logo. A constructed geometric mark, plus a full favicon set, so the tab icon is not the framework default.
- Motion. GSAP and ScrollTrigger wired in by default, so scroll animation is a starting point, not a TODO you never get to.
The point is not that my taste is better than yours. The point is that any taste, written down and locked, beats no taste at all.
The part where I failed
This is my favorite part of the story, mostly because it is embarrassing.
I picked the 5 palette presets by eye. They looked good to me. I was confident. Then, because I wanted to be thorough, I wrote a small Python script to check every text-on-background combination against WCAG contrast ratios.
The first run failed 2 of my 5 presets.
My eyes said the palettes were fine. The math said real people would struggle to read the text. The math was right. I went back, adjusted the failing colors, and kept running the check until everything passed. All 5 presets that ship today pass that contrast check.
That little story is the whole argument for the project. Taste feels subjective until you write it down and test it. Once it is written down, you can check it, fix it, and reuse it. My eyeballs were wrong 40 percent of the time. A short Python script was right every time.
Install
One command, then restart Claude Code:
git clone https://github.com/codeswithroh/tastemaker ~/.claude/skills/tastemaker
That is the whole setup. No API keys. No config file. No account. Restart, start a UI project, and the design system gets locked before the AI starts guessing.
More details on the site:
Source code:
codeswithroh
/
tastemaker
A Claude Code skill that grounds AI-generated UI in real reference images and a persistent per-developer taste profile, instead of generic AI-slop defaults.
A skill that gives AI real design taste, so the UI it builds does not look AI-generated.
Quick start · Why · Features · Presets · How it works · Contributing
What this is
Tastemaker is a skill for coding agents (Claude Code, Cursor, Windsurf). You install it once and forget it. Whenever you ask your agent to build or style a UI, tastemaker steps in and gives it a real design system to work from, instead of the generic defaults every model reaches for.
It is plain Markdown and small Python scripts. Everything runs on your machine. There is no hosted backend, no account, and no API key.
Why AI UI all looks the same
Ask any model to build a UI and you tend to get the same thing: an indigo to purple gradient, a soft shadow card, a generic…
What I learned
A few things, in order of how much they surprised me.
First, constraints make AI output better, not worse. I expected locking the palette and fonts to feel limiting. It did the opposite. The model stopped spending effort on design indecision and spent it on the actual product. The output got more interesting, not less.
Second, the default look is a choice. Every time you skip the design conversation, you are choosing the average of the training data. That is still a design decision. It is just a boring one you made by accident.
Third, scripts beat eyeballs. I trust my taste. My taste failed 2 out of 5 times on a basic readability check. Now I write the check first and pick the colors second, and I think that order matters more than people realize.
Fourth, design debt starts at line one. Most of us treat design as a cleanup pass at the end of a project. With AI tools, the end never arrives, because there is always one more feature to generate. Deciding first is cheaper than fixing later.
If you try tastemaker, tell me what broke. Feedback is genuinely welcome, in the comments here or as an issue on GitHub. And if it saves you a few hours, a star on the repo helps other people find it.
Top comments (9)
"When you don't give a model a design direction, it picks the average of the internet." That sentence explains a pattern I couldn't name until now.
I'm a non-developer building internal tools for a hospital with AI, and every screen I ship carries a house style — one font (Pretendard, since it's Korean), one blue, sidebar-plus-topbar, light/dark. It wasn't a taste decision at first, honestly; it was self-defense. Left to its own averages, the AI gave me a slightly different-looking app every single time, and 20-something tools that each look like a different company is its own kind of broken for the people who have to use all of them daily. Locking the constraints upfront didn't just make them prettier — it made them feel like one system, which for internal software matters more than beauty.
Your "constraints make AI output better, not worse" is the counterintuitive core, and I'd push it one step further: the constraint also makes the AI faster. Once the palette and layout are fixed, the model stops re-litigating them on every screen and spends its effort on the actual logic. I didn't plan that; I just noticed the builds got quicker once I stopped leaving design open.
And the 40%-wrong-eyeballs line is the real gift here. I've been approving contrast by eye like an amateur. Handing that judgment to a WCAG script — a thing that doesn't have a bad day or a favorite color — is exactly the "let something without feelings check it" discipline I keep re-learning everywhere else. Adding that check to my own house style this week.
Great to know that you are putting the effort into doing all this. I used to do all these manually as well. Used to define my pallet and the storyline and when building a focused product, that is really necessary. But there are a lot of people who are still shipping sites which looks like ai-slops and they don't know how to really improve them. So, I built these skill using all the things I learned from my experience so, that everyone can create professional sites from the getgo instead of building their own branding or color pallet from the beginning.
Again thanks a lot for checking this out. Hope you can try this out, would love to know your feedback regarding this skill and ways to improve this.
Your mission is the part I connect with most — "professional from the get-go instead of building branding from scratch." I build internal tools for a hospital as a non-developer, and I've watched capable coworkers ship things that work perfectly and look like ai-slop, then have no idea why it feels off or how to fix it. Taste is the invisible tax on people who were never taught it, and packaging it into something installable is genuinely useful work.
Here's the concrete thing I owe you: your "my eyeballs were wrong 40% of the time, the script was right every time" line didn't just resonate — it made me go build the thing. Today I wrote a small WCAG contrast checker and ran my whole house palette through it. The surprise matched yours exactly: the parts I'd fussed over (status badges) were fine, and a link color I'd approved by eye months ago was sitting at 3.44:1 — quietly failing, invisibly, the whole time. I'd never have caught it by looking. That one paragraph of yours paid for itself the same afternoon I read it.
I'll try Tastemaker and send real feedback. One honest note up front on where my case might bend it: my work is Korean-language internal apps — Pretendard font, dark/light, a sidebar-plus-topbar app shell — rather than marketing sites. So I'm curious how much of the palette/font/motion locking survives that context versus how much quietly assumes a landing-page shape. That's exactly the edge worth reporting back on: a tool meeting a use case its author didn't build for is where the most useful feedback usually lives.
This feedback is really helpful. One major thing to add in my skill is multiple language support. Thanks for this idea. Will keep the other ideas in mind as well.
Thanks a lot for sharing this again, hope you find the skill useful.
That's the one I'd have picked too. One thing that might save you time when you get to it: CJK (Korean/Japanese/Chinese) isn't just "swap the font" — the whole pairing logic shifts. Latin design leans on pairing a display font with a body font, but Korean UI usually rides a single well-built family across all weights (Pretendard is the go-to) because mixing families reads as messy in Hangul. Weight rendering and letter-spacing behave differently too. So the taste-lock for CJK might be less "font pairing" and more "one family, locked weights, correct line-breaking" — the same idea in a different shape. Happy to be your test case whenever you want eyes on the Korean side.
Woahh thanks for the insights. These are really helpful and interesting. Will definitely make my updates accordingly and it will be great, if you could test it out.
Appreciate your comment.
Deal — ping me when the multilingual update lands and I'll run it against a real Korean app, then send you the honest results, warts and all. That's the fun part: you'll get to see exactly where the taste-lock holds and where Hangul makes it flinch. Looking forward to it.
Locking the palette, font pairing, assets, logo, and motion rules before UI code turns "taste" into an interface contract instead of a vague preference. The contrast check is the strongest engineering detail here: two of five presets looked fine by eye but failed WCAG, which shows why visual systems need automated constraints as well as judgment. For a solo builder, this also creates a cheap review surface-before polishing components, you can ask whether the page still obeys the chosen system or has quietly drifted back toward the default indigo template.
Yes Marcus exactly. Instead of starting from the default purple gradient website, this skill give you a great starting point and builds your site with the best practices built in. After that point everyone can alter the sites according to their own taste.