Brand API

View saved version →

---
name: brand-adherence
description: Ship a new page for a brand that already exists, as if that brand's own team shipped it. Use when the request names one reference site and asks for a page inside its identity — a pricing page for X, a careers page in Y's system, "as if their design team built it". Not for inventing something new. Needs a shell and a writable working directory alongside the Brand API MCP.
---

# Brand Adherence

You are the brand's own design engineer. You receive one reference brand and a page to build, and you ship that page as if the brand's own team shipped it. Your success is measured one way: **a reviewer who knows the brand must not find a single token, component, or rule you altered.** Composition, hierarchy, and copy are your latitude. Everything else belongs to the brand.

**Requirements.** The Brand API MCP, a shell to download the captured files, a working directory to save them in, and a way to put your finished page at a URL the engine can reach. The MCP carries both halves of this skill: `extract_brand`, `poll_brand_extraction`, and `get_brand_extraction_result` acquire the reference brand, and `verify_brand_adherence`, `poll_brand_adherence`, and `get_brand_adherence_result` grade the page you ship against it.

## The one failure this skill exists to prevent

A full extraction runs to about a hundred kilobytes. Ask for it in one call and it overruns your tool-output cap: you get a preview plus a path into your runtime's own storage, which no tool you hold can open. You then design from the fraction you saw. The page looks plausible, and a reviewer sees the two defects at once: the brand's typefaces are named but never loaded, so every heading renders in the fallback face, and its real logo and imagery are missing. Everything below exists to stop that.

## 1. Pull the extraction in sections, and save each one as it lands

Acquire the brand first. `extract_brand(url)` returns a `submission_id`; pass it as `brand_submission_id` to `poll_brand_extraction`, polled until `status: "completed"`, then to `get_brand_extraction_result`. Markup written before you hold the brand is a guess you will throw away.

You can use a publicly facing URL directly. However, if you are running the server locally on `localhost` you need to make your server accessible over Taste Labs SSH tunnel. This is a tunnel where only Taste Labs
is able to access your page. To run the tunnel, follow the steps:

```
SERVER_PORT=3000
CRAWL_ID=crawl-$(uuidgen)
# Print the URL that we can submit.
echo "Crawl URL: http://$CRAWL_ID"
# Open the SSH tunnel.
ssh -p 2222 -o ExitOnForwardFailure=yes -R $CRAWL_ID:80:localhost:$SERVER_PORT tunnel.tasting.dev deadline=3600s
```

The steps assume your server is running on port 3000 on localhost. Adjust accordingly and use the printed URL for `extract_brand(url)`. The tunnel closes when `ssh` exits or the deadline passes, and a submission against a closed tunnel fails with `Page not reachable`. One extraction or verification takes three to five minutes, so keep `ssh` running across iterations and re-run the command if it expires. For static files without a server consider using the Python built-in server:

```
python3 -m http.server 3000 --bind 127.0.0.1
```

**Never ask for the whole document at once.** Pass `sections` and take two or three at a time. The engine runs the extraction once and caches it, so the later pulls are cheap:

```
get_brand_extraction_result(brand_submission_id, sections=["profile", "colors"])
get_brand_extraction_result(brand_submission_id, sections=["typography", "assets"])
get_brand_extraction_result(brand_submission_id, sections=["actions", "surfaces", "elevation"])
get_brand_extraction_result(brand_submission_id, sections=["layout", "structure", "navigation"])
get_brand_extraction_result(brand_submission_id, sections=["interactions", "icons"])
get_brand_extraction_result(brand_submission_id, sections=["data_display", "sections"])
```

The fourteen legal names are `profile`, `layout`, `colors`, `typography`, `surfaces`, `elevation`, `interactions`, `actions`, `navigation`, `data_display`, `structure`, `icons`, `assets`, and `sections`.

**Save each answer into your working directory as it arrives** — one file per pull, under a directory of your own, for example `brand/typography-assets.json`. Then read the exact values back out of those files at the moment you write CSS, with whatever file-viewing tool you hold. This is why you pull two or three sections at a time and not fourteen: each file stays small enough that one read returns it whole.

Never transcribe a value from memory or from scrollback. An atom is only verbatim if you copied it out of a file. Zero transcription error is the whole point: exact hex, exact type specs, exact CSS.

A section you never pulled is a section you did not use.

## 2. The artifacts are half the extraction

Every `get_brand_extraction_result` answer carries an `artifacts` object beside `design_system`, and it survives a narrowed pull, so you hold it from the first call:

| artifact | why you cannot skip it |
|---|---|
| `css` | the captured stylesheet. The real `@font-face` rules and the **hosted font file URLs**. `typography` names a typeface; only this loads it. |
| `html` | the captured page. The brand's inline-SVG logo, verbatim, and the markup as the site ships it. |
| `full_page_screenshot` / `screenshot` | what the brand actually looks like. The only honest check on density, contrast, and the light/dark balance. |

Download all three into your working directory before you design anything:

```bash
curl -fsSL "<artifacts.css.url>"  -o brand/captured.css
curl -fsSL "<artifacts.html.url>" -o brand/captured.html
curl -fsSL "<artifacts.full_page_screenshot.url, or artifacts.screenshot.url when it is null>" -o brand/reference.png
```

### Start with the fonts

A `@font-face` block spans several lines, so a line-based `grep` will not catch one. Read every `@font-face` rule out of `brand/captured.css`, whole, with whatever tool you hold: a multiline search, an inline script, or your own eyes on the file. Drop only fonts identified as icon fonts by family and usage; a `base64` `src:` can also embed a brand typeface.

Paste those rules into your `<style>` verbatim, keeping the absolute `src:` URLs. **Naming a font without loading it is a failure.** It renders as the fallback, and a page in the fallback face stops looking like the brand no matter how exact the hex values are. If a family has no `@font-face` anywhere, load it from Google Fonts when it exists there, otherwise fall back to a generic family and say so in your final message. Never substitute a different named font, and never swap a family for a similarly-named one.

**A licensed face belongs to the brand, not to your page.** The license covers the brand's domains, so your page is unlicensed whether the file comes from their host or from yours. **Ask the user for the font.** Name the family and the weights you need, and ask for the licensed files or for the vendor kit. Keep building the rest of the page while you wait.

### Then the logo

The extraction already carries it. `assets.logos[]` gives you `svg_code`, the inline SVG the engine lifted out of the markup, plus `url`, a mirrored copy on the engine's storage, and `role`, `format`, and `description` to tell the wordmark from the mark. `icons[]` carries the same `svg_code` for each icon example. Take the logo from there and never redraw one.

Fall back to the captured page only when `svg_code` is `null` and the `url` does not fetch: find the `<svg>` elements in `brand/captured.html`, where the nav's mark is usually the first candidate inside an `<a href="/">` and the small ones with one path are icons.

### Then look at the screenshot

Open the downloaded picture before you compose, and again before you finish. Density, contrast, and the light/dark balance live there and none of them survive as numbers. If a token and the screenshot disagree, the screenshot wins.

## 3. Cover every section

Every section that is present earns a place in the output.

- **profile**: `brand_name`, `industry`, `copy_tone`, `brand_signature`, `visual_language`. This is your brief for voice and intent, not just pixels.
- **colors**: `baseline[]` and `secondary[]`, each with `hex`, `alpha`, `type`, `rules.when_to_use`, nested `shades[]`. Use exact hex and honor `when_to_use` so each color lands in the role the brand gives it.
- **typography**: `titles`/`paragraphs`/`labels`/`others`, each variant with `role`, `specs`, and `technical.font_family_css`. Prefer the raw `clamp(...)` over a px snapshot.
- **layout**: `grid`, `breakpoints`, `section_separation`, `insights`.
- **actions**: `button_list[]` with per-state `visuals`, `button_group`, `links.text_decoration`.
- **surfaces**: `gradients[]` carry ready-to-use `css_code`. Paste it.
- **elevation**: `shadows.levels[]` `css_value` and `borders[]`.
- **interactions**: `global_patterns` and `animations[]` with `css`.
- **navigation**, **structure**, **data_display**, **icons**: present only when detected. Honor them when they are; skip rather than invent when not.
- **assets**: `logos[]` with `svg_code` and `url`, and `media[]`. Paste the SVG or point at the real URL; never redraw.
- **sections**: the reference's own ordered blueprint. Read it to learn the brand's section vocabulary, then **compose your own order** — you are building a different page.

## 4. Compose

Apply the decisions in order: layout scaffold, components, color and typography page-wide, surfaces, motion, then copy in the brand's voice.

**Hard rules.**

1. Begin your `<style>` with the extraction's color tokens verbatim, and reference every color through a variable. A tint the extraction does not define is allowed only as an `rgba()` or `color-mix()` derivation of a token. Zero invented hex values.
2. Load only the brand's typefaces, at the weights it lists, through the `@font-face` rules you recovered. A fallback stack holds only generic or system families.
3. Build every button, nav, toggle, card, accordion, divider, and table from the extraction's component CSS, copied verbatim. Rename a class freely; never change a value.
4. Use the brand's real assets: the logo, the imagery, the favicon. Imagery the extraction marks as compositional gets full presence, not a thumbnail.
5. Match the screenshot for density, contrast, and mood. Do not copy its layout.
6. Compose the requested page freely inside the brand's grid, spacing rhythm, and section system. Layout means arrangement. It never licenses restyling.

If a section drifts toward tasteful-but-generic, the fault is a decision built from an adjective instead of a value. Go back to the saved files.

## 5. Verify against the render, not the markup

When you can serve the page and look at it, do that at **1440** and at **390**. Half of these checks live only in the picture. When you cannot, go straight to step 6 and let the verifier carry them.

Write each finding down before you fix it, then fix from the written finding. A defect fixed silently teaches the next run nothing. Re-render after every correction: a fix you never looked at is a claim, not a verification.

## 6. Verify with the brand-adherence verifier

Your own eyes carry your own blind spots: you graded work you also made. The engine ships a verifier that extracts the reference and your page the same way and judges the pair, so once the render check passes, get the outside verdict.

**The page must be reachable by the engine.** The verifier takes two URLs and extracts both itself — no raw HTML, no file upload — so a page served on loopback is invisible to it. Use the page's deployed or preview URL, or the Taste Labs SSH tunnel from the steps above, kept open while you iterate. If the run has no way to put the page on a reachable URL, skip this step and say so in your closing message; never substitute your own impression for the verdict and present it as one.

```
verify_brand_adherence(reference_url=<the brand site>, candidate_url=<your page>)
   → job_id                     # extraction of either side is reused when recent
poll_brand_adherence(adherence_job_id=<job_id>)    # accepted → extracting → judging → completed
get_brand_adherence_result(adherence_job_id=<job_id>)
```

The verdict carries three things:

- **`score`** — one number from 0 to 1, a blend of the LLM judge and the deterministic checks.
- **`fixes`** — the deterministic verifier's fix objects, worst-first, capped at 20. Each carries an `action` discriminator (`snap_to_token`, `add_color_token`, `self_host_licensed_font`, …) plus the exact target values for that action.
- **`recommendations`** — the judge's recommendation strings, worst-first, with exact target values, capped at 20.

**Work the verdict in that order.** The fixes are mechanical: each one names the exact value to change, so apply them the way you applied the extraction — copy the target value from the fix object, never retype it from memory. Then read the recommendations top-down and apply the ones that do not fight a hard rule; a recommendation that would have you invent a token loses to rule 1. Log anything you decline, with the reason, for the closing message.

**The loop runs twice, then it belongs to the user.** Verify, apply the verdict, re-render, and **verify once more** — extraction reuse makes the second run cheap. Do not act on that second verdict. Close with both scores side by side, the fixes and the recommendations the second verdict still names, and whatever you declined and why. The user reads that list and decides whether a third round is worth the credits. A round you start on your own spends them on your blind spot instead of on the page.

## Final self-check

Run this against the file on disk, and against your last render when you have one. Fix what fails, then write the corrections back.

- Every color literal traces to an extraction token, or is an `rgba()` / `color-mix()` derivation of one.
- The body background is the brand's dominant surface, and the light or dark balance matches the screenshot.
- Every brand typeface is **loaded** from a real `@font-face`, not merely named. Only the brand's families and weights appear anywhere.
- Every component is built from the extraction's component CSS. No invented component, radius, or shadow.
- The real logo is on the page, compositional imagery is at full presence, and every asset reference points at a real brand asset.
- Every section present in the extraction was pulled, saved, and used.
- The page holds its structure at 390 and at 1440, confirmed in a render or in the verifier's verdict rather than assumed, and it holds when a remote font or script fails to load.
- Nothing overflows, nothing is truncated that had room, and nothing overlaps what a reader was meant to read.

Close with a plain message naming the brand decisions you made, how you obtained the extraction, the verifier's score before and after your corrections (or why the verifier could not run), the fixes and recommendations the second verdict still names, any you declined and why, and anything you could not verify.

View saved version →

---
name: brand-search
description: Use when the user needs website design references — whether they describe a style or mood, name reference sites, want brands visually similar to an existing site, or ask for a website without an established visual direction (e.g. "build a website for my bakery"). Finds real websites from a curated library to inform design decisions before building.
---

# Brand Search

## 1. Pick the right search tool

Both tools return the same thing: website references, each with summary brand metadata and a screenshot. They differ in what goes in.

`search_brands`: a natural-language query goes in. What the user or the agent asked for becomes the query. Ex: `search_brands("dark brutalist developer tools")`, `search_brands("warm pastel skincare landing pages")`.
`search_similar_brands`: the `submission_id` of a completed extraction goes in, and that site's nearest visual neighbours come out. Ex: you extracted linear.app, got back its `submission_id`, and pass that id in.

### `search_brands`

Build each query knowing what you're looking for — style, layout, palette, motion, tone — and write it by the guidelines below.

- Always follow the original intent of the user's or agent's prompt. Don't add anything they didn't ask for, and don't translate what they did. If the prompt says "monochromatic", the query is monochromatic, not "black and white".
- Inspect every returned result as described in step 3 before selecting references.

A prompt that's just a vibe gets a query that's just the vibe: `search_brands("dreamy editorial skincare, calm and warm", top_k=6)`.

When the user names a style or movement, carry the word exactly as they wrote it. The search is what interprets style terms, including ones nothing is formally tagged with — swapping in your own synonym would decide what the search was supposed to decide. `search_brands("vintage feeling clothing brand site")` keeps "vintage" even though the corpus's official tag for that register is "Retro": the user said vintage, so vintage is what gets searched. Same discipline behind `search_brands("y2k web aesthetic for a music label")` and `search_brands("swiss international style studio portfolio")`.

When a color or tone seeds the prompt, recruit by color role rather than hue: the useful cluster is sites where the tone plays the same structural part — ground, ink, or accent — never hue neighbours where it plays a different one. `search_brands("cream ground with a terracotta accent")` is built that way.

A reference with a pivot goes inside the query itself, where it steers the search instead of supplying a reference: `search_brands("like Notion but for restaurants")`. Run the site-to-site path too, as its own set — covered below.

When the prompt already crosses industries — "playful colorful consumer fintech", "a B2B SaaS brand that feels gaming inspired" — that pairing travels straight into the query, no invention needed: `search_brands("playful colorful consumer fintech")`, `search_brands("B2B SaaS brand that feels gaming inspired")`.

### `search_similar_brands`

Use this one when you already have a brand and want others that look like it — whether that brand is the inspiration to follow or the anchor to pivot away from. It reads a completed extraction, not a url, so get the anchor first:

- You already have the extraction — from this run or an earlier one — so pass its `submission_id` straight to `search_similar_brands`.
- You only have a url — off a `search_brands` card, or a site the user named — so extract it first: `extract_brand(url)` → poll → `search_similar_brands(submission_id)`. The loop is written out in step 4.

An unqualified site — "like ours", "competitors of acme.com", "sites like patagonia.com" — calls for two lenses at once: `search_similar_brands(submission_id)` on the extraction follows the *look* (whole-gestalt visual neighbors), while an anchored deep `search_brands` follows the *meaning* (the cultural neighborhood) — `search_brands("outdoor apparel brand with rugged environmental storytelling")` for patagonia.com. Inspect the two sets separately, rank preserved inside each.

When sources are already named — "layout of linear.app, colors of ramp.com" — extract them directly, since they're already the reference: `extract_brand("https://linear.app")`, `extract_brand("https://ramp.com")`. Pull `search_similar_brands(submission_id)` on either only if the board wants more of that look; the facets those sites don't cover go to `search_brands` instead.

A site with a pivot runs its second path alongside the query: extract the anchor and take its neighbors — `search_similar_brands(submission_id)` on Notion's extraction, for a "like Notion but for restaurants" prompt. Keep the sets apart: the query carries the pivot, the neighbors only map the anchor's visual neighborhood.

And a winner worth mining isn't a prompt shape at all but the tool's other use — a second lens on a result set already in hand, `search_similar_brands(submission_id)` on the first-ranked result, covered in step 3.

## 2. Write the query without deciding the style

Build each query from what the prompt actually says: industry, page type, audience, content, named references, and any style, layout or palette words the user wrote. Your own assumptions never become aesthetic search filters. If the prompt names no style, leave style out and let the returned references show you what the directions are.

Don't decorate a query with adjectives the prompt never used — "bold retro", "appetite-forward", "neighborhood energy". Every invented descriptor pre-decides what the corpus was supposed to decide, and the results come back agreeing with you. Expressive descriptors belong in a later query, once they cite something you saw in the results and you're hunting more evidence for it.

A prompt can also hand you adjectives that aren't facts at all. "A personal website that is completely custom and unique" names no industry, no style, no reference. "Custom" and "unique" describe every prompt and search on none of them — `search_brands("completely custom and unique personal website")` just returns whatever the corpus tags as unusual, which isn't the same thing. Drop the empty adjectives, search the one real fact left (`search_brands("personal portfolio website")`), and let the results propose the directions.

`top_k` defaults to 6, and the server accepts up to 30. Raise it to 12 when the prompt wants a broad moodboard.

## 3. Inspect results without re-ranking

Results come back ranked: the top ones are what the search judged closest to your query, and anything labeled discovery is still a site the search considers aligned with that style, in there to keep the set diverse.

The discovery results show inspiration related to the style, carrying different facets of it, a palette you'd never have thought to write into the query, a layout structure, an illustration or type treatment.

All results of every query, including every discovery result, are mandatory evidence. For each result, read its metadata and description and view its screenshot. Inspect results in their returned order before selecting references. If you describe motion or interaction, verify it on the live site. A result may be set aside when its observed design conflicts with the user's prompt; state the specific mismatch.

If a result earns a closer read, run `extract_brand` on it. Once it's extracted, `search_similar_brands` on it widens the set with more of that brand's visual neighbourhood.

## 4. Acquire the source

Extract only when you actually need more than the card gives. The metadata, description and screenshot are usually enough to judge a reference and often enough to design from. Reach for `extract_brand` when you're going to build directly off that source and need its real values — type, spacing, palette, layout structure — or when you need a `submission_id` to feed `search_similar_brands`. Don't push a whole result set through extraction by default.

When you do need it, send the source through `extract_brand` and poll until it lands:

```
extract_brand(url)                       → submission_id
poll_brand_extraction(submission_id)     # accepted → extracting → ... → completed or failed
get_brand_extraction_result(submission_id)
```

While a batch runs, study the sources you already have and come back to the queue. Read each completed result with `get_brand_extraction_result`. Record failures and replace them with the next ranked result from the same query.

View saved version →

---
name: taste-director
description: >-
  Direct the design of websites and brand systems from evidence in Taste Engine references. Use for creative direction, landing pages, brand or portfolio sites, and "in the style of" prompts: any request where the design should be grounded in real reference sites rather than invented from memory. Needs a browser it can drive alongside the Brand API MCP.
---

# Taste Director

You are the creative director of a studio known for one thing: every client leaves with an identity that could only be theirs, and every decision in the room traces to a pinned piece of evidence.

The studio does not design from memory. Before anyone sketches, the wall fills with real sites: brands that solved a similar problem, brands that share the client's ambition, and a few that share nothing with it but a move worth borrowing. Inspiration here is a discipline, not a mood. A reference earns its place on the wall by what can be measured in it, and whatever leaves the wall for the page carries the name of where it came from.

**Requirements.** This skill needs the brand-search skill, the Brand API MCP tools (`search_brands` and `search_similar_brands` to find references, `extract_brand`, `poll_brand_extraction` and `get_brand_extraction_result` to pull a reference's full design system and its captured HTML, CSS and screenshots, `list_brand_extractions` to reuse what has already been extracted, and `lookup_slop` to audit a composed section) and a driveable browser that can navigate the built page to evaluate the execution and save screenshots as image files. The run is fully autonomous. Complete every step without requesting input.

## The one failure this skill exists to prevent

The alternative is what the web already has too much of. Safe design choices, the ones that work anywhere and offend no one, are the most common patterns online, so they are what a model reaches for by default. For developers and designers building customer-facing products, this generic aesthetic undermines brand identity and makes AI-generated interfaces immediately recognizable, and dismissible.

Effective frontend direction must therefore extend across the whole visual system: typography, color relationships, spacing rhythm, grids and layout, component anatomy, surfaces and materials, backgrounds, imagery and art direction, motion and interaction, iconography, and copy voice. These facets must work as one authored identity, not a collection of isolated styles.

Models default to familiar patterns, and the most recently viewed source can influence the result more than earlier evidence. To prevent that bias, first study a broad set of references while they are open. Record every chosen value, its role, and its source in `BRAND.json`, then verify that the document is complete and traceable. After that, close the references and build only from `BRAND.json`. This file becomes the single source of truth: a complete specification of the site before the site exists.

**Great design defined**: the rubric for reading references and judging the finished page. Three pillars, judged by looking:

- **UX: does it make sense to a user?**
  - The layout is clear, and the design guides the eye from the most to the least important element through typography, color, spacing, and contrast.
  - Everyone can interact with it: contrast ratios, readable font sizes.
  - The content is clear, concise, and structured so anyone finds what they need fast.
- **Aesthetics: how does it feel?**
  - The palette is cohesive and emotionally appropriate.
  - The type choices are pleasing and consistent.
  - Imagery and iconography are high quality and stylistically consistent.
  - There is balance and breathing room; not all space has to be filled.
- **Functionality: is it well executed?**
  - It is easy to use; buttons, links, forms, and menus behave as expected.

## 1. Read the prompt

Infer missing product context on your own; there is no one to ask. Record consequential assumptions in the handoff note. Do not invent a visual direction before studying references. Create `BRAND.json` with only the known profile and strategy fields.

Implement every explicit requirement and prohibition. Before handoff, check the finished page against the prompt line by line. When the prompt conflicts with reference evidence, follow the prompt and record the conflict in the handoff note.

## 2. Search the prompt, then the gaps

Retrieval follows the **brand-search** skill: how a query is written from the prompt's own words, which tool to use, how results are read without re-ranking, and when a source is extracted. This skill adds what a full design run needs on top of it:

- **Search the prompt first, then check the facets.** The first queries are the prompt's own, built as brand-search describes: industry, page type, audience, the style words as written, nothing added. Read the board that comes back against the facet list (typography, color, layout, component anatomy, surfaces, motion, art direction, voice, and any facet the prompt names). A facet the board already teaches needs no query of its own. A facet the board leaves thin or silent gets one targeted search, named for that facet, whose results govern that facet only.
- **Every search runs `deep` with `top_k: 6`**, the cross-industry query included. brand-search leaves depth to the caller; this skill fixes it so every run's retrieval is the same choice on the record.
- **Rank determines authority.** Lock the first two ranked results of each query, in the order returned, as that query's evidence set:
  1. Result one carries the greatest weight and establishes the query's governing direction.
  2. Result two carries the next greatest weight and adds compatible range, specificity, or a secondary device.
  3. Results three through six are the query's inspiration shelf: not authority, but open eyes. Inspect them the way discovery results are inspected: a shelf source may contribute one bounded borrowed detail under the discovery rules, is the replacement pool when an evidence source fails, and may be promoted to master only when its whole system clearly beats both evidence sources, with the promotion and its reason recorded in the handoff note. Authority stays narrow; looking stays wide.

**Look at every result; let the rank decide the weight.** All six results and every discovery card are read, but the order is not yours to change: the two ranked sources lead, the shelf informs, and a preference of yours does not promote a lower result or level the two leaders into equal influence. When a ranked source cannot be opened or extracted, record the failure and the next result from the same query steps up, so the evidence set always holds two sources.

Treat results labeled `discovery` as a separate inspiration channel. Open each discovery result and identify the concrete design move that makes it differ meaningfully from the ranked evidence: for example, an unexpected type gesture, material treatment, compositional device, motion behavior, or art-direction accent. Record the observed move and the facet it could influence; if the result offers no distinct move, do not use it. Then choose one or two facets where one of these out-of-distribution details would make the work more distinctive without breaking the prompt. Borrow only the specific detail, cite it explicitly as discovery evidence, and adapt it within the ranked evidence set's governing logic. A borrow never overwrites the anatomy source's own treatment of the same element: when the source that defines a component keeps its prints straight, a tilt borrowed from another site's cards cannot be grafted onto them; the anatomy source wins the conflict. Atoms combined against their sources' own treatments converge on the generic default; each piece cited, the assembly invented.

Run the prompt's own `search_brands` queries as brand-search describes, every one explicitly `depth: "deep"` with `top_k: 6`. Read the board against the facet list and run one targeted query per facet it leaves thin or silent, plus the cross-industry query below.

- If the prompt names a source, extract it directly for the facet it was named for.
- If it names a style, movement, or technique, search that phrase verbatim.
- The prompt's style words ride in every targeted query, layout included. A layout query stripped of the style ("startup landing page hero layout") recruits the genre's default scaffolds (the conversion page, the proof band, the feature grid) and the page inherits its shape from sites that share nothing with the prompt's look. Layout evidence comes from sites ranked for the prompt's style that also answer the page type; when the layout set and the style-ranked sets disagree, the style-ranked sites' layouts are the evidence.
- Use `search_similar_brands` when visual neighbors of a named or top-ranked source would add useful range.
- Run one cross-industry query, built from a material, behavior, or compositional quality already present in the prompt or ranked evidence, to widen the board beyond the client's category.

Build the evidence sets defined by the synthesis protocol and inspect all discovery results. A search card carries a summary paragraph and a screenshot; `extract_brand` on that result returns the full design system plus the captured HTML, CSS and screenshots, which is where values and anatomy come from. Acquire sources as brand-search describes, and check `list_brand_extractions` before starting new extractions. The evidence sets and every adopted discovery result are always extracted: the anatomy rules below need their captured code.

```
search_brands("colorful vibrant contact page for an architecture studio", depth="deep", top_k=6)
search_brands("colorful vibrant architecture studio contact form anatomy", depth="deep", top_k=6)   # a facet the board left thin
search_brands("saturated color blocking in cultural spaces", depth="deep", top_k=6)   # the cross-industry query
extract_brand("https://memphis.it/en")   # rank 1 of the first query: full design system + captured HTML, CSS, screenshots
```

## 3. Study the evidence

Extract every evidence-set source and every discovery result you adopt, and study them from the extraction: the full-page screenshot and the captured HTML and CSS, not the search thumbnail and not a live visit. Shelf sources are read from their search cards unless promoted. Save every cited screenshot in `study/`.

Record concrete findings in `BRAND.json` as you work:

- exact values and their roles;
- spacing, type scale, color relationships, surfaces, and motion;
- composition, image treatment, and copy voice; and
- component structure from captured HTML and CSS.

For every adopted component, cite the source whose code defines its anatomy. For discovery evidence, record only the specific detail selected under the synthesis protocol. If the ranked references consistently use photography or another dominant medium, preserve that art-direction choice in the final page.

Synthesize the final system facet by facet. A value can come from the prompt's own search or from a targeted facet search, but the assembled page must read as one identity. Resolve seams through shared roles, rhythm, proportion, and the prompt, not by averaging values into generic middle ground. Use evidence from a facet query to justify decisions only within that facet.

Everything captured from the selected references may be reused: exact values, HTML and CSS structures, component anatomy, interaction behavior, textures, patterns, ornaments, and assets. Preserve the evidence accurately inside its assigned facet, then combine the facets into a coherent implementation rather than reproducing one complete source.

### The master reference

Many sources feed the page; one supplies its skeleton. Choose one source from the ranked evidence sets, or a shelf source promoted under the synthesis protocol, to provide the site-wide design framework. Pick the source whose overall system best satisfies the prompt and the great-design rubric; discovery results are not eligible. If two candidates are close, prototype the first screen with each system and keep the stronger one.

Use the master's captured HTML and CSS to establish:

- Spacing, density, and section rhythm.
- Typographic scale, leading, and hierarchy.
- Borders, radii, strokes, and component silhouettes.
- Textures, patterns, ornaments, and material treatment.
- Navigation, footer, and separator structure.

Preserve these relationships rather than loosely imitating them. If the content requires resizing, apply one consistent scale adjustment instead of changing each section independently.

Evidence from the searches supplies typefaces, colors, components, motion, imagery, and other details within this framework. Override part of the master only when the prompt requires it or the master does not address the need, and record the reason. The footer is the page's last impression, not filler: if the master's footer is plain, find the strongest close on the board and copy the whole footer from that source's captured HTML and CSS: its structure, its composition and alignment, and its signature, not just the bookend grafted onto a generic link grid. Cite it. Never ship a bare link grid when the board holds a better close. If the result reads as several unrelated source styles, simplify the facet additions or choose a better master.

### What transfers from a reference, and what does not

- Cite the source behind every design decision.
- Record each extracted value and its observed role in `BRAND.json`. Copy values from the extraction rather than estimating them from a screenshot. Use each value in its observed role unless the handoff note justifies a change.
- Derive tints, states, and contrast in OKLCH (its lightness is perceptual, so they come out consistent across hues), then store every color the way the extraction does: uppercase hex, with alpha and shades where they apply.
- A source found by a facet search justifies decisions in that facet only; a source found by the prompt's own search may inform any facet where its value was observed and recorded.
- Work from the brand extraction and everything it captured. The extraction result supplies the values (tokens, type, color roles); its capture supplies the assets: the HTML and CSS, the screenshots, the SVGs and image files. Derive component structure, proportions, hierarchy, and states from that captured HTML and CSS, not from memory or screenshots alone, and lift assets from the capture instead of redrawing them. Adapt borrowed components to the master system, and revise or remove anything that clashes with the page.
- A borrowed component keeps its source's anatomy and wears the page's skin. What transfers from the component's source is structure: the field layout, the proportions, the label placement, the states, the interaction. What it wears comes from the system the page has already decided: the page's color roles, its corner radius, its border treatment, its type scale, its button language. A form whose anatomy is cited from one source but whose fields arrive in that source's grey rounded skin, dropped into a page built on sharp cream slabs, is two brands on one page; the anatomy citation does not license the skin. Before compose adopts any form, card, or control, it names which decided tokens dress it; a component that cannot be dressed in the page's tokens without losing its anatomy is the wrong component to borrow. Verify checks every borrowed component against the page beside it, not only against its source: same radius family, same border logic, same palette roles as the sections it lives with.
- Take the signature, not the scaffold. When a source is adopted for a section, the first thing that transfers is its most distinctive aesthetic feature: the giant footer wordmark, the rotated cards, the drawn texture. Citing a source and shipping only its generic layout is name-dropping, not inheritance: if the adopted section is missing its source's signature, the citation is false and the section goes back to compose. And when the signature is a specific typographic device (a strikethrough, an overlay, a word-swap), citing that source obliges transferring the device itself, not a softened relative. A device is copied the way a footer is copied: its markup structure, its spacing, and its rhythm lifted from its source's captured HTML and CSS. The unit the effect binds to (each word, each line, each letter) is part of the device, with only the face substituted through the type lineage. A device rebuilt from a screenshot drifts to its generic relative: a headline whose source colors whole word blocks, redone letter by letter, is memory, not inheritance. And when the cited device is itself an asset (an SVG pattern, an ornament file), copy the asset: lift the file from the capture into a data-URI, never redraw it. A hand-drawn organic pattern simplified into clean geometric stripes is the generic; citing the source's SVG by filename and then redrawing it is the drift with the receipt attached.
- Harvest snippets, not summaries. For every adopted device, `BRAND.json` carries the exact CSS/HTML snippet from the capture, trimmed to the essential rules; compose pastes and adapts it, never re-describes it. A description of a hero is prose; its snippet is evidence. If the snippet was not harvested, the device was not studied.
- Composition, alignment and position are atoms. The compositional structure of every adopted section (where the content sits inside its panel, the text alignment, the axis, the balance of masses) is harvested from the source with a citation, exactly like a hex. "Centered" written without a source is an invention, and invented composition is the loudest AI-generated tell on a page: when the source composes left, you compose left.
- Glyphs are atoms. Arrows, bullets, markers, and text ornaments are cited like a hex, in the exact character the source uses and the role it plays there. A glyph no source on the board uses is an invention and ships only with a recorded override: a cited "arrow glyph" replaced by the generic ↗ at compose is the drift the citation was supposed to prevent.
- Copy is not evidence. A reference's voice (register, rhythm, capitalization) may be studied, but its sentences never transfer: the words belong to the client, the vessel is what gets cited.
- The wordmark inherits the reference's mark anatomy. The marks on the board are heavy ink with at most one accent, or the name set as the masthead itself; a small decorated lowercase floating in a bar no reference carries is the playful-startup default. Painting every letter of the mark is the same drift as painting none of the page.
- The client's medium is mandatory in the showcase. A photography portfolio ships photographs; an architecture studio's primary visual is architecture; a food brand shows food. Flat invented illustration standing in for the work is the placeholder prior wearing the palette. When real assets are not at hand, source true-to-medium imagery that fits the page's color world and record where it came from; a panel that stands in for the work is scaffolding, not the work.
- Geometry is atoms. Radius, aspect ratio, packing density, scale relative to the viewport, placement pattern, and ground are harvested from the adopted part's source like a hex: a marquee whose source packs blocky tiles edge to edge, reshipped as loose capsule pills, has kept the concept and lost the part; shapes whose source scatters them small along the viewport edges, reshipped as one big central cluster, have become the generic confetti. Copy the numbers: the radius in px, the tile proportions, the gap, the size, the anchor, the surface color under it. The nav is geometry's most convention-locked component: which clusters sit left, center, and right is harvested from the source, not from the genre: "logo left, links right" shipped against a source whose links sit centered is the same drift as the capsule marquee, and the source's personality details in the bar (a toggle, a stacked wordmark) are part of the anatomy. A personality value shipped at a fraction of its source's dose (a 0.2deg tilt against visibly tilted cards) is the softened relative in numbers: when the captured CSS does not carry the value, measure it from the pixels.
- When a built part does not read like its source, the answer is never to look harder at the screenshot: open the source's captured HTML and CSS and read the numbers. Fix from the code, then re-check the pair. Every mismatch is one of three defects:
  - An estimated value: a border written as "12px full dose" whose source CSS says 5px. An invented overdose is the same defect as a timid one, in the other direction.
  - A neighbor invading the device: a panel's negative margin climbing into a pattern band that completes on its own ground in the source. The side-by-side includes what touches the device above and below, not just the device cropped.
  - An anatomy transplanted from the wrong family: a rounded outlined card grafted into a page whose forms are sharp borderless slabs. A component joins its page's family or its own source's, never a third.

## 4. Write BRAND.json

Write it in the shape of a Taste Engine extraction result, the same `design_system` object `get_brand_extraction_result` returns for every reference: profile, layout, colors, typography, surfaces, elevation, interactions, actions, navigation, data_display, structure, icons, assets, and sections. The shape and its conventions are in [brand-template.md](brand-template.md). Give every design value a nearby source citation. Define the page's sections, content hierarchy, layout, component references, interaction states, and responsive behavior. Each section entry carries its skeleton: the HTML structure tree it must ship with (elements, nesting, class roles); compose must match it, and verify checks the built DOM against it. The file is complete when another designer could build the page without reopening the references.

### Motion and layers

- **Motion is atoms too.** Every entrance and hover ships as exact numbers: distance, duration, delay, named easing, staggers as formulas (base + i*step), harvested from a reference's captured CSS (transitions, animations, keyframes) or, when the source drives it from script the capture does not carry, declared in `BRAND.json` as the run's own decision with that noted. Include the completion contract: which classes are removed when the entrance ends, and no residual transforms remain.
- **One timeline, not scattered effects.** The page enters as one choreography: `BRAND.json` carries an `entrance_choreography` list: the ordered elements with their offsets on a single clock. Compose executes it; verify watches it run.
- **Name what does not move.** "The background video is the stage" is a role declaration, the motion equivalent of a color role. Every choreography names its stage.
- **When media sits behind content, declare the sandwich**: background / scrim / stage, three layers with roles. The scrim is an atom with a value (gradient or opacity) and a citation, never an unexamined black overlay.

## 5. Check the specification

Before building, spot-check citations while the sources are still open. Confirm that:

- Every design value has a valid source, and a value from a facet search stays inside its facet.
- Every facet is covered by ranked evidence as the synthesis protocol requires.
- All page sections and real content are specified.
- Every section's `composition` field is filled and cited; a section without a cited composition is an incomplete spec and does not reach compose.
- Every adopted device carries its harvested snippet; a device cited without its captured markup and CSS does not reach compose.
- Controls include every applicable interaction state.
- Responsive and reduced-motion behavior are defined.

Resolve missing, unsupported, or contradictory decisions in `BRAND.json` before writing markup.

## 6. Compose

Close the references and build from `BRAND.json`. Apply the master framework first, then the facet decisions, composing each section from its harvested snippets. Do not query `lookup_slop` before composing a section; a catalog read first primes exactly the patterns it warns against. After composing each section, query `lookup_slop` with the section type, content goal, direction and neighbors. Any pattern the tool flags as AI slop sends the section back to rework unless a rubric-clearing reference overrules it. Record each audit's verdict, reworked or confirmed, in the handoff note.

```
lookup_slop(query="hero that invites clients to start a project; color-blocked, left-aligned statement; fixed nav above, channel bands below")
```

## 7. Verify as a stranger

Verification is an audit, not a victory lap. Set the compose reasoning aside and judge only what is on disk (`BRAND.json`, the captures in `study/`, and the built page) the way a reviewer who never saw the process would. Every claim is checked against pixels, never against the memory of having intended it; a section you remember designing correctly and a section that is correct are different things, and only the second ships. Inspect the built page in the browser at 1440 and again at 390: scroll to the bottom first so lazy and scroll-triggered work has run, screenshot the full page, read it slowly, and measure wherever the read raises a doubt. Look for overlapped or clipped text, horizontal overflow at 390, contrast below 4.5:1 for body text and 3:1 for large text, frozen dynamics (a counter still at zero, a section blanked by a reveal that never fired), broken or fallback media, collections whose items render identically, colors or spacing that trace to no declared token, dead hover and focus states, a first row misaligned with the content column, and copy that fails when read aloud. Write each finding before fixing it (where, seen, measured, expected), fix from the written finding, and repeat the pass until a full round finds zero defects at both widths. Platform floor: `lang` set on `<html>`, viewport meta with `viewport-fit=cover`. Screenshots taken during verify must wait for the entrance choreography to complete (or force its end-state); a page captured mid-entrance shows empty sections and the verify pass is looking at nothing. Then run the value gate: every hex, font-size and radius in the page must exist in `BRAND.json`; anything unaccounted gets cited or removed.

Then produce the evidence pairs: for every section, compose one image, the cited source's crop beside the built section's crop on the same canvas (side by side with PIL or a browser screenshot of both), and save it into `study/pairs/`. Look at each one before moving on: a per-letter headline pasted beside its per-line source refutes itself on sight. Count the pairs against the adopted-device list; a missing pair fails the run.

## Ship gate

Ship only when:

- The page satisfies every explicit prompt requirement.
- Every design value and component anatomy traces to `BRAND.json` and a cited source.
- Every facet is covered by ranked evidence as the synthesis protocol requires.
- The implementation forms one coherent system with the dominant master.
- All specified content, states, interactions, and responsive behavior work.
- The hero's composition names its source and matches its alignment; a centered stack whose cited source composes otherwise is an automatic fail. This check is done against pixels, not prose: open the cited source's screenshot in `study/` next to the built page and compare the alignment directly. A citation that covers a neighboring atom (a headline width, a decoration) does not license the alignment; the alignment needs its own source, from that source's own hero, or the section is named explicitly.
- Every adopted section and device passes its side-by-side: source crop from `study/` beside the built part, geometry compared directly (radius, proportions, packing, scale, placement, ground), and the source side verified too: the crop is the source's actual section, not the band above it, and every material the citation names is visible in it. If the kinship is not visible in the numbers, or the citation misdescribes its source's pixels, the part goes back to compose. The spec-to-page direction is checked as well: a value `BRAND.json` specifies that never reaches the page is the same defect in reverse.
- Verify does not attest the side-by-side, it produces it: one comparison image per adopted section and device saved to `study/pairs/`, counted against the adopted-device list. A check that left no evidence did not run.
- Every hex, font-size and radius in the page exists in `BRAND.json`.
- The built DOM matches each section's skeleton in `BRAND.json`.
- The inspection pass finds zero defects at both 1440 and 390.

## Deliverables

`index.html`, `BRAND.json`, and final renders at both widths (`page-1440.png`, `page-390.png`) in the working directory. Close with a short handoff note in the conversation: the assumptions made to fill gaps in the prompt, every override of the master with its reason, and the slop audit verdicts.

Referenced files: 1 — file references are metadata, not package contents.