Designing with AI

TEDI can be used as the design system behind AI design tools, so that generated prototypes are built from real TEDI components rather than approximations that have to be rebuilt by hand.

React only. The AI design tools handle React natively and do not support Angular. Everything on this page applies to @tedi-design-system/react.

The source of truth is DESIGN.md in the React repository. It is the machine-readable description of the design system, semantic tokens, TEDI-Ready component rules, guidance on where to look things up, and the detailed setup for both tools below. This page orients you; that file has the specifics and is kept current with the code.

Claude Design

claude.ai/design can host TEDI as a design system.

Setup runs from the React repository, using the /design-sync skill in Claude Code:

git clone https://github.com/TEDI-Design-System/react.git
cd react
nvm use            # Node >= 24, npm >= 11
npm ci

Then, in Claude Code inside the repository, run /design-sync. The skill builds the library and the reference Storybook, converts and grades every component, and uploads the result, there is nothing to configure by hand.

Two things worth knowing before you start:

• Every organisation runs its own project. Design-system projects are org-scoped, so the TEHIK-owned project cannot be shared across an organisation boundary. You create one in your own organisation and refresh it on your own schedule.
• Importing the design system from the repository URL does not work. It produces token-level styling and approximated markup rather than working components, because TEDI's class names are hashed CSS Modules and there is no class contract for an importer to target. Use the sync flow above.

Figma Make

Figma Make consumes TEDI through a Make kit (@make-kits/tedi-kit, published to TEHIK's private Figma npm registry), which installs @tedi-design-system/react from npm.

Make installs packages fresh from npm and does not read the repository. It reads the markdown guidelines bundled in the kit, so changes to DESIGN.md only affect generated output once they are mirrored into those guidelines.

Styling precedence

A generating agent will silently reach for utility classes instead of a component where they are available, and the result looks plausible. The drift only surfaces when someone tries to implement the prototype. In order of preference:

1. A TEDI-Ready component's own props, from @tedi-design-system/react/tedi.
2. A community component, from @tedi-design-system/react/community, only where no TEDI-Ready equivalent exists.
3. TEDI layout primitives: Row / Col, VerticalSpacing, ShowAt / HideAt.
4. Whatever the project already uses for the remainder, driven by real TEDI tokens: semantic roles for colour (var(--general-border-primary)), the dimensions scale for spacing (var(--tedi-dimensions-10)).

Two rules hold whatever the stack: never rebuild something TEDI already provides, and never restyle a TEDI component from outside it. The absence of a prop is a signal that the design is off-system, not a reason to override it.

See also

• Building with AI for the agent skills that build UIs with TEDI in your own application, React and Angular both
• Contributor workflow for the skills used to change TEDI itself