Skip to main content

Design Systems

A design system in RIFT is tokens, a stylesheet, and a component library — versioned like content, enforced at publish, and available to both humans and AI at authoring time.

Anatomy of a design system

  • Tokens — named design decisions (colors, spacing, type, shadows) in the W3C Design Tokens (DTCG) format. Each token is exposed as a CSS custom property in the stylesheet.
  • Stylesheet — one compiled styles.css declaring the tokens as var(--…) custom properties plus all component classes. Published as a static asset alongside your pages.
  • Components — reusable HTML templates with named parameter slots, each with metadata: description, parameters, usage notes, and a worked example shown in the editor's component picker.

The package format

A design system travels as a zip with a fully documented layout:

my-design-system.zip
├── manifest.json        name, semantic version, description
├── tokens.json          DTCG token document
├── styles.css           compiled stylesheet
└── components/
    └── <slug>/
        ├── component.json
        └── template.html

The format is deliberately open — partially standard (DTCG tokens, plain CSS/HTML), partially specified by RIFT (the layout, manifest, and reference syntax). Anything that can emit this zip — a Figma pipeline, Style Dictionary, a script, or RIFT's own generator — can produce a valid design system. You can also export any version from RIFT, edit it by hand, and upload it back as the next version.

Chrome components

Components named exactly header, footer, breadcrumb, main_nav, or left_nav are treated as site chrome: the publisher injects them around every page automatically, feeding them live navigation data. Site-level header/footer HTML set in site settings takes precedence when present.

Versioning and promotion

Every upload or generation becomes an immutable version row. A site renders against the design system's active version; promoting a different version — forward or back — is one click and takes effect on the next publish. The rule that keeps this safe: new versions never rename or remove token names or component slugs that existing content references. The upload gate warns on any identifier that would break, before the version is stored.

The AI generator

You can build a design system in RIFT without ever leaving the app:

  • Create — describe the system in text (optionally with reference files) and generate a complete package: tokens, stylesheet, chrome, and starter components.
  • Update — add a component — the fast path. The AI sees your existing tokens, component slugs, and the stylesheet's actual CSS variables as context, and produces exactly one new component that fits the visual language. Nothing else in the system is touched.
  • Update — styles & tokens — evolve values (palette shifts, spacing changes) while every existing identifier is preserved. Review shows an explicit diff before anything is saved.
  • Full regeneration — a complete overhaul, clearly flagged as the option that may change identifiers.

Validation and auditing

Generated and uploaded packages pass mechanical gates before they can be stored: template slots must be plain substitution the renderer actually supports, worked examples must parse under the real reference syntax, and every var(--…) a component's CSS uses must exist in the stylesheet — the failure mode where a component renders unstyled because a variable doesn't resolve is checked, not hoped against. A one-click audit on the Design Systems page runs the same checks retroactively across every active version.