What Wuizard is, and why we built it

Wuizard is a library of live UI and a home for your design system, built so your coding agent can follow it. You choose your colours, fonts and components once. Your agent reads them over MCP whenever it builds a screen, and uses them as they are instead of making up its own.

The short version: if you build with an AI coding agent, Wuizard is how your app stops looking AI-made.

The problem we kept running into#

Coding agents are very good at writing UI that works. What they don't have is any idea what your product should look like. So every screen gets built from the most common choices: a default palette, a medium radius, a soft shadow, the same short fade on everything.

Each choice is reasonable on its own. Together they produce an app that looks like every other app built the same way. And because nothing carries over between sessions, the settings page you built on Monday and the billing page you built on Thursday end up with slightly different buttons.

We tried the obvious fixes. Long style prompts help for a screen or two and then fade out of the conversation. A tokens file fixes colours but not how anything moves. Correcting it by hand defeats the point of having an agent. Why AI-built apps all look the same goes into the causes in more detail.

What we wanted was simple: make the design decisions once, put them somewhere the agent can look them up, and have it use the real components rather than its own guesses. That's Wuizard.

The three parts#

• A live library. Components, animations, page transitions, text effects, backgrounds, colour palettes, type pairings and icon styles. Every one runs on the page, so you see how it moves before you pick it. Each is React, Tailwind and Motion source written to read your design tokens rather than fixed colours. Browse it at the library.
• Sheets. A sheet is one project's design system: foundations (colour, type, radius, spacing, shadows, icons and a motion spring), slots that each hold one chosen component, and short rules. What goes into a design sheet walks through each part.
• An MCP server. Your agent connects to Wuizard once. From then on it can read your sheet, fetch each component with your values already filled in, and check its own code against the sheet. How a coding agent reads your design system shows what that looks like step by step.

How it fits into your work#

1. Start a sheet. Pick a starter vibe, paste the address of a site you like and get its colours, type, corner radii and motion as a starting point (a screenshot gives just its colours), or describe your app to the sheet designer and let it put a sheet together.
2. Make it yours. Swap any slot for another component from the library, change a colour, try a different font pairing, add a rule. The sheet's live preview updates as you go.
3. Connect your agent. Claude, Claude Code and Cursor sign in with your Wuizard account; other MCP clients use a personal API key. The setup guide covers each one.
4. Build as you normally would. Ask for a settings page. The agent reads your sheet, pulls the slotted button, input, toast and transitions, writes the page around them and runs check_ui on what it wrote before it finishes.

When you change your sheet, your agent reads the new version the next time it asks. Changing your accent colour means refreshing one tokens file, not hunting through every screen.

Why components, not just colours#

Most of what makes an app feel generic isn't its colours. It's behaviour: how a button responds to a press, whether a modal scales in or simply appears, how a list fills in, what a loading state looks like. Two apps with the same palette can feel completely different because of motion alone.

So a sheet holds real components, not descriptions of them. Components that move with a spring take the sheet's spring setting, so one value tunes how they all feel. Every slotted component ships a reduced-motion fallback, and the library's rules ask for proper roles, keyboard support and visible focus. Your agent gets all of that by using the slot instead of writing its own.

Why MCP#

MCP (the Model Context Protocol) is an open standard that lets an AI app call tools on a server. Most coding agents support it. Using it means your agent asks Wuizard for the current version of your system each time, instead of relying on a copy that went stale last month.

It also keeps context small. The agent fetches the components the current screen needs, not your whole system in one long prompt. Lookups like reading the sheet, its tokens or a slot are free on every plan.

If you'd rather work from files, you can export a sheet as a zip and commit it. Both routes give your agent the same tokens and the same components.

What Wuizard isn't#

• Not a site builder. It doesn't host or generate your app. Your agent still writes the product; Wuizard decides how it looks and moves.
• Not a package you install. Components arrive as source files in your repo. You own them and can read every line.
• Not a replacement for a mature design system. If your team already has one in code that your agent follows well, keep it. Wuizard is most useful when there isn't one yet, or when the one you have isn't in a form an agent can follow.

Who it's for#

Wuizard suits anyone shipping UI with an AI coding agent who cares how it looks: people building their first product without a designer (vibe-coders), indie developers who want each project to have its own look, agencies that keep one sheet per client, and product teams who want every agent building to one system. A sheet can also be shared as a live, view-only page that anyone with the link can copy into their own account.

If you're weighing it against installing a component library, component libraries vs a design sheet lays out where each one is the better choice.

Where to start#

Browse the library to get a feel for what's there, then start a sheet from whichever route suits you. The docs cover each way in. Once your agent is connected, ask it to call get_sheet and describe your design system back to you. If it can, you're set.