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 (43)
"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.
Ok amazing. Here is my X: x.com/codeswithroh
We can connect in here. Once, the update is live I will ping in the comment and if you connect on X then can ping you there as well
Appreciate the offer to connect. I keep my footprint pretty minimal right now, so I'll catch your update here in the comments the moment it lands — and I'm genuinely good for that Korean-app test whenever it does. Looking forward to seeing how it handles Hangul.
It's a cool thing, but your installation path didn't work, and one off your images are broken. However, here's what I built with it :)
I added it as a skill to Magic Cloud, and the system did the rest. Impressive ^_^
Wow, this really looks good. I have updated the site with each and everything. I am sure that it will work now.
Thanks a lot for using it. Hope you find it useful.
Loved it, feel free to play with my stuff too ==> github.com/polterguy/magic
yeah definitely will check it out
Psst ... ;)
10 minutes worth of work with Claude and Magic Cloud, connected over MCP, using your skill 😇
My prompt; "I want you to use the Magic connector and create a new app named "crm5". I need a database with 3 tables, CRUD web API, the ability to send emails to contacts, and a kick ass modern designed frontend at "crm5". Use the "magic auth" workflow and only allow users belonging to the role "guest" to invoke the API."
The system created my database, API endpoints, secured them, the frontend, etc. Then when done, it used the headless browser to verify everything is 100% perfectly working, even did a couple of "intrusion attempts" to bypass the authorization requirements (no security holes).
The system allows you to do CRUD towards your contacts, contains a pipeline, and the ability to send emails to individual contacts.
This looks so clean. I really love what you have built here. If you could share a link of your product that you have built, I would definitely love to showcase it on my site.
Thank you, I just wrote an article about it here actually ==> hyperlambda.dev/blog/everything-su...
I even mention tastemaker rapidly inside the video actually :)
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.
The WCAG story is doing more work than you think, and it actually undercuts the "5 presets" framing. Contrast ratio is pairwise — text-on-background, border-on-fill, disabled-on-surface. A preset that passes for your locked heading-on-hero can still fail the moment the model uses one of your palette colors as a badge background with white text, which it will, because you handed it a palette and no contract for how each color gets used. You checked the combinations you designed; the AI improvises combinations you didn't.
So the durable version of this isn't "5 presets that passed once." It's shipping the contrast check as a token-level constraint the model has to satisfy for every new pairing it invents — semantic roles (text, muted, accent-on-accent) with required ratios attached, not just hex values that happened to test clean. Otherwise you've moved the indecision from "what colors" to "which of these five approved colors can touch which," and the model is back to guessing on the part that actually breaks readability.
The broader point I'd pull out: your eyeballs weren't wrong because taste is subjective — they were wrong because contrast is a computation your eyes don't run. Those are different failures, and only the second one generalizes into a script.
Thanks for your feedbacks, really appreciate it.
And yes the model has the 5 pallets at disposal but its not bound by it and i have given the skill the ability to actually do a contrast test based on WCAG on every iteration so, that whenever a site is generated, it actually tests the score and modify it accordingly. Setting the presets of which color goes where might limit the creativity of the agent and be more restrictive. Bt definitely more improvements can be done here.
One point that really stands out is that AI doesn't eliminate the need for architectural thinking, it actually makes it more valuable. At IT Path Solutions, we've seen that when teams invest time in defining architecture, constraints, and success criteria upfront, AI-assisted development becomes far more predictable, maintainable, and scalable.
Yeah, I completely agree with this. If you put more context into what you are building and what you are doing, it will always be much, much better at what AI does. And the more context you give in, the more data that you give it, the more directional and refined output you will get.
The detail that sticks with me is 2 of 5 palettes failing your own contrast checker. It captures something I keep running into with AI generated interfaces, my own eye is a worse judge than a script that takes five seconds to run, yet I default to trusting the eye because it feels like taste. What I have found works is treating constraints like yours as gates rather than guidelines, so the agent cannot proceed past a failed check instead of me catching it later in review. Curious whether Tastemaker enforces the WCAG check automatically or if that is still a manual step you run after generation.
Glad you find it relatable. It's completely automatic, you don't need to do any manual prompting or anything. From the get-go, it will check the WCAG.
After this post, I have made a lot of updates. Now, instead of five presets, it will automatically generate a color palette that will suit your brand the most. All the color palettes that are generated are perfect score, and it will look great on your brand. Hope you check this out, and let me know if you have any feedback.
This hits the spot so well. The generic indigo gradient with rounded cards has definitely become the official signature look of AI-generated web apps lately.
When building client-facing platforms in custom software development services, setting strict design systems, color tokens, and accessibility constraints upfront is essential before writing a single line of code. Letting an AI model improvise design choices always leads to that average internet look.
Testing contrast ratios programmatically was a smart move too. Automated accessibility checks save so much time compared to trusting visual judgment alone.
Really cool project, thanks for making it open source!
Thanks a lot for the appreciation. And yes, the problem that you have faced, I have faced the same problem too. Maybe that is one of the reasons why I made this project open source, because I believe that everybody should have this for free, so that they could create a site that is truly professional and can be worth sharing without paying any money.
This hits the nail on the head! The "average of the internet" design bias is so real almost every AI starter kit right now defaults to that same indigo gradient and standard Tailwind card style.
Your takeaway about scripts beating eyeballs (the 40% failure rate on WCAG contrast) really resonated with me. While building Synctoolo (a suite of 25+ free browser-based developer and AI utilities), I constantly ran into the challenge of keeping the UI clean, readable, and fast without falling into the "AI-slop" aesthetic. Having an automated gatekeeper for contrast and design tokens before writing code is such a smart move.
Great open-source contribution! Definitely starring the repo to test out the WCAG automation in my own workflow.
Thanks a lot for the appreciation, and thanks a lot for the star. I am constantly making a lot of updates. Hope you check the new one out, and let me know what you think.
The WCAG part is what makes this more than a style preference.
Taste can get you close, but checks make it reusable and safe. A palette that looks good but fails contrast is not a design system yet, it is just a vibe with unreadable text.
Yep, absolutely. And after the post, I have made a lot of updates. Now instead of five presets, you get a lot more.
Now the skill will generate a specific color palette based on your brand. Every site would look much cleaner and professional.
I hope you use the skill and make good use of it. Literally, share any feedback that you have
As a backend dev, I just have to say frontend is such a beast and design is harder than it looks. and yes, everything DOES look the same nowadays. Even taste is no longer original.
Yes, absolutely. That's why I have built this site.
As a backend developer, I hope you can use this skill and make your frontend look much, much better. To be very honest, I am a backend developer too, so I really know the pain of building a good frontend. But with this skill, I believe it will really help you in doing that.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.