design.md for v0 and Lovable: Stay On Brand

Give v0 or Lovable a prompt with no design context and you get their defaults: a blue-violet palette, Inter, generous rounded corners, and a layout that looks like every other generated app. Give them a design.md and the same prompt lands on your brand instead. The setup takes about two minutes per project.

This is the same play as using design.md with Cursor, adapted for two tools that take context differently.

First, have a file worth pasting

You need the design.md before anything else. Write one by hand following the structure guide, or point the Logofai design system generator at your logo and get all twelve sections in about a minute. Either way, check it contains component states and a spacing scale, because those are exactly what these tools improvise when left alone.

Using design.md with v0

v0 has no repository to read at the start of a chat, so the file goes in the conversation. Paste the whole thing as your first message, then prompt normally after that.

Here is our design system. Use these tokens, type scale,
spacing and component specs for everything you build in
this conversation. Do not substitute defaults.

[paste the full design.md]

Two things make this stick. Paste the whole file rather than a summary, because the usage notes per token are what stop it guessing placements. And say do not substitute defaults explicitly: without that instruction v0 tends to blend your palette with its own for anything you did not name.

Once you are generating components, refer back to the file by name in follow-up prompts: build the pricing card using the featured variant from the design system. That keeps later screens anchored to the same source instead of drifting toward the defaults of the model.

Using design.md with Lovable

Lovable works on a project with real files, so treat it the way you would treat Cursor. Add design.md at the project root, then tell Lovable it exists:

my-app/
  design.md
  package.json
  src/

Then in the prompt: read design.md at the project root and follow it for all styling. Referencing the path rather than pasting the content keeps your prompts short and, more usefully, means one edit to the file updates everything you build afterwards.

Lovable also honours the tokens more reliably if you ask it once, early, to set them up as CSS custom properties in the global stylesheet. After that it has a real implementation to reference rather than a document to remember.

Where each one falls short

• Long conversations drift. Both tools weight recent messages more heavily. By the fifteenth screen your tokens are competing with fourteen messages of other instruction. Re-paste or re-reference the file when you start a new area of the app.
• Motion and accessibility get skipped. Colour and type transfer well. Easing curves, durations, focus-visible rings and contrast minimums are usually ignored unless you name them in the prompt for the specific component.
• Dark mode is inconsistent. Even with both palettes defined, generated dark screens tend to use your light tokens on a dark background. Ask explicitly for the dark mode block.
• Neither will tell you it deviated. Check the output against the file rather than trusting it. Build one component with many states early, compare it token by token, and correct the file wherever it allowed a wrong reading.

What to expect

Realistically: palette, typography, radii and spacing land correctly almost every time. Component states land most of the time. Motion, accessibility and dark mode need to be asked for. That still removes the restyling pass that used to follow every generation, which is where the time actually goes.

If you want to see what a complete file looks like before setting this up, there is a full design.md example to copy.

The three tools, side by side

The file itself never changes between them. Only the delivery does, which is the whole reason a single markdown file is a better artefact than a tool-specific config.

When it ignores the file anyway

It happens. Work through these in order rather than rewriting the prompt at random:

• Check the file actually says it. Nine times out of ten the tool did not ignore anything: the value was never specified, or it was specified as an adjective. Search the file for the property that came out wrong.
• Re-anchor the conversation. If you are twenty messages in, the file is competing with everything since. Paste it again, or start a fresh chat for the next area of the app.
• Name the section, not the whole file. Asking it to follow the design system is vague. Asking it to use the button states from section 5 is not.
• Ask for one component, not a page. Whole-page prompts get approximated. A single component with its states gets built properly, and then you can ask for the page.
• Implement the tokens for real. Once the CSS custom properties exist in the codebase, the tool references code rather than recalling a document, and adherence jumps.