Design system

Generated interfaces have to look like your product. Taiga supports that two ways, and the difference in quality between them is large.

Link the repository, or describe the standards

Design Standards is a document: your colors, typography, spacing and component patterns, written down. It is seeded during onboarding, so something sensible is always in place.

A linked design-system repository is the real thing. Agents read your actual components and tokens and build against them, rather than against a description of them.

Link the repository if you have one. A description is an approximation, and the approximation is where generated interfaces stop looking like yours. The standards document still applies until you do, and remains the answer if you have no such repository.

While a repository is linked, products are not offered a Look & Feel document: the repository already settles how the product looks.

Both are set by owners and admins, like the rest of your organization’s governance. Everyone else reads them.

What planning reads from a linked repository

When Taiga plans work, it scans the linked repository for what a UI step can use: the components each package exports, the design tokens it defines, and the guidance it ships for agents. Plan steps are written against that list. A step names the components it uses and the package they come from, and a step that needs something your design system does not have says so and names the tokens it builds from.

Guidance for agents is picked up from the files design systems conventionally ship for it: AGENTS.md, CLAUDE.md, DESIGN.md, llms.txt, SKILL.md files and Cursor rules, at the root of the repository or inside a package. A DESIGN.md or llms.txt at the root is included in every plan, up to a size limit. The other files are listed with their description, and read when a plan touches what they cover.

That makes the repository the place for rules everyone using your design system should follow, such as which of two similar components to reach for. Planning is told to follow guidance about using the design system and to pass over guidance about maintaining it, such as release or commit conventions.

How the standards reach a run

Without a linked repository, every build starts by writing your Design Standards into the generated application: a token stylesheet at src/styles/design-tokens.css, and a DESIGN.md that names your component patterns and tells the coding agent to build against them. Both are drawn from the published standards at the time of the build, so a change to the document reaches the next build without any other step.

With a linked repository, nothing is written: the repository is the only source, and a second set of tokens beside it would drift from the first.

The primary button’s hover is part of the standards, not something each build invents. You can set it as a colour of its own, or point the primary button’s hover at any colour in the palette. The token stylesheet carries it as --primary-hover. If the standards name no hover, Taiga derives one from the primary colour.

Light and dark colours

The standards hold two palettes, one for light and one for dark. When you edit a colour, the change applies to the palette you are viewing. A colour you set for dark applies to the dark theme only. In the Design Standards previews, every dark colour you have not set follows the light palette, so a light edit reaches it too.

Deriving standards from a brand guide

If your brand lives in a document rather than in code, you can upload it. Taiga adapts your design standards to it, applying what the guide specifies and keeping the existing template for anything it does not cover. What comes back is a draft for you to review and publish, and builds read only the published standards, so nothing changes for them until you do. You can stop a derivation while it runs.

Editing is paused while that runs, so the two do not fight over the same document.

A guide that is already in the organization’s knowledge can be picked instead of uploaded again.

One derivation takes up to five files and 50 MB in total. A guide is a document, in PDF, Word, Excel, CSV, HTML, text or Markdown; images are not accepted. A PDF can use the whole 50 MB, and a guide in another format can be up to 10 MB. A large PDF is read in parts, a range of pages at a time, and what each part says is combined into one set of standards. That takes longer than reading a small one. At most 400 pages are read across all the PDFs in one derivation, and Taiga tells you which pages it left out.

The guide you upload is kept as organization knowledge, so it is also there for the work in every factory and product. The standards Taiga derived do not depend on it afterwards. If the guide was only meant as a source for them, you can remove it from the organization’s knowledge and the standards stay as they are.

How a linked design system reaches a run

Worth knowing because it affects build speed rather than correctness.

If your design system publishes packages to a registry, Taiga installs it like any dependency. That is the fast path, with correct versions and complete type information. Registries are connected once, in the organization’s Integrations settings, and serve every product from there.

If no registry serves it, Taiga clones the repository and links it from source instead. This produces the same result and every build is slower.

If you are on the slow path and it bothers you, the fix is connecting a package registry, not changing anything about the design system itself.

When a product should not inherit it

Not every product wants your organization’s design. An imported repository usually arrives with one of its own, and overwriting it is rarely what anyone wanted.

Each product has a Design standards switch in its settings. Products imported from an existing repository start with it off. Products Taiga scaffolds start with it on. Either can be changed at any time, and an explicit choice always wins over the default.

Turning it off stops agents being held to your organization’s tokens. Nothing is deleted: any design files an earlier build wrote stay exactly as they are, and Taiga simply stops updating them.

If the product’s own package.json already depends on your design system, those packages keep resolving. The switch governs what Taiga applies to a product, not what the repository asked for itself, so turning it off never breaks a build.

What this does not do

A linked design system grounds what agents build. It does not enforce it.

Generated interfaces still get reviewed like any other change, and the pull request is where you catch a component used in a way your team would not use it.