tastemaker

# 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.
4. **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.

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 three explicit verbs. Detect which one the request is before starting — most requests are the default.

| Mode | When | What it does |
|---|---|---|
| **build** *(default)* | The user asks to design, build, style, or improve UI. | The **Workflow** below (Steps 0-5). |
| **study** | The user pastes a screenshot or URL of a design they admire and wants to learn from it — "study this," "what makes this work," "match this vibe." | Extract the reusable **DNA** (macrostructure, archetypes, type pairing, color anchor) — never the pixels — into a diagnosis, then optionally build the user's own content with it or lock it into the style lock. Load `references/verbs/study.md` first. |
| **audit** | The user points at existing UI and wants a critique, not a change — "audit this," "why does this look AI-generated," "review this page." | Score it against the numbered gate list in `references/anti-slop-checklist.md`, return a ranked punch list by severity. **Does not edit.** Load `references/verbs/audit.md` first. |
| **comps** | The user wants reference comps only, not a built page — "give me some comps," "mock up a few hero options," a brand-kit board before committing to code. | Reuse the palette generator, macrostructure/component-catalog picks, and logo-sourcing rules to build a structured brief per comp, handed off to the user's own image generator (ChatGPT Images, Codex image mode, etc.) — tastemaker doesn't call an image API itself. Writes `.tastemaker/comps-brief.md` so a later build pass can pick up the same palette/structure decisions instead of re-deriving them. Load `references/verbs/comps.md` first. |

If a request doesn't clearly map to `study`, `audit`, or `comps`, 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`, "build it" after a `study`, or "now build this for real" after `comps`, hands off into the build Workflow.

## Aesthetic modes (optional add-ons, not part of the default skill)

Separate from the four workflow **Modes** above: an aesthetic mode is a named, opt-in style override — brutalist, minimalist, or similar — layered on top of the same shared engine (the palette generator, the structure/diversification system, the anti-slop gates), swapping specific dials (shape language, type character, motion feel, palette constraints) rather than replacing the workflow. None ship with the base skill; they're separate add-ons that, if present, live at `references/modes/<name>.md`.

**Check for one before Step 2's default mood path.** If `references/modes/` exists and contains a file matching what the user's asking for ("build this in brutalist mode," or similar), or the project's `.tastemaker/style-lock.md` already records an active mode from a previous build in this project, read that file first and apply it as the override layer Step 2 (palette) and Step 4 (build defaults) work within — instead of picking one of the five default moods below. A mode file states explicitly which of the base skill's rules it overrides and which stay in force (structure, asset sourcing, and the anti-slop gates it doesn't name are always unchanged) — follow that file's own scope, don't guess at what else might apply. Most projects have no `references/modes/` folder at all; when there isn't one, proceed straight to Step 2's default moods as normal.

## Workflow

### Step 0 — Load memory, don't start cold

Read `references/taste-memory.md` before writing or promoting any preference. Then check for `.tastemaker/style-lock.md` in the project root first.

- **Exists** → this project already has an established style. Read it and