codeswithroh/tastemaker: a Claude Code skill that grounds AI UI in real reference images

The problem tastemaker targets: AI UI that looks AI-generated

Ask a coding model for a landing page and the README says you tend to get the same result: an indigo to purple gradient, a soft shadow card, a generic hero. The project's argument is that this is not a prompting failure. The model has to invent taste from a text description, with nothing real to ground it and no memory of what you actually like. Tastemaker is a skill for coding agents that intervenes at exactly that point. It is aimed at developers who use an agent to build UI and are tired of restyling the same defaults on every new project. The README names Claude Code as the recommended host, with Windsurf and Gemini CLI also supported natively. It is plain Markdown and small Python scripts, with no hosted backend, no account and no API key, which matters if your code cannot leave the machine.

How tastemaker works: generated palettes, a contrast matrix, and two memory files

The mechanism rests on four ideas the README lays out. First, there is no fixed list of color combinations shipped with the skill. A palette is generated per project, a fresh hue and harmony each time, against a contract enforced by a script: check_contrast.py --matrix computes every pairing and reports which may carry text, which may carry a border, and which may carry neither. That is the design choice worth pausing on. The constraint is a computation rather than a written preference, so it returns the same answer regardless of how the palette looked to you. Second, references are read as pixels. extract_palette.py reads real colors from an actual image instead of having the model write a summary of the vibe and rebuild from that. Third, memory is split across two scopes. Project choices live in .tastemaker/style-lock.md and .tastemaker/decisions.log inside the repo; durable personal preferences live in ~/.tastemaker/profile.md. Fourth, the skill reads your spec first and works out which screens actually need design rather than dumping a whole design system. The README is explicit that contrast and readability are the verified part, real WCAG math, and that aesthetics are not. A palette that clears every ratio can still be ugly.

Installing tastemaker and running a first real use

The README points to the project homepage at https://tastemaker-skill.online for the live demo, and the repository keeps the skill under skills/ with plugin metadata in .claude-plugin/. The README describes installation as a one-time step you forget about afterwards, but the cleaned README does not spell out the exact command, so check the Quick start section on the site or in the repository before you copy anything. What the README does document is what appears once the skill is active: state files in the repo and a profile in your home directory. You can confirm the layout after your first UI request.

ls -a .tastemaker
cat .tastemaker/style-lock.md
cat ~/.tastemaker/profile.md

The first listing should show style-lock.md and decisions.log once a project has locked a style. The second prints the locked decisions for the current project, and the third prints the cross-project profile. If .tastemaker is absent, the skill did not engage on that request.

The contrast check is the part you can run yourself, independent of the agent. The README gives this invocation:

python check_contrast.py --matrix

What you should see is a per-pairing verdict: which combinations may carry text, which may carry a border, and which may carry neither. Since the README describes the palette as generated fresh per project, the matrix output will differ between projects. Treat a failing pairing as a build error, not a suggestion.

Where tastemaker will not help you

The README is unusually direct about one boundary: if you tell the model to lock its decisions as a design bible and use it as an anchor, you get the decisions written down in the current context, and for keeping three screens consistent inside one chat that genuinely works. You do not need this skill for that. The gap opens when the session ends, when you need a check that runs rather than a preference you can talk yourself out of, when you need pixel values rather than a description of an image, or when the model invents a badge fill and has to guess which colors may legally touch. There is a second limitation the README states itself: the verified part of tastemaker is contrast and readability, not aesthetics. A palette can pass every ratio and still look bad, so the script will not save a project whose visual direction is wrong. A third constraint follows from the architecture. Everything is local files and Python, so it only applies to agents that can load a skill; a team working in a plain chat window or a web UI with no filesystem access gets none of the persistence.

Tastemaker compared with just prompting the agent to write decisions down

The honest alternative is not another tool. It is the prompt the README anticipates: ask the model to lock its decisions as a design bible and treat that as the anchor. The difference is in what survives and what enforces. A bible lives in the context window, so closing the chat loses it or forces you to re-paste it. Tastemaker writes .tastemaker/style-lock.md and .tastemaker/decisions.log into the repo and promotes durable preferences into ~/.tastemaker/profile.md, so project decisions outlive the conversation and keep/reject patterns can carry into the next project. The second difference is kind rather than degree. A written preference is a judgment, and judgments erode. check_contrast.py --matrix is arithmetic and does not care how the palette felt. The third is that a written bible lists your colors but does not enumerate which of those colors may legally touch which, so the model still improvises when it needs a disabled state. The matrix answers that before the model gets there. If your work is one screen in one session, the prompt is cheaper and sufficient.

Maintenance, licence, and what the repository does not tell you

The last push to the repository was on 2026-09-10, and it is not archived. That is the only maintenance signal available here; the README does not publish a support policy, and no releases were retrieved, so there is no version history to read for upgrade guidance. The practical upgrade question is whether a newer skill version changes the shape of .tastemaker/style-lock.md or ~/.tastemaker/profile.md, because a schema change would affect files already committed or already sitting in your home directory. The CHANGELOG.md at the repository root is the place to check that before pulling. The licence is MIT, which permits commercial use and modification, but the repository includes a SECURITY.md and a CODE_OF_CONDUCT.md, and the README does not describe any security review of the Python scripts. If your environment restricts what a skill may execute, read skills/ and the scripts before installing rather than after.

Editorial conclusion

Adopt tastemaker if you already use Claude Code, Windsurf or Gemini CLI on UI work and want project style decisions to survive the chat session, with a contrast check that returns the same verdict every run. Skip it if your UI is mostly a component library you have already themed, or if you cannot install a skill into your agent. Before you rely on it, verify three things in the repository: that skills/ contains the entry point your agent expects, that check_contrast.py --matrix runs under your local Python, and that .tastemaker/ is added to your .gitignore if you do not want style decisions committed.

Frequently asked questions

Official sources

1. codeswithroh/tastemaker on GitHub
2. Issues
3. License: MIT
4. Project website
5. README