Get started

Solution · Design systems

Your brand, locked in one file.

Generate a design system from what you already have, review every component it allows, approve it in a commit, and check that every prototype stays inside it. One JSON document, enforced contrast, no CSS to hand-copy.

Status: available

See it on a sample brandRead the guide
One frosted-lilac glass document card that locks a cluster of themed component cubes into one brand

Lock a brand in a minute.

Try this

  1. Pick a brand input: a brief, a token file or a stylesheet. Read what was dropped or repaired.
  2. Preview the generated brand on real components, in light and dark.
  3. Switch Badge or the ghost button off, and watch the locked check report the finding.
  4. Note the status: draft. Approval is a person and a reviewed commit, not a button here.
1. Pick a brand input

2. The input and its report

Harborline input
name Harborline, brand #0e7490, rounded, calm, comfortable

texuli ds generate --brief "name Harborline, brand #0e7490, rounded, calm, comfortable" -o design-systems/harborline.ds.json

0 dropped values · 1 repair · contrast, focus and target size hold

Repaired

  • $.accessibility.targetMin control height below the 44px target (6 values)

Status: draft. A person approves it with texuli ds approve and a reviewed commit, not here.

3. Preview the Harborline kit

Preview mode

Join the Harborline beta

A sample prototype, built only from catalog components.

New

4. Lock the allowed set

Allowed in this design system

Locked check passed: every component in the prototype is allowed.

The same check runs in CI as texuli ds validate --locked, on your sources and blueprints.

Fictional brands. The drafts were generated when this site was built, and the check runs on a sample prototype, not your app.

See a full kit: Ledgerline

From brand inputs to locked prototypes.

Create: start from a brief, tokens, CSS or a logo.

texuli ds generate merges a short brief, a token file, your site CSS, sampled logo colors or a library theme into one design-system draft. Its report lists every value an importer dropped or a later source overwrote, and every color the contrast solver moved, with the reason. A repair is a brand color that changed: read it before you go on. Agents call ds.generate, which returns a draft and never saves or approves.

  • Import and generate
  • One brand document
A brief card, a token sheet, a CSS sheet and logo swatches flowing into one pearl design system document

Review: see every component it allows, in light and dark.

The texuli/ds-kit page renders the design system in one place: foundations, voice, every allowed component in each allowed variant, size and state, the brand’s own components and the approval record with its hash check. Disallowed values are marked, never rendered. The compiler holds every text pair to AA instead of only reporting it.

  • Compile and apply
A wall of component tiles in a light half and a dark half, reviewed beside one design system card

Approve: a person, a commit, CODEOWNERS.

A reviewer runs texuli ds approve --by <name>. It validates first, then stamps the approval and a content hash. The CLI cannot prove who approved: the guarantee is the reviewed commit, with your design-systems folder owned by your design reviewer in CODEOWNERS. Agents never approve, and texuli ds hash exits 1 when an approved file changed.

  • One brand document
A design system card receiving a check seal while a commit node joins a reviewed branch line

Lock: prototypes use what the brand allows.

The allow section names the catalog components, variants, sizes, tones, densities, category colors and states the brand permits. Every catalog component root carries data-tx-component and its axes, so a check maps a painted page back to the catalog. texuli ds validate --locked --prototype reads your sources and blueprints without running them; --render adds the render check and --report lists findings without failing while you migrate. Your own components join as namespaced catalog extensions with --extensions.

  • Govern components
Component cubes inside a lilac outline passing a check gate while one off-set cube waits outside

Share: hand it over as one versioned bundle.

texuli ds pack packs the document with its library sources and release history. Consumers pin an exact version and move it on purpose; texuli ds diff shows what changed, and a narrower allowed set is a breaking change. The bundle, the allow manifest and the check report each have a published contract type, so other tools can read them.

  • One brand document
A sealed bundle box with a version tag cube travelling along dashed paths to two consumer screens

One document, every surface.

  1. Describe

    The spec defines the design-system document, the allow manifest and the catalog extension format.

    Package: @texuli/spec

  2. Compile

    The compiler turns the document into --tx-* variables for light and dark, with contrast, focus and target size enforced.

    Package: @texuli/tokens

  3. Paint

    Texuli components read those variables; the provider scopes a brand to a page or one element.

    Package: texuli

  4. Check

    texuli ds generates, approves, packs and runs the locked checks on your prototypes.

    Package: @texuli/tools

  5. Hand to agents

    The MCP server gives agents the same ds operations, locally or at texuli.com/mcp. Agents draft and validate; they never approve.

Design systems is built from @texuli/tools, texuli, @texuli/tokens and @texuli/spec, on @texuli/catalog, @texuli/blocks, @texuli/charts, @texuli/media, @texuli/document, @texuli/primitives, @texuli/core, @texuli/deck and @texuli/emojis.

Solution

Design systems

Packages

  • L8@texuli/toolsThe texuli ds command-line toolsSubpaths: .
  • L3texuliSvelte provider and the Ledgerline design-system kitSubpaths: ./design-system · ./ds-kit
  • L2@texuli/tokensCompile, generate, import, apply and emit design-system documentsSubpaths: ./design-system/compile · ./design-system/generate · ./design-system/import · ./design-system/apply · ./design-system/emit
  • L0@texuli/specThe design-system document, schemas and validation contractSubpaths: ./design-system

Built on

  • L6@texuli/catalog (Agent catalog)
  • L5@texuli/blocks (Content blocks)
  • L4@texuli/charts (Charts)
  • L4@texuli/media (Media)
  • L1@texuli/document (Document engine)
  • L1@texuli/primitives (Headless primitives)
  • L0@texuli/core (Texels and the URL policy)
  • L0@texuli/deck (Deck model and engine)
  • L0@texuli/emojis (Unicode emoji catalog and engine)
Five-beat pipeline from a design system card through a compiler cube to components, a check gate and an agent console

Built with Texuli

Built on it: Protoyard.

Protoyard, open-source local prototyping, builds locked prototypes on Texuli. See how it uses Texuli, or visit Protoyard’s own site.

Prototype screens assembled from the same branded cubes inside a lilac outline, editorial not a product screenshot

Build with Design systems

Run the loop from your terminal

Install

pnpm add texuli @texuli/tokens
pnpm add -D @texuli/tools

Create

# 1. Create: a draft and its report (harborline.ds.json.report.json)
texuli ds generate --from-tokens tokens/brand.tokens.json --from-css src/brand.css -o design-systems/harborline.ds.json

Approve

# 3. Approve: a person stamps it, then commits it for the CODEOWNERS review
texuli ds approve design-systems/harborline.ds.json --by "Design reviewer" --version 1.0.0
texuli ds hash design-systems/harborline.ds.json   # exit 1 when an approved file changed

Lock

# 4. Lock: check every prototype against the allowed set (CI)
texuli ds validate design-systems/harborline.ds.json --locked --prototype ./src --json

Share

# 5. Share: one versioned bundle
texuli ds pack design-systems/harborline.ds.json --out dist/harborline-1.0.0.bundle.json

Verified by packages/tools/tests/ds-*-cli.test.ts

Recipes

For agents

Agents call the same operations through the MCP server, locally with npx -y @texuli/mcp or at texuli.com/mcp. They generate and validate drafts. Approval stays with a person.

  • ds.generateds.generate: Available

    Draft a design system from a brief, tokens, CSS or logo colors, with its report.

  • ds.validateds.validate: Available

    Validate a document, or a prototype against its locked allowed set.

  • ds.allowds.allow: Available

    Read or narrow the allowed components, variants, sizes, tones and states.

  • ds.saveds.save: Available

    Save a draft; it refuses an approved document (approval-human-only).

  • ds.bundleds.bundle: Available

    Pack a document with its library sources and release history.

Platforms

How the native renderer works

Questions

Do I need to write CSS?

No. The document is data only. The compiler emits the --tx-* variables and the CSS for light and dark.

Can an agent approve a design system?

No. Agents generate and validate drafts, and ds.save refuses an approved document. Approval is texuli ds approve plus a reviewed commit.

Does “approved” prove who approved?

No. approvedBy is what the reviewer typed. The proof is your review process: the commit and CODEOWNERS.

What does the locked check read?

Your sources, blueprints and CSS, as text, bounded and never executed. --render checks the bundled conformance sheet, or a page you serve and pass with --url; Texuli never starts your app.

We have our own components. Do they fail the check?

Not if you publish them as catalog extensions (<namespace>:<id>) and pass --extensions. The allowed set is then checked against Texuli’s catalog plus yours.

Can I start from tokens we already have?

Yes. texuli ds generate reads a DTCG token file, your CSS and a brief, and its report lists what was dropped or repaired. texuli ds import converts a single DTCG or Tokens Studio file.

Is it stable?

It is pre-1.0. Under 0.x a new minor may break, so pin an exact version. On native, Compose Desktop support is in development and Android and iOS are planned.

  • Slides

    Write decks as JSON or Markdown and present them in the browser.

    Status: in development

  • Documents

    Edit, read, paginate and export block documents.

    Status: in development

  • Workflows

    Author and view workflow graphs inside your app.

    Status: in development

  • Canvas

    An embeddable whiteboard with shapes, connectors and export.

    Status: in development

  • Sheets

    An embeddable spreadsheet with formulas and CSV.

    Status: in development

  • Dashboards

    KPI boards people arrange, from the keyboard too.

    Status: in development

  • Forms

    Schema-driven forms with conditions, steps and drafts.

    Status: in development

  • Agent chat

    A thread whose replies paint validated blueprints.

    Status: in development

  • Rich text editor

    Owned rich text with Markdown in and out, safe paste and export to any chat.

    Status: in development

Start building with Design systems

Carry one brand document across Texuli surfaces.

Read the guideSee the kitOpen the StudioDesign systems referenceFull guide on GitHub
A low horizon of stacked cubes rising to one glowing pearl cube under a wide open skyA low horizon of stacked cubes rising to one glowing pearl cube under a wide open sky