@getvitops/cli 0.9.0 → 2.0.0

package/CHANGELOG.md

@@ -1,5 +1,445 @@
 # @getvitops/cli
 
+## 2.0.0
+
+### Minor Changes
+
+- bf453b0: Anywhere the toolchain takes a config, that file may now be a `design-system.json` **or** the larger
+  site config that embeds one.
+
+  If you keep your tokens inside a `company.json` / `site.json`, you had to maintain a second file for
+  the tooling's sake — or duplicate your whole token set, because a site config must carry a complete
+  `designSystem`. Now you point the same option at the file you already have:
+
+  ```js
+  // astro.config.mjs
+  getvitops({ css: { input: 'company.json', format: 'css' } });
+  ```
+
+  ```
+  vitops generate --input company.json --format css --out dist
+  vitops lint --input company.json --src src
+  ```
+
+  The design system is taken from `designSystem.themes[theme]` with its `extends` chain resolved —
+  `defaultTheme`, else `default`, else whatever `--theme` / the `theme` option names. Nothing changes
+  for a plain `design-system.json`; the two are told apart by shape, not by filename, so you can call
+  the file anything.
+
+  **A site config also supplies the site-level facts generation reads**, so the path is declared once
+  rather than per option:
+  - `designSystem.defaultColorScheme: "system"` — emits the `prefers-color-scheme` block, which is
+    what makes `<color-scheme-toggle>`'s System position do anything.
+  - `legal.*.enabled` — renders the documents. `legal: {}` is now the whole declaration; `legal.input`
+    is optional.
+  - `icons.sprite` — builds `icons.svg`.
+  - `fonts` — `fonts: true` reads the families from it.
+
+  Each of those is already gated on a field in that config, so nothing new appears unless the config
+  asks for it. An explicit `site` option still wins when the two are genuinely different files.
+
+  Also:
+  - **`vitops validate` routes on the file's shape.** Pointed at a site config it used to report a
+    single `unrecognized_keys` for `designSystem` and nothing about the file's actual contents — a
+    wrong answer that reads like a right one. It now validates a site config as one, including the
+    cross-field integrity JSON Schema can't express, and checks every theme resolves to a complete
+    design system (`validateSite` only checked that the `extends` chain resolved, not what it resolved
+    to).
+  - **`generate()` gained `theme` and `siteEnv`.** The A/B variant for `siteEnv` is applied before the
+    theme is selected, so a variant can override tokens.
+  - **The theme editor's Save to source follows the design system into a site config.** Its patch is
+    design-system-relative, so the dev server merges into that subtree and writes only the surrounding
+    file whole. It locates the subtree in the raw on-disk object rather than the normalised one, so an
+    author who wrote either `designSystem` shorthand still gets their own keys edited.
+
+- 04a51d8: Icons: one semantic vocabulary across icon sets, with the bundle derived from your source.
+
+  Name icons by meaning — `<Icon name="menu" />` resolves to `fa7-solid:bars`, `ph:list` or
+  `lucide:menu` depending on the set you configure, so swapping sets is a config edit rather than a
+  find-and-replace. A name containing `:` still passes through untouched, which is the escape hatch
+  for a set-specific glyph.
+
+  **New `icons` option on `getvitops()`.** Configures the sets once per site and, under
+  `output: 'server'`, derives astro-icon's `include` map by scanning your source — the list most
+  projects end up maintaining by hand. On a static build no `include` is passed at all, because
+  astro-icon is already zero-config there and a list could only drop a glyph the scan couldn't see.
+  Names you declare that don't resolve fail the build; names only the scan found just warn; names
+  computed at runtime are reported with file and line so you can declare them.
+
+  **New `<Icon />` component**, and a real fix with it: `Popover`, `Details` and `Drawer` imported
+  `astro-icon/components` at module scope, so the _optional_ peer was resolved whether or not an icon
+  ever rendered — hard-failing anyone who hadn't installed it. Engines now load dynamically. The
+  per-component `iconResolver` prop still works but is deprecated in favour of the integration option.
+
+  **New SVG sprite** (`icons.sprite: true` in your site config) for consumers that can't run an icon
+  integration — Bricks/WordPress, EmDash renderers, plain HTML. `<use href="…/icons.svg#ph--list">`,
+  no JavaScript and no icon-API request. Every semantic name also gets a set-independent `icon-<name>`
+  alias, so sprite markup survives an icon-set change. WordPress gets `vitops_icon()`, a
+  `[vitops_icon]` shortcode and a **Vitops → Icon** Bricks element.
+
+  **New `vitops icons`** command: reports which icons your source uses, which names couldn't be
+  resolved, and which are computed at runtime; `--sprite` builds the sprite, `--json` for CI.
+
+  **Renamed, and completed to all four directions.** Chevrons and arrows are the
+  one family whose _meaning is_ its direction, and that direction is physical, not
+  logical — a chevron in a details marker points down in every writing mode. So they
+  are named for where they point: `expand-more`/`expand-less` →
+  `chevron-down`/`chevron-up`, and `arrow-forward`/`arrow-back` →
+  `arrow-right`/`arrow-left`. `chevron-left`/`chevron-right` keep their names.
+  `arrow-up`/`arrow-down` are new, so both families now cover all four directions.
+  `lightning` is new.
+
+  If you passed any of the old names to `<Icon />`, `resolveIcon` or an `icons`
+  config, update them. They fail loudly rather than silently: an unresolvable
+  declared name throws, and `vitops icons` reports scanned ones.
+
+  **Fixed three Font Awesome mappings that named no real glyph** and so rendered an
+  empty box: `login`/`logout` were mapped to `login`/`logout` (Font Awesome calls
+  them `right-to-bracket`/`right-from-bracket`) and `backup` to `backup`
+  (`cloud-arrow-up`). Every value in all four UI sets is now checked against the
+  installed collection.
+
+  **Phosphor (`ph`) joins the semantic map**, with all 83 names verified against the real icon set.
+  Phosphor keeps every weight in one collection and varies the name (`list`, `list-bold`), unlike Font
+  Awesome's per-weight collections, so `resolveIcon` and `generateIconInclude` gained a `weight`
+  option for sets shaped that way.
+
+  Fixes: `site.icons` was a closed object, so any icon collection not in its hand-written key list was
+  silently dropped during validation — your config passed and the icons never bundled. It accepts any
+  collection name now.
+
+- bf453b0: `vitops lint` now catches hand-written CSS that re-implements a framework primitive.
+
+  The existing linter finds classes that resolve to nothing — you named something and it isn't there.
+  This is the costlier inverse, where the code **works**: a centred container written by hand, a
+  two-column split behind a media query, a flex row. Nothing is broken, so nothing ever surfaces it,
+  and the design system quietly stops being where those decisions live.
+
+  Three rules to start, each requiring the combination that makes the intent unambiguous
+  (`margin-inline: auto` alone is not a centred track):
+
+  | Found                                                       | Suggested                                                                 |
+  | ----------------------------------------------------------- | ------------------------------------------------------------------------- |
+  | `max-inline-size: var(--width-*)` + `margin-inline: auto`   | `.centered`, widening a child with `breakout` / `spotlight` / `fullbleed` |
+  | `grid-template-columns: 1fr 2fr` inside a `min-width` query | `md-split-1-2` — or `@md:split-1-2` in the tailwind format                |
+  | `display: flex` + `align-items: center`                     | `flex items-center`, or `.cluster-start`                                  |
+
+  **Findings now carry a severity, and suggestions do not fail the command.** These are judgement
+  calls, and a reuse hint that broke CI on the day it shipped would be a worse defect than the drift it
+  reports. `--strict` promotes them for anyone who wants the ratchet. Everything the linter reported
+  before is an `error` and still exits 1.
+
+  `.css` files and `<style>` blocks are now read (the class linter only ever looked at markup). The
+  generated stylesheet is skipped by its `GENERATED … do not edit by hand` banner rather than by path —
+  the `css` format writes `styles.css` into `src/styles`, squarely inside what `--src` scans, and
+  linting it made the framework report `.split` as reinventing `.split`.
+
+  Two other gaps closed:
+  - **The format-spelling check ran in one direction only.** `md-split-1-2` in a tailwind project was
+    caught; `@md:split-1-2` in a css/bricks project was not, because variant stripping removed the
+    `@md:` regardless of format and left a bare class that matched nothing. The same silent no-op, in
+    the other direction, unreported. Stripping is format-aware now.
+  - **`grid-auto` and the whole `m-*` rhythm family were missing from the tailwind format entirely** —
+    not dropped via `TW_CLASH`, just never re-emitted when `layout.css` is skipped and a subset
+    re-emitted in its place. Unlike the `<bp>-` classes they have no Tailwind equivalent, and unlike a
+    misspelt class the linter cannot flag them, because they aren't anchored to your config. They emit
+    as `@utility` definitions now, keyed to the same `--rhythm-*` variables as the css format.
+
+  Run against this repo's own docs site, the rules found one real instance on the first pass; it is
+  fixed in the same change.
+
+- bf453b0: Maskable favicons are now opaque, so they stop rendering as a logo in a black box.
+
+  `icon-mask.png` is declared `purpose: "maskable"` and `apple-touch-icon.png` is linked on every
+  page. Both sit a deliberately-inset logo on a larger canvas — that inset **is** the maskable safe
+  zone and was always correct — but the canvas was filled with `alpha: 0`. From any transparent
+  source that left 36% of `icon-mask.png` and 40% of `apple-touch-icon.png` transparent, on two files
+  whose entire contract is full bleed: the OS crops them to its own shape and composites the rest onto
+  whatever it likes, usually black. iOS discards alpha on the apple-touch-icon outright.
+
+  `backgroundColor` was already the obvious input for this and already plumbed — as far as the web
+  manifest, and no further. So the raster and the manifest disagreed about the very colour meant to
+  sit behind the icon.
+
+  Now:
+  - those two outputs are composited onto `backgroundColor`, defaulting to `#ffffff` — the same
+    default the manifest's `background_color` already used;
+  - `favicon.svg`, `icon-{16,32,192,512}.png` and `favicon.ico` keep the source's transparency, since
+    none of them is maskable;
+  - a transparent source with no `backgroundColor` set now warns, rather than silently inheriting
+    white — a dark logo would lose against it;
+  - `icon-192`/`icon-512` declare `purpose: "any"` explicitly. Omitting it was legal (unset means
+    "any"), but with a maskable present and nothing claiming "any", some launchers picked the maskable
+    — the one with the safe-zone inset — for slots that wanted a plain icon.
+
+  `vitops favicon` gained `--background <hex>`; it previously had no way to set this at all.
+  `getvitops({ favicon })` and the Vite plugin now forward the option they were already accepting.
+
+### Patch Changes
+
+- bf453b0: Say plainly that `fonts` in `design-system.json` is stacks only and loads nothing.
+
+  The field's description was complete and self-consistent — "raw font stacks by name, emitted as
+  `--font-<name>` tokens" — and told you nothing about where the `@font-face` comes from. Following
+  it literally leads to installing a `@fontsource*` package and importing its CSS in a layout, which
+  renders correctly and silently gives up subsetting, preload, and the `size-adjust` /
+  `ascent-override` fallback metrics: a CLS regression that looks like a working setup.
+
+  The field is unchanged. What changed is that four surfaces now name the boundary and point at the
+  fix — declare the family in Astro's `fonts:` config and point the token at its `cssVariable`:
+  - the `fonts` description in the JSON Schema, and therefore `vitops docs authoring`
+  - `SKILL.md`, which previously never mentioned fonts at all
+  - the generated `tailwind.css` header and its `@theme` fonts comment
+  - the generated `type-tokens.css` header (css format)
+
+- Updated dependencies [4756788]
+- Updated dependencies [bf453b0]
+- Updated dependencies [bf453b0]
+- Updated dependencies [bf453b0]
+- Updated dependencies [bf453b0]
+- Updated dependencies [bf453b0]
+- Updated dependencies [bf453b0]
+- Updated dependencies [bf453b0]
+- Updated dependencies [bf453b0]
+- Updated dependencies [04a51d8]
+- Updated dependencies [bf453b0]
+- Updated dependencies [bf453b0]
+- Updated dependencies [bf453b0]
+- Updated dependencies [bf453b0]
+- Updated dependencies [bf453b0]
+- Updated dependencies [bf453b0]
+- Updated dependencies [bf453b0]
+- Updated dependencies [bf453b0]
+- Updated dependencies [bf453b0]
+  - @getvitops/generator@2.0.0
+  - @getvitops/utils@2.0.0
+
+## 1.0.0
+
+### Major Changes
+
+- bb92a14: **The colour system is rebuilt on a target-prefixed grammar and a shared lightness ladder.**
+  This is a breaking change to every colour token and utility class.
+
+  ## Why
+
+  Two axes shared one class namespace — functional _planes_ (`--<role>-bg-muted`) and
+  appearance-relative _stops_ (`--color-<role>-muted`) — arbitrated by a "plane wins" rule. The
+  result was not a scale. On the shipped palette, light mode:
+
+  | class                              | resolved to  | step                                          |
+  | ---------------------------------- | ------------ | --------------------------------------------- |
+  | `bg-ui-accent-x-muted`             | stop         | 100                                           |
+  | `bg-ui-accent-muted`               | plane        | 100 — identical, so `x-muted` was a dead rung |
+  | `bg-ui-accent`                     | plane        | 50 — _lighter_ than both its "muted" rungs    |
+  | `border-ui-accent-muted` / `-bold` | stop / plane | 300 / 300 — identical                         |
+  | `text-ui-accent-bold`              | stop         | 700 — _lighter_ than `text-…-muted` (800)     |
+
+  Every family was non-monotonic, two had duplicate rungs, and `--color-<role>-muted` was
+  unreachable through any `bg-` class.
+
+  ## The new grammar
+
+  ```
+  --color-<target>-<role>[-<variant>]        target ∈ bg | text | icon | border
+  ```
+
+  The target is **inside** the name, so `bg-danger-muted` and `text-danger-muted` are different
+  tokens and there is nothing left to arbitrate. **The class name is the token name minus
+  `--color-`** — one vocabulary instead of two.
+
+  Variants are ordinal (`xx-muted` < `x-muted` < `muted` < bare < `bold` < `x-bold`) and the
+  tables are sparse: only cells that hold their contrast target exist.
+
+  ## Role kinds
+
+  `colors.roles` values may now be `{ hue, kind }` as well as a bare hue string:
+
+  ```jsonc
+  "roles": {
+    "danger":  "rust",                             // shorthand => chromatic
+    "surface": { "hue": "navy", "kind": "surface" }
+  }
+  ```
+
+  - **`surface`** — a page/panel colour: `bg-<role>` is the card, `bg-<role>-muted` the page
+    behind it, `bg-<role>-x-muted` a well, `bg-<role>-bold` the inverse surface. Full text scale.
+  - **`chromatic`** (default) — a signal colour: tints (`bg-<role>-x-muted`/`-muted`) and solids
+    (`bg-<role>-solid[-bold|-x-bold]`), with **no bare `bg-<role>`** — say how loud you mean.
+    `text-on-<role>` is the guaranteed foreground for the solid family.
+
+  ## Palette generation
+
+  Every ramp now sits on one **fixed lightness ladder** (50 → L 0.98 … 950 → L 0.21); only chroma
+  and hue vary. That is what makes a step mean the same lightness in every hue. Previously each
+  seed transposed the curve, so relative luminance at step 300 ranged from 0.253 to 0.384 across
+  the shipped palette — the same variant read differently depending on the role.
+
+  Authored colours are still reproduced **exactly**. A `seed`, an `anchors` entry or a `tones`
+  value is pinned verbatim at its nearest step; every other step takes the ladder. Snapping brand
+  colours to the ladder was measured and rejected: 11 of 18 real brand hexes moved beyond a
+  just-noticeable difference (worst ΔE-OK 0.050 — Facebook's `#1877F2` → `#0067e1`) and six left
+  sRGB gamut. Deviation is now bounded and local to pinned steps, and warns past ~0.03 L.
+
+  Two tones that claim the same step now **error** instead of one silently overwriting the other;
+  the record form (`tones: { "600": "…", "700": "…" }`) is how you resolve it.
+
+  ## New
+  - **`icon-<role>`** — a non-text tier, so a glyph may run more vivid than text. `icon` is now a
+    default utility family alongside `bg`/`text`/`border`.
+  - **`--color-border-focus`** — the focus-ring tone, taken from `ui-primary`'s solid.
+  - **Contrast is enforced at build time**, not only in tests: text ≥ APCA Lc 75 on its primary
+    background, ≥ 60 on secondary planes, icons and surface boundaries ≥ 45, both appearances.
+    A violation now fails `generate`. Chromatic text is checked against the _surface_ planes it
+    actually sits on, not only its own tints. `text-<role>-x-muted` (placeholder) and `-xx-muted`
+    (disabled) are explicitly exempt; nothing else is.
+
+  ## Migrating
+
+  Rename `--<role>-<suffix>` → `--color-<target>-<role>[-<variant>]`, and the same for classes:
+
+  | before                                  | after                                                            |
+  | --------------------------------------- | ---------------------------------------------------------------- |
+  | `--<role>-bg` / `bg-<role>` (chromatic) | `--color-bg-<role>-x-muted` / `bg-<role>-x-muted`                |
+  | `--<role>-bg-muted`                     | `--color-bg-<role>-muted`                                        |
+  | `--<role>-solid` / `-solid-bold`        | `--color-bg-<role>-solid` / `-solid-bold`                        |
+  | `--<role>-on-solid` / `text-on-<role>`  | `--color-text-on-<role>` (class unchanged)                       |
+  | `--<role>-text` / `-text-muted`         | `--color-text-<role>` / `-muted`                                 |
+  | `--<role>-border` / `-border-bold`      | `--color-border-<role>` / `-bold`                                |
+  | `--color-<role>-muted` (stop)           | judge by use: `--color-bg-<role>-muted` or `--color-text-<role>` |
+
+  **`surface` background names rotate**, value-preserving: what was `--surface-bg` (the page) is
+  now `--color-bg-surface-muted`; what was `--surface-bg-bold` (raised) is now
+  `--color-bg-surface`. Elevation is expressed by which token you reach for — page `bg-muted`,
+  card `bg` — rather than a raised/sunken pair, which is what lets a future surfaces axis flatten
+  it without touching markup.
+
+  `vitops lint` reports role classes that no longer resolve, and now derives its suggestions from
+  what the generator actually emits rather than a hand-maintained list.
+
+### Minor Changes
+
+- bb92a14: Add a fourth output format, `design`, that emits `DESIGN.md` — the agent-facing brief in
+  [google-labs-code/design.md](https://github.com/google-labs-code/design.md) format.
+
+  ```sh
+  vitops generate --format design --out .     # DESIGN.md, and nothing else
+  vitops generate --format css,design         # compose it with a stylesheet
+  ```
+
+  The file is YAML front matter carrying the tokens (`colors`, `typography`, `rounded`,
+  `spacing`, `components`, cross-referenced with `{group.token}`) followed by a prose body
+  carrying the rationale — colour model, fluid scales, layout vocabulary, elevation, shape
+  cascade, component tiers, do's and don'ts. Every section is rendered from your config, so
+  it cannot describe a system the other formats don't build. Point a coding agent, a Figma
+  import, or a designer at this one file when they don't have the toolchain; `vitops docs`
+  remains the richer reference for those who do.
+
+  It is emitted with `--out .` in mind: DESIGN.md conventionally lives at a repo root beside
+  `AGENTS.md`, not in a build directory.
+
+  Three things the spec cannot express, handled the same way every time and explained in the
+  emitted prose so the file is self-describing:
+  - **Fluid `clamp()` sizes** → the maximum (desktop) value, since a spec `Dimension` is a
+    bare number plus px/em/rem.
+  - **Dark mode** → light values only, with the automatic functional flip explained. Role
+    tokens are emitted as `{colors.<hue>-<step>}` references into the raw ramps rather than
+    flattened hexes, so the role → ramp lineage survives the export — flattening them is
+    exactly what breaks dark mode downstream.
+  - **A `50%` radius** → dropped from `rounded` (it is not a `Dimension`) and named in the
+    Shapes prose instead, so nothing is silently lost.
+
+  **New:** an optional `meta` key in `design-system.json` (`{ name, description }`) supplies
+  the brand name and the Overview paragraph. It affects no other format.
+
+  **New:** `StylesheetFormat` (`Exclude<Format, 'design'>`), exported from
+  `@getvitops/generator`. `@getvitops/astro`'s `css.format` now takes that narrower type —
+  `design` produces no stylesheet to inject, so passing it there is a type error rather than
+  a missing-file failure at build time. `vitops lint --format` is likewise restricted to the
+  three CSS formats. No change for anyone already passing `tailwind`, `css` or `bricks`.
+
+- bb92a14: Generate legal documents from your site config
+
+  `vitops legal` renders a privacy policy, terms of service and cookie notice from a site
+  config, in markdown, HTML or EmDash Portable Text:
+
+  ```sh
+  vitops legal --out ./content                 # every enabled document, as markdown
+  vitops legal --doc privacy --format html     # one document, as an HTML fragment
+  ```
+
+  The documents are **derived from your config**, not filled into a form. The analytics
+  provider they name is the one whose ID you set; the personal information they list is what
+  your configured forms actually collect; the countries they name come from the providers you
+  use. So a provider swap updates the policy on the next build, and the fix for a wrong policy
+  is a corrected config — hand-editing the output is overwritten.
+
+  Enable documents under `legal`, which gains the facts the prose asserts:
+
+  ```jsonc
+  {
+    "legal": {
+      "jurisdiction": "ca", // only 'ca' (PIPEDA) ships today
+      "privacyPolicy": {
+        "enabled": true,
+        "lastUpdated": "2026-08-01",
+        "retention": "24 months after our last contact with you",
+        // Third parties the config cannot imply. Analytics, Turnstile and your
+        // deploy platform are detected automatically — list only the rest.
+        "processors": [
+          {
+            "name": "Stripe",
+            "purpose": "payment processing",
+            "country": "the United States",
+          },
+        ],
+      },
+      "termsOfService": { "enabled": true },
+      "cookieConsent": {
+        "enabled": true,
+        "type": "opt-in",
+        "categories": ["Essential", "Analytics"],
+      },
+    },
+  }
+  ```
+
+  Delivery, by stack:
+  - **Any stack** — `vitops legal`. No integration code; prints to stdout without `--out`.
+  - **WordPress/Bricks** — `vitops generate --site <path>` also writes `dist/legal/*.html`, and
+    the theme loader now registers `[vitops_legal doc="privacy"]` to render one in a page. The
+    document updates on the next deploy with no action in WordPress.
+  - **Astro** — `getvitops({ legal: { input: 'site.json', out: 'src/content/legal' } })` writes
+    markdown into a content collection and re-renders when the site config changes. It needs a
+    `css` config (that is what registers the Vite plugin); without one, use the CLI.
+  - **EmDash** — `--format portable-text`, pasted into the admin.
+
+  Also new on the public API: `generateLegal()`, `renderMarkdown()`, `renderNodes()`,
+  `derivePolicyVars()`, `parseMarkdown()` / `toHtmlFragment()` / `toPortableText()`, and
+  `resolvePrivacyContact()`.
+
+  Two things to know before you publish anything this produces:
+  - **It is not legal advice.** Every document opens with a review banner saying so. The
+    bundled terms-of-service prose in particular is generic website boilerplate and
+    deliberately does not cover sales, refunds, subscriptions, accounts or user-generated
+    content — a site doing any of those needs clauses drafted for it.
+  - **It is only as true as your config.** A policy asserting things your site does not do is
+    worse than no policy. Check that the config describes reality before you ship the output.
+
+  `validateSite` now rejects a config that enables a privacy policy without a contact for
+  privacy requests or a `domains.canonical`, since both are interpolated into sentences that
+  would otherwise render blank.
+
+### Patch Changes
+
+- Updated dependencies [bb92a14]
+- Updated dependencies [bb92a14]
+- Updated dependencies [bb92a14]
+- Updated dependencies [bb92a14]
+- Updated dependencies [eeb059f]
+  - @getvitops/generator@1.0.0
+  - @getvitops/utils@1.0.0
+
 ## 0.9.0
 
 ### Minor Changes

package/README.md

@@ -1,7 +1,7 @@
 # @getvitops/cli
 
-CLI for the Vitops design-system generator. Turn a `design-system.json` into Bricks, CSS, or
-Tailwind v4 output.
+CLI for the Vitops design-system generator. Turn a `design-system.json` into Tailwind v4,
+Bricks, `DESIGN.md`, or standalone CSS output.
 
 ```sh
 # scaffold a starter config (stamps a $schema for editor autocomplete)
@@ -17,14 +17,19 @@ npx vitops generate --format bricks,css --out dist
 
 ## Commands
 
-| command                                            | does                                          |
-| -------------------------------------------------- | --------------------------------------------- |
-| `vitops init [--out design-system.json] [--force]` | write a starter config with `$schema`         |
-| `vitops validate <file>`                           | schema-check (non-zero exit on error)         |
-| `vitops generate -i <file> -f <formats> -o <dir>`  | generate `bricks` / `css` / `tailwind` output |
-| `vitops favicon -i <svg\|png> -o <dir>`            | generate a favicon set from a source image    |
-| `vitops agents [-o AGENTS.md] [--docs-dir <dir>]`  | link the agent skill + AGENTS.md pointer      |
-| `vitops docs [topic] [--all]`                      | print live reference docs to stdout           |
+| command                                            | does                                            |
+| -------------------------------------------------- | ----------------------------------------------- |
+| `vitops init [--out design-system.json] [--force]` | write a starter config with `$schema`           |
+| `vitops validate <file>`                           | schema-check (non-zero exit on error)           |
+| `vitops generate -i <file> -f <formats> -o <dir>`  | `tailwind` / `bricks` / `design` / `css` output |
+| `vitops favicon -i <svg\|png> -o <dir>`            | generate a favicon set from a source image      |
+| `vitops agents [-o AGENTS.md] [--docs-dir <dir>]`  | link the agent skill + AGENTS.md pointer        |
+| `vitops docs [topic] [--all]`                      | print live reference docs to stdout             |
+
+Every `--input` takes a `design-system.json` **or** the larger site config that embeds one
+(`company.json` / `site.json`) — told apart by shape, so name the file whatever you like. Add
+`--theme <name>` to build a `designSystem.themes` entry other than the default. `vitops validate`
+routes the same way and checks a site config as a site config.
 
 ## Using the output
 
@@ -80,6 +85,19 @@ The CLI only writes files — how they reach WordPress is up to you:
 - **CI:** run `vitops generate --format bricks` in your pipeline and deploy the artifact the
   same way you deploy the rest of the theme.
 
+**Agent brief (`DESIGN.md`).** `--format design` emits a single `DESIGN.md` and **no CSS** — the
+portable brief in [design.md](https://github.com/google-labs-code/design.md) format (YAML token
+front matter, then prose) for a coding agent or design tool that doesn't have the toolchain
+installed. It conventionally lives at the repo root beside `AGENTS.md`:
+
+```sh
+vitops generate --input design-system.json --format design --out .
+```
+
+`--format` is comma-separated, but a run shares one `--out` — so keep the brief its own invocation
+whenever your stylesheet goes somewhere other than the repo root. Regenerate it with your CSS; it's
+derived from the same config, so it can't drift from what the browser gets.
+
 ## Teaching AI agents (`vitops agents` + `vitops docs`)
 
 This package **ships an agent skill** (`skill/SKILL.md`, the [Agent Skills](https://code.claude.com/docs/en/skills)