Wuizard for product teams: on-brand UI from every agent

One engineer with an AI agent can drift off-brand. A team of engineers, each with their own agent and their own conversations, drifts faster. Every session starts fresh and makes its own small choices: a new shade of grey, a slightly different radius, another way for a dialog to open. Code review catches logic. It rarely catches a 2 px difference in a corner.

Wuizard puts the design decisions in one place that every agent can read, and gives agents a way to check their own work against it. This page covers how product teams set that up, and the limits you should know about first.

Why drift is worse on a team#

On your own, at least the same person is prompting each time. On a team, the instructions that kept one person's agent in line live in that person's prompt history. A colleague's agent never saw them. Rules files help, but they describe components rather than provide them, and motion is hard to pin down in words, so each agent still writes its own version of the hard parts.

The fix is the same as for any shared standard: one source, kept where the tools look, with a check that runs before review.

Make the sheet match your brand#

A sheet is your product's design system in a form an agent can follow: foundations, slots and rules. For an existing product, start from what you already have:

• Type in the exact values. The sheet's Foundations take your colours, display and body fonts, display weight, radii, spacing unit, shadow style, icon style and motion spring.
• Or extract them. Point Extract at your marketing site or app and it reads colours, type, radii and motion into a starting sheet, which you then correct by hand.
• Choose a component per slot. Pick one primary button, one modal transition, one toast and so on from the live library, all drawn with your values. The app UI patterns topic is a good place to start for product screens.
• Write the house rules. Add short rules the agent follows on every screen, such as "use the project's existing data table". Rules can be switched off without deleting them.

A coherence check warns when a component clashes with the foundations and suggests a swap, and the live preview renders a demo app from your tokens as you edit.

Give every agent the same sheet#

There are two ways to get the sheet in front of your team's agents, and they work well together.

Commit the export#

Export the sheet and commit it. The zip has CLAUDE.md and AGENTS.md, the tokens as CSS variables, JSON, Tailwind v4 and v3 and Swift, every slot's component rendered with your values, slots.json and ATTRIBUTION.md. Many coding agents read a root CLAUDE.md or AGENTS.md automatically, so everyone's agent starts from the same rules, whether or not that person has a Wuizard account.

This has a useful side effect: a design change becomes a pull request. When the sheet changes, the owner exports again and the team reviews the diff to the tokens and components like any other change. The catch is that exported files don't update themselves; someone has to re-export. The export guide shows where each file goes.

Connect over MCP#

Agents connected to the account that owns the sheet read it live. get_sheet returns the foundations and rules, get_slot returns a component with your values, and get_page assembles whole pages from the sheet's section slots. The exported CLAUDE.md tells an agent to use the server when it's connected and the files when it isn't, so the two setups don't conflict. The MCP setup guide covers Claude, Claude Code, Cursor and other clients.

A check before review#

check_ui takes a component an agent wrote and lists where it breaks the sheet: colours, radii, springs, fonts, shadows, spacing or icon strokes outside the foundations, missing reduced-motion handling, and hand-written versions of components that already have a slot. The generated CLAUDE.md asks agents to run it before finishing a screen.

It's a review aid, not a gate. It runs over MCP, so it's available to agents connected to the sheet's account, and each review counts against the plan's allowance (see usage and limits).

Bring designers and product managers in#

Turn on a share link and anyone with it can see the sheet without signing in: a demo app built only from the sheet, the foundations, the component in each slot and the rules agents are told. It's a quick way to agree on a direction before anyone builds a screen, and it shows motion, which static specs rarely do. Links can be turned off or reset at any time.

Beyond the web app#

The same sheet can serve other surfaces. translate_asset returns a slot in Vue, Svelte, SwiftUI or vanilla JS with your values, so a native app can share the web app's foundations. The section.* slots let an agent build marketing pages that match the product, and generate_media makes icons, illustrations and backgrounds in your colours.

Where it doesn't fit yet#

• Shared editing. There are no team roles or shared editing of one sheet today. Plan on a single owner.
• A mature system maintained in code. If designers and engineers already look after a component library your agents use reliably, the sheet adds less. Use it for the gaps, such as motion or marketing pages, or not at all.
• Deep, specialised controls. For data grids, date pickers and similar, keep the library you trust and say so in a rule. Component libraries vs a design sheet covers combining the two.
• Offline or locked-down environments. Live reads need a connection to Wuizard. The committed export works anywhere.

If those limits are fine for your team, the lowest-effort trial is one sheet, one export committed to a branch, and one real screen built by two different people's agents. If the screens match, it's working.