@frontic/ui

Frontic UI

Vue components for commerce storefronts, built for teams where an AI agent writes most of the code.

Agents write components fast and drift while they do it: a hex code here, a 14px there, a slightly different radius on every card. Each file is fine on its own. Together they stop looking like one brand.

Frontic UI takes those decisions out of the component. No colour, size or radius ever sits in a component. The agent decides what the UI does; the colour, type and spacing come from the brand and from nowhere else. Change one token in library/brand.json, run build, and every component in the project follows, including the ones shipped last month.

Every item is accessible by design: keyboard, focus, roles and labels are built in, so what an agent assembles from them meets current regulations without anyone auditing it afterwards.

Start

npx @frontic/ui create my-store        # a new Nuxt or Vite project, MCP and skills set up
npx @frontic/ui init                   # or add Frontic UI to a project you have
npx @frontic/ui add button dialog card # items and the recipes they need
npx @frontic/ui build                  # after you edit brand.json or a recipe file

Use pnpm dlx or bunx instead of npx if that's your runner.

Then give the agent the brand. It has the design-system skill from create or skills; this prompt starts it:

Use the design-system skill to build this project's design system from <your storefront URL, Figma library or codebase>, install the pages that show it, and compare them against the source.

How it holds

Three layers, each one unable to do the next one's job.

Items are Vue files in your repo, one folder each, with their own API. An item wears recipe classes like fui-button-solid. It has no palette class to wear, so there is nothing to drift.

Items are not a dependency. Like shadcn, add copies the source into your project and from then on it is your component. Treat it as a starting point that skips the first eight levels, not a finished thing: remove the variants you don't use, add the ones your design needs today, change the API. Nothing updates underneath you, and diff shows you what the registry has if you ever want to look.

Recipes live in library/recipes/, one JSON file per component holding its recipes by name: card.json holds card, card-header and the other parts, shared/action.json the action family. add brings the recipes an item needs, adds a missing one to its file and keeps one you edited. A recipe says backgroundColor: '{colors.primary}', never #7008e7. It has a base, variant axes and defaults, the shape of the component's cva call; a look for two values together sits under one of them as with, and needs nothing in the component.

Tokens live in library/brand.json: colours by role (primary, muted, buy, promo), text styles (heading, body, small), radius, borders, shadows, breakpoints and fonts. This is the only file where a value like #7008e7 can appear.

build compiles the two files into frontic.css. Tailwind emits only what your templates use.

check holds the project to them. It fails on a class the brand's theme does not define, a colour below contrast and a recipe token the brand lacks, and warns about text written into an item. build prints the same findings as warnings. The check block in components.json sets each rule to error, warn or off and the contrast level to AA or AAA.

Neither file is a format of our own. brand.json follows the W3C Design Tokens (DTCG) specification, so the tokens your design tool exports are the tokens the build reads. DESIGN.md takes its sections from Google's DESIGN.md, the convention agents already know for describing a design system in Markdown. Frontic UI puts shadcn's copy-the-source model, DTCG tokens and DESIGN.md together rather than inventing a fourth thing.

Both files are plain text. Your agent reads and edits them exactly as you do, and a change to the look is a change to one of them, never a class on a component.

Your DESIGN.md

DESIGN.md is meant to become your design system's rulebook: the voice of the brand, how spacing works, when to use buy and when promo, which layouts a product page allows, what a component should never do. Write it the way you'd write it for a new designer. init writes its eight section headings, Overview to Do's and Don'ts; after that it is yours alone. Nothing compiles it: a look is a token in brand.json or a value in a recipe file, and DESIGN.md says when to use it.

The agent reads it before it writes. So when a page needs a component that doesn't exist yet, the agent builds it the way the rest were built: with the same tokens, a new recipe file next to the others, following the rules you wrote. New work lands inside the system, not next to it.

Accessible by design

Items are built on Reka UI, so focus management, keyboard navigation, ARIA roles and labels come with the component. Contrast is a property of the tokens and recipes, checked by check against brand.json rather than once per screen, at AA or AAA. Together that covers each component's share of WCAG 2.2 AA. The page around them is the project's: heading order, alt text, link text, labels and reading order are written where the page is, and check doesn't see them.

Work with an agent

npx @frontic/ui mcp --client claude    # the registry, browsable from your editor
npx @frontic/ui skills --client claude # the rules, the skill that builds a brand from a source, and the review brief

The MCP server lets the agent search items, read an item's API and styling, and get the install command. The skill tells it how to work here: items through their barrels, colour and type through the brand's utilities, changes to the look through the two files. create sets both up; cursor, vscode, codex and opencode are the other clients.

Commands

Icons

Pick a library at init: Lucide, Tabler, Hugeicons, Phosphor or Remix Icon. Items are rewritten to it on install.

See it

Every item, with every variant and state, at ui.frontic.com: the example, the variant matrix, the API, and the tokens and recipes behind it.

Beyond one project

A Frontic account keeps a company's library in one place: the same brand.json, recipe files and DESIGN.md, synced into every project with the frontic CLI. Same files, same rules; only where they live changes.

Built on

shadcn-vue and Reka UI. MIT.