Puckoops design system

Camelot

The components, tokens and rules every Puckoops product is built from — one source for how things look, so a screen in one product reads like a screen in another. Orbit is the first product built on it.

Components
50
Tokens
124
Themes
2

01 — What’s here

02 — Using it

import "@puckoops/camelot/styles.css";
import { Button } from "@puckoops/camelot";

<Button variant="primary">Continue</Button>;

Variants carry the design. Reach for a variant or a component before reaching for a className — the variant is what stays correct when the system changes.

03 — The rules

  1. Colour comes from tokens, never from a literal. No hex, rgb(), hsl() or named colours in product code.

    Every value resolves through tokens.css, so a palette change is one file and dark mode works everywhere.

  2. Chrome is achromatic. The teal, blue, amber and red ramps mean state and appear only inside the system's state components: Chip, the state glyphs of Alert, Toast, HelperText and PriorityMark, and a field's error. Product code never references them.

    State is chromatic and nothing else is, so a coloured pixel always means a state.

  3. Every status carries its frozen glyph: a Chip without glyph is incomplete.

    Desaturate a screenshot and every state must still read from glyph and label alone.

  4. Text sizes come from the type classes (.h1, .h2, .h3, .body, .small, .caption, .caps, .num, .kpi …), never from inline font sizes.

    The scale and its line heights are part of the system; ad-hoc sizes drift.

  5. Every count, amount, date and percentage is set in the mono face with tabular figures (.num, .num-sm, .kpi, Td numeric).

    Columns of numbers line up or the table is wrong.

The full list, with a validator, is on the MCP pages.

04 — Where to start

Open Design tokens → Semantic for the palette, then any component page for its variants. Working with an AI assistant? Point it at the MCP server first; MCP → How to use has the one-line install.