05Design systems

Your design system, used one-to-one.

A design system is the components, tokens and rules a team builds from. Modeinspect works on the one in your codebase: agents place your real React components, the design panel offers your Tailwind theme, and every change ends in a pull request.

01

Your real components

Modeinspect finds your team's React components after setup. Drag them onto the canvas, mention them in chat and edit their props. Agents place the same components too, so new work starts from the system you already have.

The components panel listing the team's own Accordion, Alert, AlertDialog, Attachment and Avatar components with live previews
02

Props, not overrides

Select one of your components in the live app and set its props from the design panel, such as variant, size or disabled, picking from the variants the component already has.

A Button selected in the live app, with its variant prop open on link, default, destructive, secondary, outline and ghost
03

Tokens in the design panel

Select an element in the live app and pick spacing, color and type from your own Tailwind theme instead of raw numbers. Tokens are offered, not enforced: a value that matches no token stays a one-off, in plain sight in the diff.

A selected dashboard card with its fill set to the card token, and the theme's design tokens listed in the design panel
04

Follows your rules

Edit your codebase's design guidelines in Modeinspect, and agents follow them along with your Tailwind theme. The coding agent also reads your repo's CLAUDE.md, AGENTS.md and Claude, Cursor and agent rule files, and saves short rules your team can view and edit.

The design guidelines editor with rules for colors and components next to the codebase's theme tokens
05

Pull request

One click creates a branch, commits the changes and opens a pull request with a written title and description. Each agent change is type-checked first. Engineers review and merge it like any other change. Modeinspect works on Next.js React codebases that use Tailwind.

Opening a pull request from the canvas

Design system guide

How to create a design system that people and AI agents both use

Seven steps to a design system in code, from cutting the catalog to governing how components get used, with the instructions and lint that keep agents on it.

What is a design system?

A design system is the set of design tokens, components and usage guidelines a team builds its interface from. A component library is the components alone. It becomes a system when the tokens and guidelines travel with it.

Read this section in the guide ↗
Why the code has to be the source of truth

Coding agents read the repo, not the Figma library. Figma files, Storybook, generated docs and screenshots are copies that drift, and an agent trusts a stale copy as much as a current one.

Read this section in the guide ↗
Step 1: subtract before you add

Inventory the components the codebase already has, then delete duplicates, one-screen components and decoy folders. Three dropdowns mean an agent picks one of three.

Read this section in the guide ↗
Step 2: turn every design decision into a token

Tokenize color, spacing, radius, type, shadow, motion and breakpoints, and give each token a one-line comment saying what it is for, so an agent picks the right one instead of guessing.

Read this section in the guide ↗
Step 3: build components an agent can pick from the name

Generic names, one typed prop per design decision, className as the escape hatch, every part of a compound component exported with a full example, sizing written down and the variant exposed in the DOM.

Read this section in the guide ↗
Step 4: document behavior, not only looks

Behavioral variants, such as a single or multiple accordion, look identical at rest. Give each one prop on the root, a named example and a line saying when to use it.

Read this section in the guide ↗
Step 5: put instructions next to the code they govern

Four layers: a component index in AGENTS.md, scoped rules for UI files, docs beside each component with when not to use it, and lint for whatever keeps breaking.

Read this section in the guide ↗
Step 6: theme in tokens, never in components

A dark: class on every element is a pair someone forgets. A scale that flips per theme, semantic tokens that point at it and components that use only those tokens keep dark mode in one place.

Read this section in the guide ↗
Step 7: govern the usage, not the definition

Agents edit the component file by default, which changes every screen. Keep props, placement and composition open, enforce the rest with lint, and measure corrections per component usage.

Read this section in the guide ↗
How to prompt an agent against your design system

Name the components to use and where they live, point at an existing usage, and ask for the change rather than the result. Code an MCP server returns is one more copy.

Read this section in the guide ↗
Where Modeinspect fits

Modeinspect works on the design system in your Next.js React codebase that uses Tailwind: your real components, tokens from your theme in the design panel, your repo's rules files and a pull request at the end.

Read this section in the guide ↗

Questions

A design system is the set of design tokens, reusable components and usage guidelines a team builds its product interface from. Nielsen Norman Group calls it "a complete set of standards intended to manage design at scale using reusable components and patterns". In a codebase, the components and tokens live in the repo and the guidelines sit beside them.
A component library is the set of reusable UI components. A design system adds the tokens those components use and the guidelines for when to use each one. The shadcn/ui docs describe their project as "how you build your component library", not a library you install.
For a team that ships with coding agents, start in code. Agents read the repo, so the code is the copy they trust. A Figma library can mirror the code components for exploration, but every copy kept by hand drifts.
Agents use a design system well when component names are generic and each design decision is one typed prop. Export every part of a compound component with a full example, and put "when not to use" guidance next to each component. Add a component index in AGENTS.md, scoped rules for UI files and lint for the rules that keep breaking.
Only for what the code cannot say: voice, tone, intent and when not to use a pattern. A design doc that restates tokens and components is a copy that drifts. Put component guidance in doc comments, and keep a short index in AGENTS.md that points at the code.
No. An agent that works in the repo can read and import the components directly. Storybook's and shadcn's MCP servers help with lookup and installing components, but the code they return is another copy, so the import should still come from the repo.
Put it in tokens. A color scale flips per theme, semantic tokens point at the scale, and components use only the semantic tokens. Ban dark: color utilities inside components with a lint rule, and review changes in both themes.
A variant that looks identical at rest and only differs in use, such as an accordion that allows one or several open panels. Screenshots and static renders cannot show it, so give it one prop on the root, a named example and a line saying when to use it.