Cursor

Give Cursor a design system it will hold to.

Cursor is disciplined about code. Tell it your state management convention and it will respect that across fifty files. Tell it to make something “feel premium” and every component arrives with a slightly different idea of what that means.

Why rules files handle code but not design

A .cursorrules file works because engineering conventions are already written in specifics — use this library, never that pattern, put files here. Design conventions usually aren't. “Clean and minimal” survives one component and drifts by the next, because there's nothing in it to check against.

Composer amplifies the drift

Multi-file edits are where it shows. Composer touches eight files at once; without a fixed palette and scale in context, each one gets an independently reasonable answer. You end up with three greys that are nearly the same, two radii, and a button that doesn't match the button one directory over.

Put the design system in the rules file

The thing that makes architecture rules work — concrete values, stated once, always in context — works for design too. It just needs the values to exist first.

snapp produces them from references rather than from a blank page. Save a few sites whose look you want, tag which aspect to take from each, and it writes a guide with real font stacks, hex values and their roles, a spacing scale, radii, and motion timings. Paste that into .cursorrules and every subsequent prompt inherits it — including Composer's.

How to set it up

1. Save three or four sites whose design you'd be happy to be compared to.
2. Tag what to borrow from each — typography here, colour there, motion from a third.
3. Add a note about what you're building so the guide is written for your project rather than in the abstract.
4. Generate, copy, and paste into .cursorrules under a ## Design system heading.

From then on “make this match our design system” is a checkable instruction rather than a hopeful one.