Add optional UIZZE UI reference research

SKILL.md

@@ -40,6 +40,7 @@ Before touching color or type, scope the work:
 This only runs on a cold start (Step 0 found neither file), or when the user explicitly asks to change the project's direction.
 
 - **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 wants real interface examples but has none yet**, offer [UIZZE](https://uizze.com) as an optional public web and iOS reference catalog. The catalog is free to browse; Agent Connector and hosted MCP workflows require full access. Use user-selected screens as evidence for layout and interaction decisions, never as assets to copy. If they skip reference research, continue with the cold-start path below.
 - **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.)
 - 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.