Tastemaker
Generate genuinely beautiful, on-brand UI instead of generic "AI slop", use whenever...
Install
npx skills add codeswithroh/tastemaker --skill tastemaker -g -a claude-code -y- Repository
- codeswithroh/tastemaker514
- Category
- Design
- Updated
- 24d ago
- License
- MIT
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- Yes, review before use
What it does
Generate genuinely beautiful, on-brand UI instead of generic "AI slop", use whenever the user asks to build, design, style, or improve a UI, landing page, dashboard, app screen, or component, whenever a PRD/spec needs a design pass before implementation, whenever the user pastes reference images/Pinterest/Dribbble links and wants the app to look like them, or whenever the user complains the AI-generated UI looks generic, boring, cookie-cutter, or "like every other AI app." Make sure to trigger this even if the user doesn't say "design" explicitly, phrases like "make this look good", "build the frontend for X", "this looks like every other SaaS site", or "match this vibe" all qualify. Also triggers on two verbs, "study"/"extract the look of" a reference screenshot or URL, and "audit"/"review"/"why does this look AI-generated" for critiquing existing UI.
Tastemaker
The problem this solves
Ask an LLM to build a UI and it defaults to the same handful of patterns: indigo-to-purple gradients, the same rounded card with a soft shadow, the same generic hero layout. This isn't a prompting failure, it's what happens when a model has to invent visual taste from scratch, from a text description, with no grounding and no memory of what the person asking actually likes.
Most "design skill" approaches try to fix this by handing the model a bigger catalog of canned styles and palettes to pick from. That helps a little, but it's still generic, a library of canned options, not your taste, and it forgets everything the moment the session ends.
Tastemaker works differently, on three ideas:
- Ground in real pixels, not descriptions. If the user gives you references (images, screenshots, URLs), extract tokens from the actual reference, deterministically, with a script, instead of writing a text summary of the vibe and generating from that summary. Text-mediated style transfer is lossy; that's most of why AI UI looks generic even when the prompt describes something specific.
- Remember, don't re-derive. Once a project's style is established, lock it and reuse it for every subsequent screen or component in that project. Across projects, keep a lightweight personal profile of what this specific developer keeps vs. rejects, so returning users start warm instead of from zero.
- Scope to what's actually being built. If a PRD or spec exists, use it to figure out exactly which screens/components need design work, and target effort there, not a generic "here's a design system" dump disconnected from the real product.
- Treat craft as many small choices that compound. Taste is not one hero gradient or one dramatic animation. It is the right component library, the right hierarchy, the right empty state, the right easing, and the decision to delete motion where daily use would make it annoying.
