The payoff for a good run isn't the file — it's the system underneath. A finished project can save as a design system: the tokens, components and rules the work produced, carried into the next project so your taste accumulates instead of resetting each time. You can also build a system directly from sources you already have — screenshots, PDFs, exported tokens, code — with Create design system.
What gets saved
A saved system is a complete package, described by its design-system.json
manifest. Saving carries all of it, not just tokens and rules:
- Tokens —
tokens.cssandtokens.json: the colors, type scale, spacing and radii the project settled - Components and documentation —
components.htmland the component inventory the work produced - Rules —
DESIGN.md, the brief the agent reads when it builds with the system - Fonts and assets — logos, font files and their licenses
- Exports and reports — generated code files and verification reports, when the system has them
Private working files stay behind: attachments you added to the project and
anything under .1design/ are not copied into the package. A package needs at
least tokens.css and DESIGN.md; projects from older releases that keep
those under css/design-system/ and .1design/context/ still save.
Saving one
Open Systems from the top bar with the project you want to keep open, then
click Save project name as a system. It lands in the Design systems
list alongside your other saved and imported systems. The system takes the
name from the project's own design-system.json if it wrote one, otherwise
from the project title — so a title that describes the aesthetic ("quiet
editorial dark", not "launch page v2") pays off here, because it's the system
you'll reuse, not the artifact.
If the project was built with a saved system, saving again updates that system rather than creating a new one. The update replaces the package as a whole: the new version is staged and validated first, and the previous one is kept as a revision rather than overwritten in place.
Export the system a finished design already is
Saving a project carries the package the work produced. Since 1.13.0 there is a second route, for a design that never wrote one: the preview's Share / export menu offers Design system (tokens + DESIGN.md), which reads the rendered page rather than the project's files.
It serves the page the way the preview serves it — so its stylesheets, fonts
and images resolve — then measures what the browser draws: palette, type,
radii, shadow and motion. From those measurements it writes tokens.css,
tokens.json, a measured direction.json, DESIGN.md, components.html,
design-system.json, a thumbnail of the frame it measured, and a reports/
folder holding the raw numbers, the capture contract and the structure it
observed. Running tokens.mjs --direction direction.json regenerates both
token files from that direction.
The measurement and the token builder are the kit's own, the same ones
extract-style.mjs and tokens.mjs use, so an extracted package and a token
run can't disagree about the same page.
What an extraction won't claim
A rendered page shows colour, type, geometry and depth, and nothing about intent. The package is explicit about that line rather than papering over it:
- No component inventory. Variants, states and token bindings can't be
recovered from rendered output, so no
components.jsonships.components.htmllists the landmarks and repeated class names observed in the source, and labels them as structure. - The editorial fields describe the measurements. The mood is three
measured words and the signature is a measured hex and pixel value —
DESIGN.md, the manifest notes anddesign-system.jsoneach record that. - Contrast repairs are named. Where a measured colour fails contrast,
tokens.cssships the repaired value rather than the page's, and every repair is listed at the end ofDESIGN.md.
It is a metered render, and it is refused on codebase projects, where the design lives behind your own dev server and Build mode's Tokens tab is the equivalent surface.
Create a design system from your sources
Create design system starts a project on the Design system template. The composer prefills Create a design system: — describe what you want and attach what you have: screenshots, PDFs, exported tokens, Figma content, or a linked code repo (read-only). Instead of fitting your material to one of the preset directions, the agent reconstructs the system from the sources themselves.
Sources and roles
Each source is recorded with a role:
- Design reference — the design the system is rebuilt from; its palette, type and components are the evidence
- Desired-output example — shows how you want the documentation organized; it never overrides the reference's colors
- Supplement — extra material that fills gaps
Each source is also marked as inspected, partial or unsupported, with the reason when something couldn't be read. If the agent you're running can't inspect images, it's told so up front: image sources are marked unsupported and the system is built from the text and structured sources you gave it, rather than from guessed visual observations.
Provenance
Every foundation value and component property records where it came from:
- extracted — read from structured data such as tokens or code
- observed — seen in an image or PDF
- inferred — a rule deduced from the evidence
- extended — added to complete the system, and labeled as an addition
- unknown — not recoverable from what you supplied
A single cover image yields a faithful system with its extensions labeled. It won't claim Figma pages it never saw, or a component count the reference didn't show. By default a broad request produces a reconstruction with labeled extensions; ask for originals only and you get a faithful reconstruction that leaves extensions out.
What the package contains
The result is a complete package generated from one set of canonical token data:
- Canonical tokens and foundations —
tokens.json,tokens.css, and per-value provenance - Components — each with variants, states and its source evidence
- Interactive documentation —
components.html, with Search components, tokens or values, an All platforms filter (iOS, Android), a theme selector when the system has modes, and Copy markup / Copy token buttons - Copyable code — CSS, tokens JSON, a Tailwind v3 config, and Swift and Kotlin token tables, each with Copy code and Download file
Because every export comes from the same token data, the code tabs and the
downloaded files can't drift apart. The Swift and Kotlin files are literal
token tables, not native components, and the Tailwind config expects
tokens.css to be loaded alongside it.
Verification
Verification is part of the gate. Before a reconstructed system publishes, its structure, exports and rendered documentation are checked. The result is pass, partial or fail: a failing package won't publish until it's repaired, and a partial one stays marked partial after it's saved — it never turns into a verified claim.
In Systems, a reconstructed system shows a Source reconstruction card with its scope profile, its mode (Faithful reconstruction or Reconstruction with labeled extensions), the verification status, and one line for each check that didn't pass. Checks that weren't run — native compilation, for example — are listed as not run rather than counted as passing.
Using one
At the next project creation, pick the system from the design-system picker under Your systems — the new build starts from its tokens and components instead of a blank direction or a generic default. To add a system to a project that's already open, select it in Systems and click Apply to project name.
Applying installs the whole package into the project's ds/ folder — tokens,
components, documentation, fonts and assets — and records the package's
version on the project, so you can tell which revision a project was built
with. The system shapes the first build the same way a direction would, except
the taste is yours: the second project inherits what the first one learned.
The free tier caps saved systems at 3; Pro is unlimited. Moving one to the Trash from Systems frees the slot.
The direction a system publishes
When a system's tokens.css uses the kit's token names (--color-*,
--font-*), saving or importing it also publishes a matching ds-<id>
direction, so its palette and fonts show in the pickers. If those tokens point
at aliases such as var(--ds-brand), the aliases are resolved to real values
first — a circular alias is dropped rather than published. Reconstructed
systems don't publish a separate direction: they're applied as complete
packages, so their generated CSS stays exactly as built.
What it's good at
- Product consistency — every project starts from the same real system
- Brand carry-over — a brand board's tokens become the next site's seeds
- Rebuilding what exists — screenshots or a codebase become a documented system with its evidence attached
- Taste accumulation — the kit learns what you keep, project over project
- A team language — the shared system everyone builds from
Systems vs directions vs templates
- Saved system — your aesthetic, distilled from a finished project or reconstructed from your sources
- Direction — a built-in starting aesthetic, one of 17
- Template — the output format (slides, site, mobile), not the style
A direction is a fast start; a saved system is a fast yours start.
Tip: Save the system from a project you're proud of early — the second project inherits it, and the taste compounds from then on instead of starting cold each time. When you create one from sources, read the Source reconstruction card before you apply it: it tells you which checks didn't pass.