Echo UI

View saved version →

---
name: echo-design-eye
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.
---

# Design Eye, for Echo

Turn 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.

The 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.

## Where you are

This skill runs in a project, with a terminal, and in a chat, without one.

- **In a project** (any agent that can run commands in the builder's code): everything below applies as written.
- **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:

| Below, in a project | In a chat |
| --- | --- |
| Read the project for the brief | Read the conversation and the files the builder shared; ask only what's still missing. |
| `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. |
| 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. |
| `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. |
| `npx echo-ui-cli style check <the style's folder>` | `check_style`, with the `style.json`. |
| `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. |

## What you're producing

- **One reference**: a single analysis, named as a design language.
- **A style group** (several images sharing one visual logic): one foundation for that style, synthesized across the group.
- **A moodboard** (many images, several styles): one foundation per style, written so they can be compared side by side.

Each foundation is a folder in the builder's library: the document, a `style.json`, and its `assets/`.

## The brief: what will be built

A 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:

- who it's for: the audience, and their age range;
- what they come to do: the one job;
- where they use it: a phone, a desk, both;
- what it must never feel like.

Read 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 questio

Preview of the first 4,000 characters. Read full instructions →

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

View saved version →

---
name: echo-style-fit
description: Pick the visual style a product wears with Echo UI, from the builder's own style library (~/Documents/styles) and Echo's. Profiles the product on the seven temperament axes the styles are placed on, has Echo order every candidate against that profile, reads the best of them, and returns an opinionated pick with the argument for it, the runner-up, what to adapt and what to refuse; then wears it. Use when the builder asks which style fits, how the product should look, to pick a design direction, or whether a style suits the product.
---

# Style Fit, for Echo

Choose the style this product wears, and make the choice arguable. The deliverable is a decision someone could disagree with, not a ranking and not a summary of the options. Echo's grammar stays whatever you pick (the light, what each material is for, state in words, motion as physics, AA); a style changes the vocabulary: colours, type, radius, finish, density, and the rules the agent builds screens by.

**Candidates come from the libraries, not from the builder.** The builder's own styles are in their library, written there by Echo's Design Eye; Echo's are published with the registry. Never ask for documents to be uploaded or pasted.

- `npx echo-ui-cli style list --json` lists every style from both, with its essence, whether it makes a light or a dark device, and where its foundation is.
- `npx echo-ui-cli style show <name>` shows one: its fingerprint, settings, rules, refusals, fonts, and the path of its foundation document.
- The library's `INDEX.md` has each of the builder's styles with its fingerprint and what it serves.

Consider every style unless the builder names some. A style read months ago is still a candidate; the point of a library is that it accumulates.

## Where you are

This skill runs in a project, with a terminal, and in a chat, without one.

- **In a project** (any agent that can run commands in the builder's code): everything below applies as written.
- **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:

| Below, in a project | In a chat |
| --- | --- |
| `npx echo-ui-cli style list --json`, `npx echo-ui-cli style show <name>` | `list_styles` for Echo's (with a name, one in full). The builder's own are the ones they share or point you to in this chat: their `style.json` files, or their library's `INDEX.md` (a fingerprint is enough to rank). If they haven't, ask for them once: in a chat the library can't be read, so this is the one time to ask. |
| The project's `## Product` section, its README and screens | The conversation; ask only what's still missing. |
| `npx echo-ui-cli style fit --profile … --tolerance …` | `fit_styles`, the same arithmetic, with the builder's own passed in as `yours`: each one's name and fingerprint. |
| Save the decision in the library's `decisions/`, with its row | Hand the decision back as a file, `<product>-direction-<yyyy-mm-dd>.md`, to keep beside their styles. |
| `npx echo-ui-cli style use <name>`, and the amendments into `DESIGN.md` | `wear_style` (`name` for Echo's, `style` for theirs): its link lets the builder feel the pick on Echo's own site. Put WHAT TO ADAPT and WHAT NOT TO TAKE in the decision file; in the code tool, they go into `DESIGN.md`'s `## Product` section. |

## The mechanism

The reason this isn't taste: **profile the product on the same axes before looking at any candidate.** Score the product first, then measure distance. The other order, reading the styles and then rationalizing a favourite, produces confident nonsense, and you'll feel the pull, because one option is usually prettier.

1. Build the product's profile.
2. Order the candidates against it, and read the best of them.
3. Argue against the winner.
4. Write the decision, and wear the style.

## Step 1: the brief, then the profile

Read what the project already says about itself: a `## Product` sectio

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: echo-ui
description: Build or change a product's interface with Echo UI, the tactile React design system: a screen, a component, a look from a moodboard, or Echo's check on code. Use it for any interface task on a product that's built, or will be built, with Echo, in a project or in a chat.
---

# Echo UI

Echo UI is a design system for React: components that press, click and move, all on one grammar (the `echo-ui-core` package: theme, sound, motion), with the builder's own style on top. A style changes the look (colours, type, radius, finish, density); the feel stays Echo's.

## Where you are

- **A project with Echo** (an `echo.json` at its root): the project's own Echo skill leads, with the Echo block `init` wrote into the project's agent instructions. They know the project's folder, its style and its checks. Follow them, and leave this one.
- **A project without Echo, with a terminal** (any agent that runs commands in the builder's code): set it up first. `npx echo-ui-cli init`, or `npx echo-ui-cli init --style <name>` when the builder has a style for this product (Echo's `echo-style-fit` skill picks one). `init` writes the project's own skill, `DESIGN.md` and the check, and from then on they lead.
- **A chat, with no terminal** (with Echo's connector): the rest of this skill.

## In a chat: make the style here, build with it in the code tool

1. **A look of their own.** A moodboard goes to Echo's `echo-design-eye` skill, which turns it into a style. Echo's `echo-style-fit` skill picks the style that fits the product, from Echo's and the builder's own. `wear_style` shows the pick: its link makes Echo's whole site wear the style's colours, so the builder can feel it before anything is built.
2. **A screen or a component.** Name the screen's one main action; everything else on it is quieter. Find each part with `search_components` ("a settings toggle", "confirm a delete"), and read it with `get_component` before using it: its anti-patterns are the part a model gets wrong. Style only with `var(--echo-*)`, from `get_tokens`; never a hex, a duration or a shadow by hand.
3. **Check before handing over.** Run `check_code` on every file you write, and fix what it reports the way each finding says. It's the same check the CLI runs in a project.
4. **The handoff.** The code goes into a project in the builder's code tool. End with the commands, in order: `npx echo-ui-cli init --style <name>` (or `npx echo-ui-cli init`, with no style), then `npx echo-ui-cli add <name>` for each component the code uses. A style of the builder's own has to be in their library first, as `wear_style` says.

Echo's components aren't an npm package: `npx echo-ui-cli add` copies each one's source into the project, which owns it from then on. Never write `npm install` for a component; the one package is `echo-ui-core`. The Base UI package is `@base-ui/react` (per-component imports, e.g. `@base-ui/react/dialog`), NOT `@base-ui-components/react` (the old name). Training data may be stale.

The accessibility floor, on every screen: every control has a name: `label`, `aria-label` or `aria-labelledby` (the types require it); a form error goes in words, in the field's `error`; never colour alone; announce with `toast()` from `useToast()`, under one `<Toaster>`; never remove a focus ring, shrink a target below 24×24px, or put `aria-hidden` on something focusable. `get_accessibility` has the rest.