Update to Echo UI

{
  "description": "Read a moodboard or design references as a senior brand, product and UX/UI designer would, and turn each style in it into a design foundation a product can wear with Echo UI: the document, its evidence, and a style.json Echo applies. Use when the builder shares images and wants the product to look like them (\"make it look like this moodboard\"), or asks to analyze, deconstruct or extract a style. In a project it saves to the builder's own style library (~/Documents/styles), private to them; in a chat it hands the files back.",
  "included_files": [
    {
      "relative_path": "references/echo.md",
      "size_in_bytes": 15798
    }
  ],
  "name": "echo-design-eye",
  "skill_md_contents": "---\nname: echo-design-eye\ndescription: Read a moodboard or design references as a senior brand, product and UX/UI designer would, and turn each style in it into a design foundation a product can wear with Echo UI: the document, its evidence, and a style.json Echo applies. Use when the builder shares images and wants the product to look like them (\"make it look like this moodboard\"), or asks to analyze, deconstruct or extract a style. In a project it saves to the builder's own style library (~/Documents/styles), private to them; in a chat it hands the files back.\n---\n\n# Design Eye, for Echo\n\nTurn visual references into a **design foundation**: an evidence-backed document that observes what the work is made of, systematizes the rules underneath it, ends with a fit profile, and then says how Echo wears it. Echo is a design system with a fixed grammar and a free vocabulary: the foundation becomes the vocabulary, a `style.json`, and the grammar stays.\n\nThe output is never a description of a screenshot. It is a document someone could hand to a builder, or to a model, and get new work in that style that the reference never showed.\n\n## Where you are\n\nThis skill runs in a project, with a terminal, and in a chat, without one.\n\n- **In a project** (any agent that can run commands in the builder's code): everything below applies as written.\n- **In a chat** (with Echo's connector, and no terminal): the commands below can't run, and the builder's library isn't on disk. Do the same work this way:\n\n| Below, in a project | In a chat |\n| --- | --- |\n| Read the project for the brief | Read the conversation and the files the builder shared; ask only what's still missing. |\n| `npx echo-ui-cli style sample …` | If this chat can run code, sample the plates with it (Python and Pillow: the dominant values, and a crop of each material you name). If it can't, read the values by eye and mark each one \"read by eye\" in the evidence: a sampled hex and a guessed one aren't the same claim. |\n| Write the style's folder into the library, and its `INDEX.md` row | Hand the folder back as files: `<style-name>.md`, `style.json`, and the plates and crops you made. Say where they go: `~/Documents/styles/<style-name>/` on the builder's computer, where `init --style <style-name>` finds it, and this chat's project, so the next conversation has it. Give the `INDEX.md` row as a line to add. |\n| `npx echo-ui-cli style list` | The styles the builder shares or points you to in this chat: in a chat, that's the library. |\n| `npx echo-ui-cli style check <the style's folder>` | `check_style`, with the `style.json`. |\n| `npx echo-ui-cli style use <style-name>` | `wear_style`, with the `style.json`: its link lets the builder feel the style on Echo's own site, and it gives the command for their code tool. |\n\n## What you're producing\n\n- **One reference**: a single analysis, named as a design language.\n- **A style group** (several images sharing one visual logic): one foundation for that style, synthesized across the group.\n- **A moodboard** (many images, several styles): one foundation per style, written so they can be compared side by side.\n\nEach foundation is a folder in the builder's library: the document, a `style.json`, and its `assets/`.\n\n## The brief: what will be built\n\nA style is reused across products, so the foundation describes the style, not the product. But a moodboard usually arrives for a product, and before Part II's rules meet real screens you need to know what that product is:\n\n- who it's for: the audience, and their age range;\n- what they come to do: the one job;\n- where they use it: a phone, a desk, both;\n- what it must never feel like.\n\nRead the project first: its README, the `package.json` description, the landing copy, the screens already built, and a `## Product` section in `DESIGN.md` if one is there. Then ask the builder only what's still missing, in one message of at most three short questions. These questions are about the product; the style's own questions (its colour, the tiles that don't fit) come after you've read the board (\"Read the board, then ask\", below). Write the answers at the top of `DESIGN.md` as a `## Product` section, above Echo's marked block (Echo keeps anything outside its markers), so every agent on the project reads them. With no product in sight (the builder is only filling their library), skip the brief.\n\n## Reading lenses\n\nPick the lens per image, not per document: a foundation often needs both.\n\n- **Interface lens**: product surfaces, apps, websites, dashboards. Read surfaces, layering, type, colour behaviour, signature affordances.\n- **Imagery lens**: posters, illustrations, renders, photography. Read value structure, surface and mark, lighting, colour, line, contrast, composition, depth, type.\n\nRead [references/echo.md](references/echo.md) once a session before writing: it's Echo's own style as a foundation, and it sets the voice, the altitude and the depth for everything below.\n\n## Three systems: type, buttons, surfaces and colour\n\nA product's look rests on three systems. The builder may bring a board for each (a type board, a buttons board, a UI and colour board) or one board holding all three. With one board, sort its tiles into the three and say which tiles fed which. Read each system for what it *decides*, not only for what it shows:\n\n- **Type:** the faces and why they're paired; what each size is for (a display line, headings, body, labels, data); the weights used and the ones never used; case and tracking; figures, tabular or not; line length.\n- **Buttons and controls:** how the main action, a second action and a destructive one differ; their shape; filled, outlined or bare; the label's case and weight; how far they're raised; what \"on\" looks like.\n- **Surfaces and colour:** how one level sits above another (a shadow, a step of value, a line); how groups are separated; how dense it is; and **each colour as a job**: what it's for, its hue family and temperature, how saturated and how light it reads against the rest. Count where each colour appears: a colour on one tile of many is a question for the builder (below), never the accent on its own. A sampled hex is evidence, not the answer: the theme finds the value that works on the device for every reader, colour-blind readers included, and `style check` says what it moved.\n\n## The board's own tells\n\nA board can carry slop of its own: a sparkle for \"AI\", a strip of round-number stats, three identical cards in a row, an indigo gradient, a stock sans with nothing beside it. A tell on the board isn't a decision the style made. Leave it out of the style's rules, and name it in Part IV under **The board's own tells**, with why it was left behind, so the builder sees it. Echo's slop police knows the common ones, and `style check` runs it on the style you write.\n\n## The stance\n\nThis is not an inventory. \"The nav sits top-left, below it a card\" is a screen reader's output, not a designer's. Placement earns a mention only when it reveals a *rule*.\n\n- **Materials and treatments, not elements.** Name what things are made of, as reusable nouns: \"smoked glass\", \"stochastic dither\", \"pressed paper\". A named material travels to new work; \"the card in the middle\" cannot.\n- **The why behind every choice.** Every observation carries its reason. A bullet that says *what* without *why* is half-finished.\n- **Three designers, one voice.** Brand: what emotion and positioning the choices signal. Product: what the hierarchy claims matters. UX/UI: affordances, legibility, interaction cost.\n- **Commit to the style.** Each foundation argues its own case. Be honest about weaknesses *inside* that commitment: name what the style costs and where it breaks.\n\n## Visual evidence: show, don't just tell\n\nThe document contains its evidence. Sampled hex beats guessed hex, and a claim about a surface lands next to the magnified crop that proves it.\n\n**Preflight.** The CLI needs a real file it can open. An image pasted into the conversation often lives only there: confirm each reference exists on disk at a path the shell can reach (`ls` it).\n\n- **Full evidence mode**: you have real paths. Use the CLI below.\n- **Text-only mode**: you don't, and can't get them. Say so in one line, ask the builder to save the images somewhere reachable if they want figures, and write the document with no image embeds (the fallback below).\n\nNever write a figure reference you haven't verified. A document full of broken image links is worse than one that honestly carries none.\n\n1. For each reference image: `npx echo-ui-cli style sample <image> --out <the style's folder>/assets/<plate> --crop x,y,w,h:material-name --zoom 6`. It writes `reference.png` (the plate), `values.png` (the dominant values, dark to light) and a magnified `crop-<name>.png` for each crop, and prints the real hex with each value's share of the pixels: quote those, dark to light. It gives eight values, and a plate with more colours loses its smallest first: when an accent you can see isn't in the list, sample again with `--swatches 12`. It reads PNG and JPEG; save anything else as one first.\n2. **A collage** (one image holding many references, as a moodboard exported from a canvas is): give each tile its own plate with `--region x,y,w,h`, the tile's box in the collage's pixels. `--crop` stays in the collage's pixels too.\n3. Choose one to three crops that prove your *surface* claims. Look at them after they're made: if a crop contradicts what you wrote, rewrite the claim, not the caption.\n4. Embed with relative paths and plate captions: `FIG. 01 — REFERENCE.`, `DOMINANT VALUES`, `DETAIL / SURFACE AT 6×`, each with one sentence on what it demonstrates.\n5. **Verify before finishing.** List the assets and confirm every embedded path is a real file.\n\n**Text-only fallback.** Replace each figure with its evidence in words: `DOMINANT VALUES` as a hex table read off the image, marked `~` as estimates, and what a magnified crop *would* show as a stated reading. Note in the title block that the document carries no assets.\n\n## Moodboards and style groups\n\nThe first job with a pile of images is deciding what belongs together. Group by **visual logic, not subject matter**: two posters of different scenes belong together if they share a surface treatment and a value structure; two screenshots of one app belong apart if one is a marketing shell and the other a working tool.\n\nIf the builder already grouped them, honour it. If not, cluster them yourself and state each group and its logic in one line. Note an image that fits nowhere rather than forcing it: an outlier is information about the range the builder is drawn to, and what to do with it is the builder's call (below).\n\nKeep the section order identical across foundations from the same board, so they can be read in parallel.\n\n## Read the board, then ask, before you write the style\n\nBuilders don't make clean boards: they collect what they like, and one loud image can sit among nine quiet ones. So between the reading and the writing there is one stop. Read every tile (sample it, group it, see what each system decides), then send the builder **one message, at most three questions**, before you write Part II or a `style.json`. Each question says what the board shows, gives the answer you'd suggest first, and one line on why.\n\n1. **The colour.** Say what the board agrees on, counted in tiles, not in how loud a tile is: \"eight of ten tiles are black ink on white paper; the acid `#D3F44F` is on one, the blue on one\". Then ask which colour the product uses: none (black and white), one of the board's, or one of their own. Suggest the answer the most tiles support. Never take the accent from a single tile: the loudest image on a board is rarely its system.\n2. **The tiles that don't fit.** Name each image that doesn't share the board's logic, in a few words, with why (\"the blue prints: illustrated, warm, a second hue; the rest is drawn line\"). Ask whether to leave it out, read it as a style of its own, or take one thing from it (its imagery, its colour), and suggest one.\n3. **What two readings both defend.** The one thing where the board supports two answers and the choice changes the style: which part is the main action (the white key on its slab, or the filled pill), whether the parts are drawn or molded, whether a grey is a colour or the ink thinned. Suggest one.\n\nWrite the answers into the foundation's title block, under `BUILDER'S ANSWERS`, with the date, so the document says what was decided and by whom, and the same question is never asked twice. With nobody there to answer (a run with nobody watching), take your suggested answers, write them there as yours, and say so in chat.\n\n## The foundation document\n\n**Title block**: the style's name, a one-line thesis, `SOURCE / ANALYSIS / DATE / STATUS`, and `FIG. 01 — REFERENCE` with the plate.\n\n**PART I / OBSERVATION: what the reference is made of.** The materials, textures and treatments, named at component level and stripped of their arrangement. For each: what it physically is (estimates wear `~`; sampled values are quoted exactly), why it works, what it contributes. With several plates, read each under the headings its lens calls for (interface: surfaces, layering, type, colour behaviour, signature affordances; imagery: VALUE STRUCTURE, SURFACE / THE MARK, LIGHTING, COLOUR, LINE, CONTRAST, COMPOSITION, DEPTH, TYPE), and give each plate an honest WEAKNESS and a one-line TAKEAWAY. End with a distillation naming where the character actually comes from (\"texture and material contrast, not colour\").\n\n**PART II / SYSTEM: the rules underneath.** Prescriptive and placement-agnostic: what to do on a screen the reference never drew. If you can't defend a rule from the images, it's an observation; leave it in Part I. Cover what the references support: spatial logic (the principle and the defining move) · the elevation and depth ladder (a table: role, blur, tint, radius, shadow) · surface and texture primitives (reduce the motifs to one primitive with parameters) · colour logic (sampled or authored, the accent budget, temperature, inversions worth stating) · the type scale (what each step is *reserved* for, and what's deliberately absent) · imagery treatment (the house process for any photo or illustration entering the system) · the motion budget (inferred from static cues) · **constraints**: six to ten numbered rejection rules (\"No borders for separation. Only tint and blur delta.\"), the part that makes it a language rather than a moodboard.\n\n**PART III / FIT PROFILE.** The contract with Style Fit, which reads it to match a style to a product. Keep the labels and the axes exactly as written. Place the style on each axis with these anchors, so two readings of the same board land within a point:\n\n| Axis | 1 ←→ 5 | A 1 looks like | A 3 | A 5 |\n| --- | --- | --- | --- | --- |\n| Warmth | clinical ←→ human | cool neutrals and hard geometry, no trace of a hand: lab equipment, a terminal | neutral, with one human touch: a warm accent, a rounded corner, a photograph kept in its place | a warm palette, marks made by hand, people in the pictures: paper grain, brush, faces |\n| Volume | whisper ←→ shout | near-monochrome, small type, most of the page is air | one confident accent and a clear hierarchy | saturated fields, type the size of the screen, colour everywhere |\n| Density | sparse ←→ dense | one idea a screen, wide margins | cards with room between them, a few controls at a time | tables, many controls at once, a console for an eight-hour day |\n| Formality | playful ←→ severe | jokes, stickers, bounce, shapes that don't line up | friendly, and orderly | a strict grid, an institution's voice, no play |\n| Era | heritage ←→ futuristic | serifs, print craft, ledgers and archives | timeless modern: a clean grotesque, nothing dated | glass, light and gradients: the future as a surface |\n| Craft | raw ←→ engineered | rough, handmade, unaligned: a zine | tidy, with a hand still showing | precision everywhere: every value on a scale, nothing approximate |\n| Ornament | austere ←→ decorative | nothing that isn't needed | one signature flourish | pattern, illustration and decoration throughout |\n\n```\n## PART III / FIT PROFILE\n\nTEMPERAMENT — position on each axis, 1–5, one clause of evidence each:\n| AXIS | 1 ←→ 5 | POS | EVIDENCE |\n| Warmth      | clinical ←→ human      | n | ... |\n| Volume      | whisper ←→ shout       | n | ... |\n| Density     | sparse ←→ dense        | n | ... |\n| Formality   | playful ←→ severe      | n | ... |\n| Era         | heritage ←→ futuristic | n | ... |\n| Craft       | raw ←→ engineered      | n | ... |\n| Ornament    | austere ←→ decorative  | n | ... |\n\nSIGNALS — what a viewer feels in the first two seconds, before reading a word.\nSERVES — product categories, audiences, and moments this style is built for.\nSTRAINS — where it breaks: content types, screen densities, scales it cannot carry.\nCOSTS — what executing it demands: craft, budget, engineering, ongoing discipline.\nADJACENT — styles it blends with, and the one it must never be mixed with.\n```\n\n**PART IV / ECHO: the style, as Echo wears it.** Sort every Part II rule into one of three places, and say where each went:\n\n| Lands as | What it becomes | For example |\n| --- | --- | --- |\n| A setting | a value in `style.json`'s `seed` | a near-black body, one amber accent, matte, crisp corners, a medium grotesque |\n| A rule for the agent | a short line in `style.json`'s `rules` (three to eight) | \"Colour only for state.\" \"One display sentence per band.\" |\n| A refusal | `{ wants, instead }` in `style.json`'s `refusals` | \"Red for errors, green for success\": instead, the LED's shape and a word on its tag, since Echo never says a state in hue alone |\n\nEcho's grammar never moves, so a rule that needs it to is a refusal:\n\n- a part you press looks pressable and travels when it's pressed;\n- what each material is for: caps are pressed, wells hold a value, screens report, glass arrives and leaves;\n- state is said, never only coloured: a word, a shape, a mark;\n- motion is physics (springs, travel), and reduced motion always wins;\n- sound is feedback, muted until the person turns it on;\n- WCAG 2.2 AA, which the theme holds for every colour role.\n\n**How a part is rendered is not the grammar.** Echo's parts can be *molded* (plastic lit by one key light from the upper left: a bevel, a shadow, a glow) or *drawn* (the same parts drawn in one ink: outlined, hollow, standing on a hard ink edge they travel down when pressed, as a spec sheet draws a key). Flat and drawn are different things: flat has no depth, drawn shows its depth in line. A board of outlined, hollow controls that still look pressable is `render: drawn`, a setting, never a refusal.\n\n**Before you refuse.** Read Part I's distillation again. If a refusal would drop what it names as the style's character, it's the wrong translation: look again for the setting (`render`, `radius`, `finish`, `chassis`). If there truly isn't one, stop and ask the builder before writing the style, and say what Echo would lose.\n\nWhat a style can set today, and where on the board to read it:\n\n| `seed` | Read it from |\n| --- | --- |\n| `chassis` | the body: the surface the parts sit on (the ground of cards and panels, not always the page) |\n| `paper` | the ink: the colour most text is in |\n| `accent` | the builder's answer to the colour question: the one colour the style spends on \"on\". For black and white it's the ink itself. Other colours on the board become rules or refusals |\n| `lcdTint` | the tint of screens and readouts, when the style has them |\n| `render` | how the board shows its parts. `molded` when they're shaded, lit or glossy (plastic, glass, a bevel, a soft shadow). `drawn` when they're outlined in one ink and hollow (a spec sheet, a wireframe, a technical drawing, an outlined pill on a hard ink edge). Drawn has no light, so `finish` doesn't apply, nothing glows, what's lit is solid ink, and the accent stays the board's own colour as a fill under the ink |\n| `finish` | 0 matte (uncoated paper, flat print) to 1 glossy (lacquer, glass, a specular rim); molded only |\n| `radius` | the corners of boxes, panels and fields: 0 crisp (hard corners) to 1 soft. Read it from the boxes, not the buttons |\n| `pills` | read it from the buttons and segments: write `pills: true` when they're full pills, whatever the boxes' corners (pill keys on crisp boxes is a spec sheet), `pills: false` when the boxes are soft and the keys aren't. Leave it out when they agree |\n| `density` | `compact` for Density 4–5, `default` for 3, `comfortable` for 1–2 |\n| `fontMachine`, `fontSans`, `fontMono`, `fontLcd` | labels and caps, body text, data and code, screens: a CSS font stack each |\n\n**Fonts.** Name a free font close to what the board uses (Google Fonts, or a system font), and list it in `fonts` with its role, source and link. A font the builder already owns, or the project already uses, wins.\n\n**Motion and sound.** A still image has neither: infer them from the temperament, and mark them `\"inferred\": true`.\n\n| Temperament | `motion.character` | `sound.voice` |\n| --- | --- | --- |\n| Volume 1–2, Formality 4–5 | short and damped, no overshoot | dry, quiet ticks |\n| Volume 3, Formality 3 | Echo's springs as they are | Echo's clicks as they are |\n| Volume 4–5, Formality 1–2 | springy, with overshoot and play | bright, round pops |\n| then Warmth 4–5 | softer, slower to settle | lower, softer |\n| or Warmth 1–2 | quicker, exact | higher, drier |\n\n**Decisions.** What a designer used to settle in each screen's mock, one short line each, in `style.json`'s `decisions`:\n\n- `emphasis`: how something is made important\n- `primaryAction`: the one main action\n- `secondaryAction`: a second action\n- `destructiveAction`: a destructive action\n- `currentPlace`: \"You are here\"\n- `status`: how a state is said\n- `typeRoles`: what each type size is for\n- `layout`: how a screen is composed\n- `surfaces`: how one level sits above another\n- `colourJobs`: what each colour is for\n- `iconography`: icons\n- `imagery`: photos and illustration\n- `copyVoice`: how the product talks\n- `emptyStates`: an empty screen\n\nWrite each from what the board shows, in its own terms (\"importance is one large number; everything else is small, at the edges\"). A decision comes from a part on the board doing that job: the second action from a second button, not from a tag beside the first. Leave out what the board doesn't show: `style check` lists what's undecided, and the agent building a screen asks the builder or uses Echo's default and says so. Never fill one from habit: an invented decision is a default with a name.\n\nWrite `style.json` beside the document:\n\n```json\n{\n  \"version\": 1,\n  \"name\": \"graphite-showroom\",\n  \"title\": \"Graphite Showroom\",\n  \"essence\": \"A dark showroom with one lit object; austerity as luxury.\",\n  \"fingerprint\": { \"warmth\": 1, \"volume\": 1, \"density\": 3, \"formality\": 4, \"era\": 4, \"craft\": 5, \"ornament\": 1 },\n  \"seed\": { \"accent\": \"#E8A33D\", \"chassis\": \"#16171A\", \"paper\": \"#ECEAE6\", \"finish\": 0.2, \"radius\": 0.3, \"density\": \"default\", \"fontSans\": \"\\\"Inter\\\", system-ui, sans-serif\" },\n  \"fonts\": [{ \"role\": \"sans\", \"family\": \"Inter\", \"source\": \"Google Fonts\", \"url\": \"https://fonts.google.com/specimen/Inter\" }],\n  \"rules\": [\"Colour only for state.\", \"One lit object per screen: everything else recedes.\"],\n  \"decisions\": { \"emphasis\": \"One lit object; everything else recedes into the dark.\", \"primaryAction\": \"The amber cap, one per screen.\", \"status\": \"A word and an LED, never a colour alone.\" },\n  \"refusals\": [{ \"wants\": \"No shadows; depth is a tint step\", \"instead\": \"a matte finish, which keeps shadows shallow: Echo's parts are molded and lit\" }],\n  \"motion\": { \"character\": \"short and damped, no overshoot\", \"inferred\": true },\n  \"sound\": { \"voice\": \"dry, quiet ticks\", \"inferred\": true }\n}\n```\n\nThen check it: `npx echo-ui-cli style check <the style's folder>` lists every problem at once; fix them all. It also says which device the style makes (a pale chassis makes Echo's light device: light plastic, and screens of paper glass printed in ink), what the theme will correct for contrast, and whether the accent comes out as another colour (a molded device holds every accent to one lightness, so an acid comes out olive; a drawn one keeps it as a fill under the ink): note all three in Part IV.\n\n**The slop police.** The same check runs Echo's slop police on the style. It bans pairings that read as AI-made (a mid-grey ground; cream with terracotta or orange; near-black with one acid colour; cream, brass or oxblood, and a serif; indigo or violet on white, in a stock sans; one stock face, for everything), names the ingredients it found, and prints the question for the builder. **Never keep a ban yourself.** Ask the builder (below). If they keep it, add `{ \"rule\": \"<its name>\", \"reason\": \"<their words>\" }` to `keeps`. If they don't, change one ingredient toward the board's own evidence and check again. Say in Part IV what the police stopped and what was decided.\n\n**CLOSING.** The name and its decision procedure: the single question a designer asks when the spec is silent, and how each answer resolves.\n\n## Asking the builder\n\nWhen you're not sure, ask. Don't guess, and don't reach for your own default: a default nobody chose is exactly what reads as AI-made. You're not sure when:\n\n- the slop police stops something the board or the builder seems to want;\n- no decision in the style covers a choice you're about to make;\n- two rules disagree.\n\nAsk in one message, at most three questions, each with the answer you'd suggest first and one line on why. Write the answer where it will be read next time (the style's `keeps` or `decisions`, or the `## Product` section of `DESIGN.md`), so the same question is never asked twice.\n\n**Only the builder keeps a banned pairing.** Never add to `keeps` on your own. If no one is there to answer (a run with nobody watching), take your suggested answer, say so in your last message, and where the police is involved, change the ingredient instead of keeping it.\n\n## Naming\n\nTwo words: a material or mood, and an object metaphor (Graphite Showroom, Corduroy Cloud). A good name carries the decision procedure, so the closing almost writes itself. The folder and `name` are the same words, lower case, joined by hyphens.\n\n## Craft rules\n\n- Concrete values (sampled hex, px, %, opacity) are what make a foundation executable.\n- Constraints in the negative (\"No X. Only Y.\") do more work than encouragements.\n- The tone is a senior designer writing a locked spec: declarative, warm-blooded, no hedging. Short titles, em-dash bullets, italics for the load-bearing idea.\n- If an image is too low-resolution to read a surface honestly, say what you can't see rather than inventing it.\n\n## A foundation without its Echo part\n\nThe library may hold foundations written before Echo: a document with Parts I to III and no `style.json`, which `npx echo-ui-cli style list` marks \"only its document\". It doesn't need its moodboard read again: the document already has its plates, its sampled values and its rules. Write only PART IV / ECHO from it, exactly as above: the settings from its sampled values, every Part II rule sorted into a setting, a rule for the agent or a refusal, the decisions it supports, its fonts, and motion and sound from its temperament. Add the Part IV to the end of the document in the voice it's written in, leave Parts I to III as they are, write the `style.json` beside it, and check it. If its figures are missing, say so: the style can still be worn.\n\n## Output\n\n1. Write to the builder's library, `~/Documents/styles/<style-name>/`, or wherever `ECHO_STYLES_DIR` points (`npx echo-ui-cli style list` prints the path): `<style-name>.md` (the document), `style.json`, and `assets/`. It's theirs and private: nothing in it goes into the project.\n2. From a moodboard, one folder per style.\n3. The library holds work from earlier sessions. Never write loose files into its root, and never copy a folder's contents up a level. If a name is taken, update that folder deliberately or choose another name; check before overwriting.\n4. **Register it in the library's `INDEX.md`**: a row per style in its table, `| STYLE | FINGERPRINT | ESSENCE | SERVES |`, with the name linking to the document, the fingerprint as `W_ V_ D_ F_ E_ C_ O_`, the one-line essence and a condensed SERVES, alphabetical. If the document went out text-only, say so in the index's assets status. With no index yet, start one: a title, a line on what it is, the seven axes and their ends, and the table. The index is how Style Fit, and the builder, find a style without opening every document.\n5. **Last, verify**: every figure in the document resolves to a real file (or, text-only, there are none), and the style check is clean: no banned pairing left that the builder didn't keep.\n6. In chat, keep it short: for each style, its name, its one-sentence essence and its fingerprint; what the builder answered (or that you took your own suggestions); whether it has figures or is text-only; what the theme corrected; what the slop police stopped, and what the builder said or what you changed. Then offer to wear it: `npx echo-ui-cli style use <style-name>`.\n"
}