One command line, your whole design system.

Turn the design system you ALREADY have into a contract your coding agent follows - without touching a line of your CSS.

`init` installs our tokens, which is why it ends in a one-time setup you have to do by hand. If your project already declares its own custom properties, none of that applies: they are in `:root` and already painting the screen, and what is missing is not code but the contract - the file your agent reads before it writes UI. So adopt writes no CSS at all. It reads your stylesheets, describes your system in `_synthesisui/`, and adds a managed block to CLAUDE.md pointing at it. Your tokens keep your names, your files are not rewritten, and `clean` removes every trace. It is a dry run by default: nothing lands on disk until you pass `--write`.

── Adopt ─────────────────────────────────────────────────────────

  Reading your system … 3 stylesheets, 29 tokens found

    colour      19
    spacing      6
    radius       4

    from src/app/globals.css (29)

  Would create (nothing written yet):
    _synthesisui/ds/acme/system.json    your system, described
    _synthesisui/ds/acme/GUIDE.md       what your agent reads
    CLAUDE.md                           a managed block pointing at it

  Your stylesheets are not touched. Nothing outside
  _synthesisui/ is written, and `clean` removes all of it.

Read the app you already have and turn it into your design system - v1 mirroring your own values exactly.

The entrance for somebody who already shipped something. It takes a CENSUS of your project: every colour, radius, spacing and font, ranked by how often it repeats, plus the tokens you already declare - all arithmetic, no inference, the same scan the doctor runs. `--dry` writes that census to `_synthesisui/census.json` and sends nothing, so you can read the payload before it leaves the machine. Without `--dry` (and after `login`) it becomes a design system on your account, and the promise there is fidelity: v1 carries YOUR values under YOUR names, nothing normalised, nothing improved, scoring exactly as well or badly as your app does. That honesty is what makes the v2 it proposes afterwards worth approving. A role your project never names is left neutral rather than guessed, and the report says how many. An agent can annotate the census with judgement a parser cannot make - which grey is the real grey, which family is the display voice - and send that back with `--census`; any value it invents that your code does not contain is dropped.

── What your project says ────────────────────────────────────────

  next · react · tailwind
  2 files · 12 distinct design values
  10 color · 5 radius · 4 spacing

  #ffffff color, 3× in 2 files
  12px radius, 3× in 2 files
  #71717a color, 2× in 2 files

  Written to _synthesisui/census.json
  Nothing was sent. Read the file, then run it without --dry.

── This root holds several projects ──────────────────────────────

  3 apps (apps/web-admin, apps/web-dashboard, apps/web-review) - and this
  census is the average of all of them.
  That is a fine DIAGNOSIS and a poor system: a light app and a dark one
  average into a palette that is neither.

  The shape that works, if your vocabulary is shared:
      synthesisui import --dir packages/ui   the system comes from here
      synthesisui doctor apps/web-dashboard  how far this one is from it

Wire your agent to the system: the check as a hook, the system as tools, and a contract that stops repeating itself.

Three layers, and only the first one guarantees anything. The HOOK runs the check after every file your agent writes, so whether it happens stops being the agent's decision - measured on a real build, an instruction to run the check by hand sat at line 24 of a 44-line file and was ignored. The TOOLS let it ask this system what a value is called instead of guessing. And the CLAUDE.md block, seeing the hook installed, stops demanding a check that already happened, because two places asking for the same thing is drift in the instructions. Both config files belong to you: every write is a merge, running it twice changes nothing, and a file it cannot parse is refused rather than replaced. Restart your editor session afterwards - hooks and tools are only read at startup.

── Connected ─────────────────────────────────────────────────

  ✓ .claude/settings.json  the check now runs after every write
      npx synthesisui@0.16.13 hook
  ✓ .mcp.json              four tools, so the agent can ask instead of guess
  ✓ CLAUDE.md              rewritten for what is installed

  Reopen your editor session - both are read at startup.

The design system as tools your agent can query. Local, no account, no network.

Started by your editor, not by you - `connect` registers it. Four tools: check_file measures one file and names the token this project already has for every literal; find_token answers what the system calls a value, and refuses when nothing holds it; list_components is the live catalogue with what each component is for; add_component materializes one as real code. It reads the system already installed in the project, so it works offline and needs no account.

The check, run by your editor after every write rather than remembered.

Started by your editor, not by you - `connect` installs it. It reads the file that was just written and reports the token this project already has for anything hardcoded, plus any --ds- name the system does not declare. It never blocks: refusing an edit makes the check an adversary, and an adversary gets disabled within a day. And it is silent when there is nothing to say, because a hook that speaks on every edit is noise, and noise is what gets a hook removed.

Audit any repo for drift - every design value written by hand, and the token your system already has for it.

The only command that needs nothing: no account, no install, no network. It reads your files and writes none of them. It does not need a system from us either: if your project declares its own tokens - `--acme-color-primary` in `:root`, Tailwind v4's `@theme`, anything at the root - it measures your code against YOUR vocabulary and names the drift with your own words. With one of our systems installed it also reports where the code overrules a component the system defines, and where the system contradicts itself. With no tokens anywhere it still counts the distinct design values written by hand, which is the number worth knowing before anything else.

── Doctor ────────────────────────────────────────────────────────

  No system installed - 1 file read

  4 distinct design values are written by hand here.
  No design system is installed, so none of them has a name yet.

  Give them one:
      npx synthesisui@latest init --ds <slug>

── Doctor ────────────────────────────────────────────────────────

  Ember v22 - 87 tokens, 3 files read

  Token coverage  ░░░░░░░░░░░░░░░░░░░░░░░░    0%
                  0 from the system, 6 by hand

  6 values by hand · 5 already have a name
  4 overrides · 4 left the system

  Where to start
      1. the 4 overrides that left the system  4 places
      2. #f5f2f6 → --ds-color-obsidian-100     2 files  (cheap)
      3. #a79eb2 → --ds-color-obsidian-300     2 files  (cheap)

Connect the CLI to your account (device flow).

Opens a short device-code flow so the CLI can reach your private systems and the hosted AI commands. Public gallery systems don't need it.

→ opening https://www.synthesisui.com/device?user_code=WXYZ-1234 (code pre-filled)
✓ logged in as you@company.com

Write _synthesisui/config.json (framework target + folders) and optionally bring a system in.

Bootstraps a project: records where pages and components live and which framework you target, so later commands need no flags. With --ds it also pulls that system in right away (tokens + rules + philosophy + CLAUDE.md).

List the published design systems.

ember        v13   Warm obsidian, incandescent gradients
halogen      v11   Cool, clinical, high-contrast
…

Materialize a design system into _synthesisui/ds/<slug>/ (tokens, recipes, GUIDE, CLAUDE.md).

Brings the whole system into your project: tokens.css + theme.css, the recipe catalog, rules.md / philosophy.md (when authored) and a GUIDE.md the agent reads. Public systems need no login.

✓ Halogen v11 → _synthesisui/ds/halogen/
✓ CLAUDE.md updated - the agent now knows the system

Print a ready-to-paste prompt for your coding agent to build/modify UI on-system.

Reads only local state (no network) and prints a prompt describing the task on-system: which files to read first, the data-ds scope, the styling contract and where files go. Works for both building new UI and modifying existing UI. Pipe to pbcopy to copy just the prompt.

Materialize a whole page from a system template into your project.

Codegens a deterministic page from the system's templates - the .tsx plus co-located scoped CSS (responsive + the CSS-only hamburger). Refine it in place; it stays on-system. (Formerly `page`; the old name still works.)

Bring one component (recipe + compiled CSS) from a system into the project.

Granular 'bring specific': writes a single component under _synthesisui/ds/<slug>/components/ - handy for one you refit or created on the platform. Its styles reference the DS tokens, so install the system (add <slug>) for tokens.css to resolve.

✓ pricing-tier → _synthesisui/ds/halogen/components/pricing-tier.{json,css}

Move an installed system to the latest version and get a migration brief for your agent.

Re-materializes the artifacts under a new v<n>/ (the old folder stays, for rollback and diff), regenerates the components the CLI itself wrote, and writes UPGRADE.md - a deterministic list of what changed, breaking items first. Hand that file to your coding agent. A variant that never rendered anything is housekeeping, not a breaking change, and the brief says so.

↑ Ember v18 → v22 (kept v18/ for rollback)
  rules.md → 7 rules (read these first)

── Upgraded ember: v18 → v22 ─────────────────────────────────────

  No breaking changes detected.

  The migration brief is at _synthesisui/ds/ember/UPGRADE.md

Strip create-next-app boilerplate so the system has a clean surface to land on.

Dry run by default: it lists what it would remove and touches nothing. The starter's own CSS fights a design system for the same selectors, and its leftovers are the single biggest source of a page that renders unstyled after install.

The queue of what your agent needed and the system refused to invent.

When the agent hits a gap - a component the catalogue lacks, a value with no token - the contract makes it file the gap instead of inventing, with the use case and what it considered already written. Run bare to read the queue; close a request once you have authored it or decided against it. Nothing expires on its own.

Send the local record - checks, fixes, open requests - to your system's dashboard.

The hook writes a ledger on your machine and never touches the network. This is the one command that ships it, by hand, to the overview page of a system you own. Re-running is free: the server dedupes events and treats the request queue as a snapshot, so the local files stay the source of truth.

Generate a token-only component recipe for your system with hosted AI.

Our AI generates a new component as a validated token-only recipe (anti-hallucination by construction) and writes it under _synthesisui/ds/<slug>/generated/. It wears the system automatically.

✓ upgrade-banner generated (recipe + css)
  → _synthesisui/ds/halogen/generated/upgrade-banner.{json,css}

Get engagement-pattern proposals tailored to your product (hosted AI).

Describes your product and gets back proposed engagement patterns to consider - it proposes, never auto-applies.

Adapt a component you already have INTO your system, and get the code back.

Point it at a file you wrote (or one an agent wrote for you) and it comes back re-expressed in your tokens, keeping the structure and the behaviour. Uses hosted AI, so it needs login and spends credits - the deterministic commands never do.