name: tastemaker description: 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:

1. 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.
2. 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.
3. 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.

Read this file top to bottom before starting. It's short by design; the reference files below hold the deep material and are only worth opening when the step calls for them.

Modes

Tastemaker has one default behavior and two explicit verbs. Detect which one the request is before starting — most requests are the default.

If a request doesn't clearly map to study or audit, it's the default build. If the user pastes a reference image or URL with no verb, ask once whether to study it (extract reusable DNA) or treat it as a reference to ground a fresh build (Step 2's extract-palette path). A follow-up like "now fix it" after an audit, or "build it" after a study, hands off into the build Workflow.

Workflow

Step 0 — Load memory, don't start cold

Check for .tastemaker/style-lock.md in the project root first.

• Exists → this project already has an established style. Read it and reuse those exact tokens/assets for the new work. Do not re-derive a palette or type pairing from scratch — that's exactly the drift this file exists to prevent. Only revisit it if the user explicitly asks to change direction. Also read .tastemaker/log.json if present (the structural build log, see references/diversification.md) — it records the macrostructure and archetype picks of previous builds so this build can rotate to a different shape instead of repeating one.
• Doesn't exist → this is a fresh project. Also check ~/.tastemaker/profile.md (outside the repo, in the user's home directory) for a personal taste profile accumulated across their other projects. If it exists, treat it as a strong prior — propose starting from it rather than starting neutral. If neither file exists, this is a genuinely cold start; go to Step 1.

Step 1 — Figure out what you're actually building

Before touching color or type, scope the work:

• If a PRD, spec, issue, or design brief exists in the project, read it and extract the concrete list of screens/components that need UI (e.g. "onboarding: 3 steps," "empty state for no results," "pricing table," "settings page"). Design effort should map onto this list — don't generate a generic design system disconnected from what's actually being shipped.
• If no spec exists, ask the user directly (briefly) what screens are in scope, rather than guessing. A design system for the wrong surface area is wasted work.

Step 2 — Establish the style, grounded in something real

This only runs on a cold start (Step 0 found neither file), or when the user explicitly asks to change the project's direction.

• Check the target script first. If the PRD, the user's request, or the actual UI copy is in a non-Latin script (Korean, Japanese, Chinese, and others), the two-family Latin pairing model below does not apply — read references/style-tokens.md's Non-Latin script typography section before picking type. It's a different model (one family across a weight scale, not two families), not a font substitution inside the same one.
• If the user has references (pasted images, a Pinterest board export, screenshots, URLs to sites they like): run scripts/extract_palette.py against the image(s) to get deterministic dominant colors, contrast ratios, and lightness stats — real numbers pulled from real pixels, not a guess. Combine that with your own visual read of the reference (layout density, corner radii, shadow depth, whether it leans playful/serious/technical) to write a concrete style brief. Anchor every token to something visible in the reference — if you can't point to why a color or pattern is in the brief, don't include it. Once you've assigned extracted colors to Primary/Accent roles, run scripts/check_contrast.py --palette ... on the assignment — a color that looked fine as a dominant swatch in the source image can still fail as a button-label background once it's assigned that role (see references/style-tokens.md's Contrast floor section for a concrete example of this exact failure).
• If the user has no references, generate a fresh palette from the app idea rather than picking from a fixed set. Classify the idea's mood from the keyword table in references/style-tokens.md, then run scripts/generate_palette.py --mood <mood> (add --mode light|dark if the product implies one). This produces a new, legible-by-construction palette every run, so two similar projects don't come out identical, which is the whole point: no monoculture. Pair it with the mood's font set from that file's type-pairing catalog. Only ask a direct question when the idea genuinely spans two moods with no lean, per that file's "When to actually ask" section. State in one line which mood was inferred and why. Use references/component-patterns.md for layout pattern choice the same way (adapt, don't apply unchanged). (The five hex palettes in style-tokens.md are reference anchors showing each mood's intended character, not palettes to ship.)
• If the product needs an actual light/dark toggle (common for internal tools, less common for a marketing site) rather than one locked mode, that's a decision to make explicitly here, not default into. See references/style-tokens.md's Runtime dark/light toggle section: generate the companion pair from the same --seed in both --mode light and --mode dark, verify both with check_contrast.py --matrix, and record the toggle decision in the lock's Dark mode line per references/style-lock-format.md.
• Either way (generated, or extracted from references), the palette comes with its contrast matrix: generate_palette.py prints it, and for a reference-extracted palette you run scripts/check_contrast.py --matrix text=.. bg=.. surface=.. primary=.. accent=.. border=.. on-primary=.. yourself. Write the result — palette, type, and the legal-pairings summary from the matrix — to .tastemaker/style-lock.md's Color contract section (see references/style-lock-format.md for the exact structure). This is what makes the lock a contract over which colors may touch, not just a set of hexes that happened to pass once; every later step in this project reuses it instead of re-deriving.

Step 2.5 — Pick the structure, and diversify against project memory

Color is now locked and varies per project. But two sites with different palettes still read as the same template if they share the same page shape — the generic hero → 3-feature-cards → testimonial → CTA → footer rhythm is the strongest "an AI built this" tell at the page level, and it survives a perfect palette. This step makes structure vary the way color already does. Skip it for App shell screens (dashboards/internal tools) — their shape is governed by references/component-patterns.md's App shell section; this step is for public/marketing pages, where structural sameness bites hardest.

1. Check project memory first. Read .tastemaker/log.json (created by previous builds; see references/diversification.md) alongside the style lock. It records the last builds' macrostructure and archetype picks.
2. Pick a macrostructure by name from references/macrostructures.md — the whole-page skeleton — matched to the brief's actual argument, and different from the last build's per the rotation rule.
3. Pick the component archetypes that fill it from references/component-catalog.md — nav, hero, feature, proof, CTA, footer, section-head — each with its variation knobs. Nav, footer, and hero must each differ from the last build's; if you reuse an archetype, change a knob.
4. State the rotation out loud in one line before building (the accountability step — picking on the page is what breaks the default-attractor): which macrostructure and archetypes you picked, and how they differ from the last build. See references/diversification.md for the exact format.
5. This is what the CSS stamp and the .tastemaker/log.json entry (both written at Step 4) record. Within a single project, keep pages coherent (shared nav/footer/type frame); across projects, structure varies.

The picks feed Step 3 (which assets each archetype needs) and Step 4 (the build itself).

Step 3 — Real assets, all of them, in the same pass — and attribution-free by design

A site with no real photography, no illustrations, and no motion reads as static and generic no matter how good the color/type tokens are — this step is what makes a generated site feel dynamic and alive. The goal is a complete site in a single pass: every section that needs a photo has a real photo, every concept has an illustration, every icon is in place, and it all animates — the first time, with no follow-up round of "now add the images." Every source below is chosen to make that possible: API-first (fetchable automatically, no human browsing step) and attribution-free (nothing the end user ever has to see). This is deliberate — an attribution credit sitting on a finished marketing site is a visual hindrance no real product ships, so this skill sources only from places that don't require one.

For every asset the scoped screens need:

• Decide illustration vs. real photography per section. Sections showing something factual or physical (office, product-in-use, people, places) call for real photography; sections conveying an abstract concept (mission, values, an idea, a feature benefit) call for illustration. Both get filled in this same pass — neither is optional.

• Real photography → Openverse, via scripts/fetch_photos.py, automatically and with no API key. Run scripts/fetch_photos.py "<search terms>" --out design/assets/photos for every photo-appropriate section — no key, no signup, nothing to set up. It searches Openverse (800M+ openly-licensed images), filtered by default to CC0 + Public-Domain-Mark, which legally require zero attribution — nothing on the site, ever. This is what makes photos and icons zero-setup: keyless in every session, no accounts, no keys. (Illustrations are the one asset type that may need a single one-time setup step — populating ~/.ideagram/undraw/ — see the Illustrations bullet below; once that's done once, it's reused across every future project.) (Optional upgrade: --source pixabay uses Pixabay for more stock-polished, full-res imagery if a section needs it — also attribution-free, but needs a free PIXABAY_API_KEY. Use it only when Openverse's more eclectic pool doesn't have a clean match. Unsplash is deliberately not used at all, because its API forces visible on-site attribution.)

• Credit the sources in the code, never on the page. fetch_photos.py writes a CREDITS comment block (creator + source + license per photo) into the photos folder. This is a voluntary courtesy — CC0/PDM require nothing — so paste it into a code comment at the top of your HTML/CSS as a genuine thank-you to the people whose work you're using. It's visible to any developer reading the source and invisible to the end user. That's the honest middle ground: generous credit, zero visual hindrance. Never promote it to visible on-page text.

• Logo → preserve first; construct only on a real cold start. See references/logo-sourcing.md. Before designing a mark, search the repository and brief for an existing logo, favicon, brand kit, or distribution asset. If one exists, treat it as locked: reuse it byte-for-byte unless the user explicitly requests a rebrand. Do not recolor, reinterpret, or replace an established mark merely because it clashes with the new page direction. Only when no identity exists should you construct a simple geometric mark from primitive shapes in the locked palette (following ideagram/references/style-contract.md) — not a letter dropped in a colored box. Once the mark is established, run scripts/export_favicons.py <mark>.svg --out design/assets/favicons/ and wire the favicon set into <head>.

• Illustrations → the vendored ideagram/ skill, always available, no cross-skill dependency. ideagram/ is bundled directly inside this skill (see ideagram/SKILL.md) specifically so illustration sourcing never depends on whether a separate ideagram skill happens to be installed in the current session — it's part of tastemaker now, not an optional sibling. Two things trigger this step, and both use the exact same workflow:

  1. Implicit — Step 3's own illustration-vs-photography split above identifies a concept-driven section (mission, values, an abstract feature benefit) that calls for illustration rather than a photo.
  2. Explicit — the user's own request uses the word "illustration" (or "illustrate") anywhere, for anything — a whole site, one section, or an ad-hoc "add an illustration of X here." Treat that word as a direct instruction to run this workflow for that concept immediately, not just a hint to weigh against other options.

  The workflow itself (full detail in ideagram/SKILL.md, read it before the first use in a project): distill the concept to one sentence, match it against a local unDraw library at ~/.ideagram/undraw/ (real illustrator-grade SVGs, not hand-drawn-by-LLM path data), recolor the match to this project's locked accent with ideagram/scripts/recolor_undraw.py, validate with ideagram/scripts/validate_assets.py. If ~/.ideagram/undraw/ doesn't exist yet or has no index, say so plainly and either ask the user to grab 20-30 free illustrations from undraw.co (30 seconds, no attribution needed) or fall back to ideagram/assets/primitives composition — and be upfront that the fallback is a real quality drop from real unDraw art, per ideagram's own honesty rule. Don't silently accept the downgrade as if it were the intended result.

  • The illustration isn't done until it's in the page. Save the finished SVG to design/assets/illustrations/, then actually reference that file path in the section's markup (<img src="design/assets/illustrations/<name>.svg" alt="..."> or inlined <svg>) as part of the same pass — generating an on-brand illustration and leaving it unused on disk isn't a completed step.
  • Record what happened in .tastemaker/style-lock.md's Assets section (illustration vs. photography split line) — including whether the library was populated or the primitive fallback was used, so a later session in this project doesn't have to rediscover that state.

• Icons → Iconify, via scripts/fetch_icons.py, automatically, matched to the mood. Iconify's public API needs no key, returns SVGs already tinted to the accent color, and draws from permissively-licensed open sets (Lucide, Tabler, Phosphor, Heroicons, Material Symbols, Iconoir, Solar, Carbon, MingCute, Fluent) that require no attribution. Pick one set per project and stay in it so every icon shares one stroke weight — but which set is the point that used to get skipped: pass --mood <the project's locked mood> so the set varies with the project, and each mood maps to two candidate sets rather than one, picked between per run the same way generate_palette.py --seed varies the palette (the mapping lives in the script's docstring) — so two "technical" projects aren't guaranteed the same Lucide icons any more than two "premium" ones are guaranteed the same palette. scripts/fetch_icons.py --search "<terms>" --mood <mood> to discover names, then --icons name1 name2 --mood <mood> --color "#<accent>" --out design/assets/icons to fetch. Name --set directly only when neither of the mood's candidates fits this project. Don't fall back to emoji-as-icons or hand-drawn one-offs when a two-line fetch gets a consistent, real icon set.

• When even a populated unDraw library has no real fit for a concept (per ideagram/SKILL.md Step 2's "don't force a bad match" rule), or an image-gen tool happens to be available for a bespoke style: references/illustration-sources.md covers the remaining options, including Streamline as a manual, attribution-aware exception. This is now the rarer path — ideagram's unDraw-match workflow (once the library is populated) is the norm, not Openverse/Iconify-style full automation, because the win here is real illustrator-grade art, not a zero-touch fetch.

• Last-resort fallback, never the plan: if a specific asset genuinely can't be sourced (no network, no populated unDraw library and the user can't add one), build it code-native — SVG shapes / CSS gradients from the locked palette — rather than leaving a gap or a grey box. Say plainly when this happened; don't imply a real photo/illustration exists where a placeholder does. Note this should be rare for photos and icons specifically, since both fetch without any key — the illustration path is the one place a one-time manual step (populating ~/.ideagram/undraw/) may genuinely still be needed.

• Save everything into design/assets/ (photos, illustrations, icons in their own subfolders) so it's reusable across screens, and run scripts/validate_assets.py over any SVGs before use — a malformed SVG (classically a -- inside a <!-- --> comment) reads fine as text but renders as a broken image in strict browsers, invisible unless actually parsed.

• Motion → GSAP + ScrollTrigger, in the same pass, not a later polish step. Wire up assets/gsap-starter.js for scroll-driven reveals and staggered entrances, and for anything with a narrative/storytelling shape (a landing page that unfolds section by section) build a GSAP scroll timeline per references/animation-guidelines.md — pinned sections, scrubbed reveals, sequenced hero moments. This is what turns a stack of static sections into a site that tells a story as you scroll, and it's default, not optional. The dependency-free reveal.css/reveal.js pair remains only as a fallback for contexts that can't take a GSAP dependency.

Step 4 — Build the actual screens

Now generate the PRD-scoped screens/components, constrained to .tastemaker/style-lock.md and the asset files from Step 3. Point explicitly at file paths and token values rather than re-describing the vibe in prose each time — concrete constraints produce consistent output; restated vibes drift.

Six defaults are non-negotiable at build time — they are the difference between "a styled document" and "a designed product," and generated sites reliably skip them unless forced:

1. Show, don't tell — visual representation over text, always. This is the single biggest thing that separates a real product site from an AI-generated one, and the easiest to get wrong because writing another paragraph is the path of least resistance. The default failure mode is a wall of feature cards, each with a heading and two sentences of prose explaining a benefit. Real product design shows the benefit instead: a product-UI mockup, a before/after comparison, an actual chart, a diagram, a numbered visual flow, a stat with one label, an annotated screenshot. Before writing a paragraph to explain something, ask whether a visual could carry it with a caption instead — and default to the visual. Concretely: a "fast analytics" claim becomes a real chart, not a sentence about speed; a "3-step onboarding" becomes three visual panels, not a bulleted list; a feature becomes a small UI mockup of that feature, not a description of it. Text earns its place only where a visual genuinely can't carry the meaning (a headline, a short subhead, a caption, a CTA label). Every section should be mostly something to look at, with text as the caption — not mostly text with a decorative icon. See references/component-patterns.md for the show-don't-tell pattern per section type. This is a hard default, verified in the anti-slop checklist, not a stylistic preference.
2. The hero has one job and one visual focus. For every default app or site with a public-facing hero, read and apply references/hero-guidelines.md before building above the fold. Start from one sharp promise, one short explanation, one primary action (plus at most one secondary action), and one product-relevant visual. Do not turn the hero into a miniature dashboard of the site's features: workflow rails, metric sidebars, floating badges, proof stamps, orbit decorations, file/status footers, and extra microcopy compete with the value proposition. Push explanation and process below the fold. Complexity is allowed inside the product; it is not automatically allowed in the product's first impression.
3. Motion is wired in this pass, not deferred — the track depends on the screen, not the project. Every screen ships with GSAP by default; this is a build-step requirement, not just an asset-sourcing note from Step 3. A finished page with zero motion is a skipped step, not a minimalist choice. But which motion depends on what the screen actually is, per references/animation-guidelines.md:
   • Marketing/landing screens (a page the user scrolls through once): wire assets/gsap-starter.js for baseline reveals and build a real sequenced hero timeline plus at least one scroll-storytelling beat (scrubbed reveal, pinned section, parallax).
   • App shell screens (dashboards, settings, anything behind a persistent sidebar/topbar the user works inside rather than scrolls through): a scroll-driven hero timeline has nothing to attach to and is the wrong tool. Use the App shell motion track instead: panel/tab-switch transitions, staggered list/table entrances on data-load, animated state changes, and skeleton loading states.
   • A single project can have both kinds of screen (a public landing page in front of an authenticated app); give each screen the track that fits it, don't apply one default everywhere. Don't hand back a static screen and call motion a follow-up, and don't force a hero-timeline treatment onto a dashboard just because that's the default for the other track.
4. No section is asset-empty. Per Step 3, every section that calls for a photo/illustration/icon/mockup actually has one — no flat color blocks or bare text where a visual belongs. In a clean hero, this means one meaningful visual rather than several decorative ones.
5. Every color pairing the build introduces is a legal one. Step 2 locked a contract, not just five hexes — the Color contract section of .tastemaker/style-lock.md says which pairings are text-safe (>=4.5:1) and which are UI-safe (>=3.0:1). When a screen needs a pairing not already in that list (a badge fill with a label, a disabled state, a hover, a state-carrying border), that is a flag, not a free choice: pick a pairing that's already legal for the purpose, or run scripts/check_contrast.py --matrix again with the new token added and update the lock before shipping it. Don't invent a pairing and assume it's fine because the palette passed once — early hand-picked drafts for two moods in references/style-tokens.md failed exactly this way, caught only by actually running the numbers, which is why color generates against this contract now (scripts/generate_palette.py) instead of being hand-tuned and hoped.
   • When a pairing fails, work through this order — don't loop on the same failing value hoping a re-run changes the math:
     1. Reuse a pairing already legal for the purpose. The fastest fix is almost always already in the lock's text-safe/UI-safe lists — check there before inventing a new value.
     2. Nudge the new color's lightness within its own hue family, not the hue itself (shifting lightness preserves the palette's character; shifting hue doesn't), re-run check_contrast.py --matrix on the result, and only accept it once the matrix confirms the pairing actually clears its floor — this is the same lightness-solving approach scripts/generate_palette.py already uses at generation time, applied ad hoc to a single new token.
     3. If nudging would visibly break the color's intended role (a brand-fixed accent that can't move, a hue chosen deliberately for the mood), fall back to a known-safe neutral already in the palette (text or on-primary) for that specific pairing instead of forcing the original color to work.
     4. If none of those apply (a hard external constraint, like a client's fixed brand hex that genuinely can't satisfy the floor for its intended use), stop and surface the conflict to the user rather than shipping the failing pairing or silently substituting something they didn't ask for.
6. Spacing follows the scale, not habit. Per references/style-tokens.md's Spacing scale section: pick the project's tokens once, record them in .tastemaker/style-lock.md's Density & spacing section, and reuse them — don't let each card or section improvise its own padding. The rule that actually governs the result: internal spacing (a card's own padding) should be equal to or less than external spacing (the gap between that card and its neighbors) — violating this is what makes a layout read as cramped in one place and empty in another at the same time, a real failure mode this rule was written to catch. Content cards (pricing tiers, feature cards, testimonials) have a real floor: space-6 (24px) minimum internal padding, not whatever a compact stat tile uses. Don't reach for the same padding value everywhere regardless of what the element is.

Stamp the build and record it in project memory. The first non-empty line of the built CSS (or the top of an inline <style>) is a comment recording the structural picks, mood, palette seed, and contrast result — the format is in references/diversification.md. In the same pass, append an entry to .tastemaker/log.json (create it if absent) with the macrostructure and archetype picks. This is the durable record the next build reads to rotate against — skipping it is how the skill drifts back into building the same shape every time.

references/anti-slop-checklist.md carries two checks that bracket the build. Before you finalize, run its pre-emit self-critique: score the planned output 1-5 on six axes (show-don't-tell, philosophy, hierarchy, specificity, restraint, variety) and revise anything scoring below 3 — catching weakness there is cheaper than catching it in the gate sweep. After you build, run its numbered gate list (mood-scoped: some gates loosen or tighten per the project's mood) — it catches the specific tells (generic gradient defaults, emoji-as-icons, contrast checked on only one pairing, text-walls where visuals belong, static/no-motion pages, transition: all and other motion tells, mid-render token improvisation, the generic hero→3-cards→CTA→footer template, invented metrics) that make output read as AI-generated regardless of how good the underlying tokens were. Record the six critique scores in the build stamp.

Step 5 — Close the loop: curate fast, remember what was learned

Taste lives in what gets kept vs. rejected, not in the first draft. What this looks like depends on whether you can actually get a response back:

• Interactive session (the normal case): ask a quick, specific keep/reject question rather than an open-ended "thoughts?" — e.g. "keep this hero treatment, or try a variant?" — and log the real answer to .tastemaker/decisions.log.
• Autonomous/single-pass run (no one available to answer, e.g. a background task): don't fabricate an approval that never happened. Log the decision entry as status: pending-review with what was shown and why you chose it, so a later session (or the human, whenever they do look) has the reasoning available and can convert it to a real kept/rejected verdict then. A pending entry is honest; an invented "user approved this" is not.
• Periodically (e.g. every handful of resolved decisions, or when the user says a project is done) summarize durable patterns from resolved log entries up into ~/.tastemaker/profile.md — the kind of preference that would matter on a different project too (e.g. "prefers muted/desaturated palettes over saturated ones," "consistently rejects skeuomorphic shadows"), not project-specific detail that belongs only in that project's lock file. Don't promote pending/unresolved entries into the global profile — only real revealed preference should shape future cold starts.

This is what makes the second project faster than the first, and the tenth faster than the second — the tool is meant to get more accurate for a given developer the more they use it, not stay static.

Reference files

Scripts

Assets

A note on honesty

Don't claim a step happened if it didn't. If there was no image-generation tool available and you fell back to curated icons + code-native visuals, say so plainly rather than implying custom illustrations were generated. If no references were given and the style came from the starter scaffolding, say that too. The whole point of this skill is to close the gap between "looks AI-generated" and "looks intentional" — silently overclaiming what happened undermines the exact trust it's trying to build.

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.

See the difference, not just the claim

One prompt, build a landing page for a coffee subscription, built twice: once with no skill, once with tastemaker installed. Same request, unchanged, both times.

Left is the indigo-gradient, letter-in-a-box-logo, emoji-icon default most agents reach for. Right is the same prompt with tastemaker: a palette generated fresh for the project's mood, real fetched icons, a constructed mark, and motion, in one pass. Both are real, live pages, not mockups or screenshots.

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 hero. This is not a prompting problem. It happens because 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 fixes this with four ideas, not a bigger catalog of canned options to pick from:

1. Generate within a check that actually runs. There is no fixed list of color combinations shipped with this skill, and the palette is not five approved colors the model may combine however it likes either. A new one is generated per project (a fresh hue and harmony each time) against a contract: check_contrast.py --matrix computes every pairing and says which may carry text, which may carry a border, and which may carry neither. So the constraint produces variety instead of sameness, and a rule that runs is different in kind from a rule you wrote down, because it returns the same answer no matter how confident anyone felt.
2. Ground in real pixels, not words. Give it a screenshot or a reference and it reads the real colors and contrast from the actual image, using a script. It does not write a vague summary of the vibe and rebuild from that. Text summaries lose most of what made the reference feel specific.
3. Remember, do not re-derive. Once a project locks a style, every later screen reuses it. Nothing drifts. Across projects, a small profile file learns what you keep and what you reject, so your next project starts warm.
4. Scope to the real work. It reads your spec first and figures out which screens actually need design, instead of dumping a design system that has nothing to do with what you are shipping.

"Can I not just tell the AI to write the decisions down?"

Yes, partly, and it is worth being straight about where the line is.

If you say "lock these decisions as a design bible and use it as our anchor," you get the decisions written down in the current context. For keeping three screens consistent inside one chat, that genuinely works, and you do not need this skill for it.

Here is what that does not give you:

• It does not survive the session. The bible lives in context. Close the chat and it is gone, or you re-paste it and hope. Tastemaker writes .tastemaker/style-lock.md to your repo and ~/.tastemaker/profile.md to your home directory, so the decision outlives the conversation and carries into the next project.
• It has no check that runs. A written-down preference is still a judgment you can talk yourself out of. check_contrast.py --matrix is a computation. It does not care how good the palette looked to you, and it returns the same verdict every time. That is the difference between an intention and a constraint.
• It cannot read pixels. "Match this reference" through a conversation becomes a text description of an image, then a rebuild from the description. extract_palette.py reads the actual pixel values.
• It leaves the combinations to improvisation. A written bible lists your colors. It does not enumerate which of those colors may legally touch which, so the model still guesses when it invents a badge fill or a disabled state. The matrix answers that up front.

Short version: a conversation gives you the decision. This gives you the decision plus something that enforces it after you have stopped paying attention.

What is verified, and what is judgment

Worth separating these two clearly, because it is easy to let one stand in for the other, and this project has been guilty of that.

Verified (a computation, not taste). Contrast and readability. check_contrast.py runs real WCAG math over the palette and reports pass or fail. This is accessibility, not aesthetics. A palette that clears every ratio can still be ugly. The reason it belongs here anyway is that it catches a class of failure your eyes genuinely cannot: contrast is a calculation, and looking at a color confidently is not running it. Early hand-picked palette drafts for two moods failed that check on the first pass, and only the script caught it. That failure is the reason color is generated against the contract now instead of hand-tuned and hoped.

Judgment (heuristics and memory, not proof). Everything that is actually taste: the reference extraction, the mood-to-palette matching, the accumulated profile, and the anti-slop checklist. These are informed defaults and accumulated preference. They are not verified, and this README should not imply they are. They get better with your references and your rejections, not with more math.

Do not read the contrast script as evidence that the design is good. Read it as evidence that the design is legible, which is a smaller and more checkable claim.

Quick start

Install it into your Claude Code skills folder:

git clone https://github.com/codeswithroh/tastemaker ~/.claude/skills/tastemaker

Restart Claude Code, then just ask:

build a landing page for a coffee subscription

Tastemaker triggers on its own. It generates a palette, picks a matching type pairing, sources real assets, wires up motion, and builds. You do not invoke anything.

Using Cursor or Windsurf? Drop the same folder into their skills directory.

For the deterministic color extraction script you need Python 3 and Pillow (pip install Pillow). If Pillow is missing, it falls back to a vision based read instead of failing.

What you get

The palette generator

When you have no reference, tastemaker does not hand you a color picker, and it does not hand you a fixed color scheme to choose from either. It generates one, on the spot, for your project. A menu of