wonderblok
Get early access

Give your coding agent a design to follow.

If you build with a coding agent and the UI keeps drifting, the missing piece is a design the agent can read. Wonderblok is a design file your agent edits over MCP, with tokens, components and written rules it must read before every edit, so each screen stays consistent with the last.

Get early accessSee pricing
TokensComponentsGuidelinesChange history

WHO THIS IS FOR

Sound familiar?

You describe a screen, the agent builds it, and it looks fine. Ten screens later nothing matches: three kinds of buttons, five grays, spacing that changes by the hour. The agent is not careless. It simply has no source of truth for how your product looks.

Wonderblok is that source of truth. Colors, type and spacing live as tokens. Components are drawn once. Written guidelines sit in the file, and the agent has to read their current version before it may edit anything. Your prompts get shorter because the rules no longer live in them.

  • Every screen looks a little different

    Without shared tokens and components the agent re-invents the style each time.

  • Rules live in a long prompt

    A style guide pasted into every chat gets forgotten, truncated or contradicted.

  • You cannot see what the agent changed

    Edits land in code with no place to review them as design.

AN EXAMPLE WEEK

From ten screens that do not match to one system, in a week

A scenario, not a customer story: what a week can look like when your agent works on the canvas with you.

  1. Monday

    You write down what you keep repeating

    You are building a habit tracker with Claude Code. The app works, but every prompt starts with the same paragraph about spacing, buttons and tone. You paste that paragraph into the file's guidelines once, in six short lines. The next prompt starts without it.

  2. Tuesday

    The grays become tokens

    You ask the agent to list every color and spacing value in the frames you already have. There are five grays and four paddings that almost match. You keep one gray and two paddings, name them, and have the agent replace the rest with the nearest token.

  3. Wednesday

    New screens come from components

    You need a billing screen. You ask the agent to read the guidelines, then build it from existing components and tokens only, and to tell you what it could not match. It comes back with a finished screen and one honest note: there is no component for a plan comparison row.

  4. Thursday

    You change a rule, the agent has to catch up

    You decide cards get a larger corner radius. You update the guidelines. The next edit the agent tries is refused until it has read the new version. It reads, applies the change to the card component, and every screen that uses the card follows.

  5. Friday

    You review like a designer

    You open the change history and go through what the agent touched this week. You keep most of it, revert one spacing change on the profile screen, and leave a note on a button that feels too small. The agent fixes it and says what it changed.

  6. Next week

    The code follows the design

    You set code names on the components to match your React names and point your coding agent at the design file. It builds the next screen from the frame instead of from your description. When the app runs, a build check lists where it differs from the design.

BEFORE AND AFTER

What changes once your agent has a canvas.

WITHOUT A DESIGN FILE

  • Every screen looks a little different, because the agent re-invents buttons and spacing each time.
  • Your style rules live in a long prompt that gets truncated, forgotten or contradicted.
  • You find out what the agent changed by reading code, and you only see the visual result after you run the app.
  • A new color or a new corner radius means asking for edits screen by screen.
  • Accessibility problems like low contrast and tiny touch targets surface when a user complains.

WITH WONDERBLOK

  • Colors, type and spacing are tokens, and the agent uses them instead of inventing values.
  • Your rules are written once in the file. The agent must read the current version before it may edit.
  • Changes land on a canvas you can look at, with a history you can keep or revert.
  • One change to a token or a component reaches every screen that uses it.
  • Contrast and touch-target problems are listed per screen before you build.

HOW IT WORKS

Vibe coders: the workflow, step by step.

Each step shows what you ask for, what you get, and the features behind it.

  1. 01

    Connect your agent

    Wonderblok sets up the MCP connection for Claude Code, Codex and Claude Desktop. From then on your agent can read the file and edit frames, text, components and tokens. The file stays on your device.

    MCPLocal files

    You get: Your agent can see the design and change it.

  2. 02

    Turn the values you use into tokens

    Start with what already exists. Ask the agent to find the colors, type sizes and spacing in use, then decide which to keep. Name them once. Tokens can carry a value for light and for dark mode.

    Tokens and modesMCP

    YOU SAY

    List every color and spacing value used in the Settings frame that is not a token. Group near-duplicates and suggest one token for each group.

    You get: A short list of tokens that replaces a pile of one-off values.

  3. 03

    Write the rules in the file

    Put the sentences you paste into every chat into the guidelines instead: how dense the screens are, which button to use for the main action, what tone the copy has. The agent gets the current guidelines and a hash of them, and edits are refused until it has read that version.

    GuidelinesRead-before-edit

    YOU SAY

    Read the design guidelines. Then tell me which of them your last three edits did not follow.

    You get: A rulebook that is applied without being repeated.

  4. 04

    Draw each piece once, as a component

    Buttons, inputs, cards and list rows become components with variants for size and state. Once they exist, new screens are assembled from them, and the style lives in one place.

    Components and variantsFrames and auto layout

    YOU SAY

    Turn the primary button on the Home frame into a component with variants for default, pressed, disabled and loading. Use only existing tokens.

    You get: Pieces your agent reuses instead of redrawing.

  5. 05

    Ask for screens that use only what exists

    Now you can ask for a new screen and add a constraint: use the tokens and components that are already in the file, and report anything you could not match. The report is the useful part. It shows where your system has a gap.

    GuidelinesComponentsTokens

    YOU SAY

    Read the design guidelines, then add a billing screen using only my tokens and existing components. Tell me what you could not match.

    You get: A screen on brand, plus a list of missing pieces.

  6. 06

    Check the screen before you build

    Run the checks on a frame to catch low contrast and small touch targets. Ask the agent to fix what is listed and to say what it changed.

    LintChange history

    YOU SAY

    Check the Checkout frame for contrast and touch-target problems and fix what you find. List each fix.

    You get: Lint results per screen, and fixes you can review.

  7. 07

    Review what changed, then build from the design

    Open the change history to see what the agent did since you last looked. Keep it or revert it layer by layer. When the screens are right, set code names so components and tokens match your code, and have your coding agent build from the file. Build checks compare the running app with the frames.

    Change historyCode namesBuild checks

    YOU SAY

    Set the code names for the Billing components to my React component names, then build the screen from the frame.

    You get: You stay in control of the agent, and the code starts from the design.

USE CASES

Six jobs you can hand to your agent this week.

  • A new screen that matches the rest

    You need a billing screen and you do not want a fourth kind of card.

    PROMPT Read the design guidelines, then add a billing screen using only my tokens and existing components. Tell me what you could not match.

    Result: A finished frame built from your system, with a short list of anything that was missing.

    GuidelinesComponentsTokens

  • Clean up screens that drifted

    Ten screens in, there are five grays and spacing that changes from screen to screen.

    PROMPT Replace every color and spacing value in the Home, Settings and Profile frames that is not a token with the nearest token, and list each replacement.

    Result: Screens that agree with each other, and a list you can scan for anything that looks wrong.

    TokensChange history

  • Contrast and touch targets

    The app looks fine on your monitor. You have not checked it the way a tired user on a phone would.

    PROMPT Check the Checkout frame for contrast and touch-target problems and fix what you find. List each fix.

    Result: Lint results for the screen, with the fixes applied so you can review them.

    LintChange history

  • Dark mode without a second set of screens

    Users ask for dark mode, and your agent would happily duplicate every screen to give it to them.

    PROMPT Give the color tokens a dark value, then show the Home and Settings frames in dark mode and list any text that fails contrast.

    Result: Dark mode from the same screens, driven by token values.

    Tokens and modesLint

  • A feature built on a proven pattern

    You are adding onboarding for a feature, and you would rather start from something that works than from a prompt.

    PROMPT Add the permission priming pattern from Universe for notifications and restyle it with my tokens and my copy.

    Result: A pattern from shipped apps, in your brand, as editable frames.

    Universe (Pro)Tokens

  • Hand the design to your coding agent

    You have a screen you like. You want the code to match it instead of approximating a description.

    PROMPT Set the code names for the Billing components to my React component names, then build the screen from the frame.

    Result: Code that starts from the frame, and a build check that lists where the running app differs.

    Code namesBuild checks

WHAT TO LOOK AT

The features that matter most to you.

  • MCP connection

    Your coding agent works on the design file directly, so decisions stop living in pasted prompts.

  • Guidelines the agent must read

    Your rules are applied without repeating them, and outdated rules cannot be used by accident.

  • Tokens with light and dark modes

    A color change or a dark mode is a value change. The agent uses the value instead of making one up.

  • Components and variants

    A button drawn once is the same button on every screen, in every state.

  • Frames with auto layout

    Screens resize and reflow like the real thing, so the design is a fair preview of the build.

  • Lint checks

    Low contrast and small touch targets are listed per screen before you build.

  • Change history and revert

    An agent edits fast. History shows what changed since you last looked, and you can undo any of it.

  • Notes on layers

    When something feels off, leave a note on that layer. The agent acts on it and reports what it did.

  • Code names and build checks

    The design and the code share names, and the running app is compared with the frames.

  • Universe patterns

    Start a new flow from a structure proven in shipped apps instead of a blank prompt. Part of Pro.

QUESTIONS

Straight answers.

Why does my AI-built UI look inconsistent?

Because the agent has no shared source of truth. It invents spacing, colors and components per screen. Tokens, reusable components and written rules in a file the agent must read fix the cause.

How does the agent know my design rules?

Wonderblok gives the agent a guidelines document and a hash of it. Edits are refused until the agent has read the current version, so old rules cannot be used by accident.

Which agents work with it?

Any agent that speaks MCP: Claude Code, Codex and Claude Desktop are supported, and the app sets up the connection for you.

Can I undo what the agent did?

Yes. Wonderblok keeps a change history per layer, so you can see what changed since you last looked and revert it.

Is the Free plan enough to try this?

Free includes 100 MCP calls a week. That is enough to set up tokens, write your rules and have the agent build a screen or two from them. Working through a whole app with an agent will use more, which is what Pro and its much higher limit are for.

Will my coding agent still ignore the design?

The rules apply to edits made in the design file: the agent has to read the current guidelines first. In your code, the agent is only as consistent as the design it builds from. That is why component and token names match your code and why build checks compare the running app with the frames.

I already have a half-built app. Can I start from it?

Yes. Start with the tokens and the two or three components you reuse most, then ask the agent to extend them. Wonderblok can also bring web pages in as frames, and anything without an equivalent is listed after the import.

HONEST LIMITS

What to know before you start.

  • Wonderblok runs on macOS today. Windows, Linux and Android and iOS tablets are coming soon.
  • Wonderblok does not write your app's code. Your agent does, using the names and values in the design.

ALSO FOR

More in Build a product and every other group on the Solutions page.

Try it on one real job.

Download for macOS and start on Free. Windows, Linux and tablets are coming soon. No card needed.

Get early accessSee pricing