Getting your design system into AI-generated code is a two-step problem. First, you need the design system in a machine-readable format — that's what DesignDNA produces. Second, you need to prompt your AI tool in a way that actually enforces it.
Most developers skip the second step. They attach design.md and assume the model will respect it. It won't — not unless you explicitly instruct it to. The prompts below are the ones we use internally and recommend to every team that scans with DesignDNA. Each one is structured to leave the model no room to improvise.
Why Prompt Structure Matters
AI models are trained to be helpful, which means they fill in gaps. If your prompt doesn't specify the border-radius, the model picks one. If it doesn't specify the font weight, the model picks one. Multiply that across a 20-component page, and you have a codebase full of design decisions you never approved.
The solution is a prompt that does three things:
- References the design file explicitly so the model knows where the rules come from
- Lists what's in scope so the model knows what to build
- States the constraints hard so the model knows what it cannot invent
The prompts below follow that pattern. Copy them, attach your DesignDNA output files, and paste them into Claude, Cursor, Windsurf, or any other AI coding tool.
Prompt 1 — Build a Full Page
Use this when you need an entire page assembled from scratch. It's the most common use case and the highest-risk one: the more output the model produces, the more opportunities it has to drift from your spec.
I have attached a DESIGN.md file extracted from a reference website.
Build a complete landing page with:
- Hero section with headline, subheadline, and primary CTA button
- Features grid (3 columns)
- Testimonials section
- Final CTA section
- Footer
Follow the DESIGN.md exactly:
- Use only the colors defined in the colors section
- Apply gradients as full-bleed section backgrounds where specified
- Use the exact border-radius, padding, and spacing values
- Implement every hover state defined in the components section
- Never add box-shadow, gradients, or border-radius values
that are not in the file
Use React and Tailwind CSS.
Do not deviate from the spec. Do not round values.
Do not substitute colors with similar ones.
[Attach: design-system.md]
What this prompt does: The final three "Do not" lines are the most important. Without them, models routinely round 12px border-radius to rounded-xl, substitute hsl(220, 14%, 96%) with gray-100, and invent box-shadow depths. The explicit prohibition removes the model's discretion.
When to use it: New marketing pages, landing pages, or any full-page layout that must match an existing brand exactly.
Files to attach: design-system.md (the DesignDNA output from your reference site)
Prompt 2 — Build a Single Component
Use this when you need one reusable component — a card, a button group, a modal, a data table row — and you want it to be production-ready on the first pass.
Using the attached design-system.md and variables.css,
build a reusable card component in React.
Requirements:
- Use the exact background, border, border-radius,
and padding values from the card component section
- Implement the hover state exactly as specified
(border color shift, transform, shadow if listed)
- Typography inside the card must use the exact
font family, size, weight, and line-height
from the typography section
- Use CSS custom properties from variables.css
(var(--color-primary), var(--spacing-lg), etc.)
Do not hardcode any value that exists as a variable
- Component must accept: title, description, and
optional CTA link as props
If a value is not in the spec: ask me before inventing it.
What this prompt does: The last line — "ask me before inventing it" — is crucial. It shifts the model's default behavior from "fill in the gap" to "surface the gap." This is how you catch the edge cases your design system doesn't cover before they silently accumulate in your codebase.
When to use it: Any time you're building a component that will be reused. Invest the extra specificity upfront; it pays off every time the component is instantiated.
Files to attach: design-system.md + variables.css (both exported from DesignDNA)
Prompt 3 — Migrate an Existing Project to the Design System
Use this when you have an existing codebase with inconsistent, hardcoded styles and you want to bring it into alignment with a real design system — without breaking any functionality.
I have an existing React project with inconsistent styling.
I have attached a complete design system extracted from
our reference website.
Your job:
1. Replace all hardcoded color values in the codebase
with the CSS variables from variables.css
(--color-primary, --color-surface, --color-border, etc.)
2. Replace all hardcoded spacing values with the
spacing tokens from the same file
3. Update all button components to match the exact
specs in the components section of design-system.md
including hover, focus, active, and disabled states
4. Import theme.css into the project entry point
so all Tailwind utilities reflect the design system
5. Flag any component in the existing codebase that
uses a pattern the design system explicitly forbids
(listed in the Don'ts section of design-system.md)
Do not change any functionality.
Only change visual styling to match the spec.
[Attach: design-system.md + variables.css + theme.css]
What this prompt does: The numbered list forces the model to treat this as a structured refactor rather than a rewrite. Step 5 is often overlooked — your design system's "Don'ts" section (if present in your design.md) is a list of anti-patterns. Surfacing violations in the existing codebase gives you a concrete audit trail.
When to use it: Legacy projects, inherited codebases, or projects that predate your design system. Also effective after a brand refresh — attach the new design.md and let the model identify everything that's out of date.
Files to attach: design-system.md + variables.css + theme.css (all three DesignDNA exports)
Tips for All Three Prompts
Be explicit about what the model cannot invent. The weakest prompts say "follow the design system." The strongest ones say "do not use any color, spacing, radius, or shadow value that is not present in the attached file." The difference in output quality is significant.
Use numbered lists for multi-step tasks. Models follow numbered instructions more reliably than prose. If you need five things done, list five things.
Include the constraint in the positive and negative form. "Use var(--color-primary) for all interactive elements" and "Do not hardcode hex or rgb values" say the same thing from different directions — and together they're more reliable than either alone.
For large pages, break the prompt into sections. Build the hero first. Review it. Then build the features section. Smaller, reviewable chunks are easier to catch before they accumulate errors.
Reference the section of the design file, not just the file. Instead of "follow design.md," try "follow the Typography section of design.md for all text styles." Section-level references reduce ambiguity and improve adherence.
Getting the Files
All three prompts assume you have design-system.md, variables.css, and theme.css from DesignDNA. These are generated in 30 seconds by scanning any live website.
Point DesignDNA at your reference site — your production app, your Storybook, your Figma-to-code output, anything with rendered CSS — and it extracts your full visual system into these structured files.
Once you have them, store them in your repo alongside .cursorrules or upload them to Claude Projects. Every AI interaction in your codebase will have your design system as ground truth.
Extract your design system in 30 seconds — scan your site with DesignDNA →