What goes into a design sheet
A design sheet is a design system your coding agent can follow: foundations, one component per slot and a few rules. What each part holds, and why.
The Wuizard team5 min read
On this page
A design system is a set of decisions made once and reused everywhere: these colours, these fonts, this button, this way of opening a modal. A sheet is Wuizard's version of one, shaped for a reader that isn't a person: your coding agent.
That shaping matters. A person can read a style guide, look at a few screens and get the idea. An agent does better with exact values and exact components it can fetch on demand. So a sheet is deliberately concrete. It has three core parts (foundations, slots and rules) and a few extras that build on them.
Foundations: the values everything reads#
Foundations are the small set of values every component uses. In a sheet they cover:
- Colour. Seven roles rather than a long palette: background, surface, foreground, muted text, lines, accent and the colour that sits on the accent. Components ask for a role, never a hex value, which is why a new palette changes everything at once.
- Type. A display face with its weight and letter spacing, and a body face. Pairings in the library set both together.
- Radius. Three steps, small, medium and large, so corners stay consistent without a debate per component.
- Spacing. One base unit. Tailwind's whole spacing scale is built from it, so
p-4means the same thing on every screen. - Shadow. One style (none, soft, crisp, hard offset or glow) drawn at three depths:
shadow-sm,shadow-mdandshadow-lg. - Icons. Stroke width, size, round or square line ends, and how a standalone icon is framed.
- Motion. One spring, set by stiffness and damping. Components that move with a spring take this value, so a sheet feels snappy, soft or bouncy as a whole.
Your agent gets the foundations as CSS variables, a Tailwind v4 theme, a Tailwind v3 config, JSON or a SwiftUI file. Here is the full CSS for a sheet started from the Studio vibe:
:root {
--color-bg: #f6f5f1;
--color-surface: #ffffff;
--color-fg: #141416;
--color-muted: #6b6b74;
--color-line: #e4e2dc;
--color-accent: #2f5bff;
--color-accent-fg: #ffffff;
--radius-sm: 6px;
--radius-md: 10px;
--radius-lg: 16px;
--font-display: "Inter", ui-sans-serif, system-ui, sans-serif;
--font-body: "Inter", ui-sans-serif, system-ui, sans-serif;
--spacing: 4px;
--shadow-sm: 0 1px 2px 0 rgb(0 0 0 / 0.06);
--shadow-md: 0 4px 16px -4px rgb(0 0 0 / 0.12);
--shadow-lg: 0 20px 48px -16px rgb(0 0 0 / 0.2);
--icon-stroke: 1.75;
--icon-size: 20px;
--spring-stiffness: 380;
--spring-damping: 30;
}That's the whole visual vocabulary. Anything outside it is, by definition, off-system, which makes it easy to check.
Slots: one chosen component per job#
Tokens alone leave the agent to write every component itself, and that's where the default look creeps back in. Slots close that gap. A slot is a named job in the interface, such as button.primary, input.text, transition.modal, transition.page, feedback.toast or loader, and it holds exactly one component you chose from the library.
Every new sheet starts with those six. You can fill more as you need them, grouped the way you'd think about an app: buttons and controls, inputs and forms, navigation, motion and overlays, feedback and loading, and content and effects such as headline animations, hover effects and backgrounds.
The point of a slot is that the agent never has to choose. When it needs a toast, it doesn't write one or pick from several; it asks for feedback.toast and gets yours, with your values already filled in. Every slotted component reads the foundations through CSS variables, ships a reduced-motion fallback, and has its tunable numbers (a duration, a starting scale, a blur) written into a small block near the top of the file.
A few library items aren't slotted because they belong to the foundations: adding a colour palette replaces the sheet's colours, a type pairing replaces its fonts, and an icon style replaces its icon settings.
Keeping slots coherent#
Mixing components from different moods is the fastest way to make an app feel stitched together. Each sheet has a vibe, and a coherence check warns when a slotted component clashes with it (a very bouncy component in a strict editorial sheet, for example) and suggests a swap that fits. The vibe pages show what each mood looks like in practice.
Rules: the short instructions#
Some decisions aren't values or components. They're habits. Rules are short sentences the agent follows on every screen. Every sheet starts with four:
- Never introduce colours outside the sheet's foundations.
- For any UI listed in slots, use the slot asset instead of writing a new one.
- Respect prefers-reduced-motion using each asset's fallback.
- If something isn't in the sheet, search the library and ask before adding it.
You can switch any of them off, delete them, or add your own on the sheet's Rules tab. Good rules are specific and checkable, like "use sentence case for every label" or "one primary button per screen". Vague ones like "keep it clean" give the agent nothing to act on.
Sections and whole pages#
Section slots (section.hero, section.features, section.pricing, section.faq, section.cta, section.footer and others) work like any slot, with one extra: once the required sections are filled, your agent can ask for a whole page. A landing, pricing, about, contact, blog, features, changelog, careers or not-found page comes back as one file that imports each section in a sensible order. Sections ship with neutral placeholder copy, so nothing on the page claims a price or a customer you don't have. The docs explain how readiness works, and the landing sections topic shows the components.
Media made in your colours#
A sheet can also hold images and short animations made for it: app icons, logo marks, illustrations, photos, backgrounds and realistic UI screenshots, all in the sheet's colours. They're saved to the sheet, so your agent can list them and download the files into the project instead of reaching for stock images.
CLAUDE.md: the sheet in words#
From all of the above, Wuizard writes a CLAUDE.md: plain instructions for building in your project, followed by the foundations, the slots and your rules. You can read it on the sheet's CLAUDE.md tab. It's what the agent reads when it can't call the server, so it's included in the export (with an AGENTS.md copy for agents that look for that name), and it's available over MCP as a resource for clients that keep standing context.
What a sheet leaves out#
A sheet decides how your product looks and moves. It doesn't decide what your product does. Layout of a specific screen, your copy, your data and your business logic stay with you and your agent. The agent composes screens from your slotted pieces; the sheet makes sure the pieces are always yours.
It also isn't fixed. Change the accent colour, swap the page transition, add a rule: the next time your agent reads the sheet, it gets the new version.
Ways to start one#
- From a vibe. Starter sheets come with colours, type, motion and a component in each starter slot that fits the mood.
- From a website or screenshot. From a website, Wuizard reads the colours, type, corner radii and motion and matches them to library components. A screenshot gives the colours, and the rest starts from the closest vibe. It copies values, never code.
- From a description. Tell the sheet designer what you're building and it creates a sheet, showing each change as it makes it.
- From the library. Collect components as you browse and fill slots one at a time.
However you start, everything above is editable. To see how an agent actually uses all this while it builds, read how a coding agent reads your design system over MCP. For the bigger picture, start with what Wuizard is.
In the library