Cline plans before it acts, which I like. It also asks permission for each file change, which means you see mistakes early. What it cannot do is guess your brand colors.
That is a one file fix.
How Cline rules work
Cline reads rules from a .clinerules/ folder in your project root. Every Markdown file inside becomes part of the system context for that workspace.
A single .clinerules file in the root also works. The folder version is better once you have more than one concern to describe, because you can toggle files independently.
The setup
Save DESIGN.md in the repository root, then create .clinerules/design-system.md:
# Design system
This project's visual contract is DESIGN.md in the repository root.
Before you plan or edit any UI work:
1. Read DESIGN.md.
2. Use only its color tokens, spacing scale, radius values, and type styles.
3. Follow its component rules for states, density, and layout.
4. Do not add a font family, shadow, or gradient it does not define.
5. If a value is missing, say so in the plan instead of choosing one.
When you present a plan for UI work, list the DESIGN.md tokens you intend to use.That last line is the one I would not skip. Cline shows you a plan before it edits anything, so asking it to name the tokens turns the plan step into a design review you get for free.
Plan mode is your checkpoint
This is where it gets genuinely useful. In plan mode, Cline describes the change before touching files.
If the plan lists #0061ff for the primary action and your DESIGN.md says #0061ff, you approve in two seconds. If it lists a Tailwind default, you caught the drift before a single line was written.
I have found this catches more design problems than reviewing the diff afterwards, because at plan stage the fix is a sentence rather than a refactor.
Verify it worked
Start a fresh task and ask a factual question:
Which font family and base font size does this project use? Cite your source.The answer should quote DESIGN.md. If Cline says it cannot find design information, check that .clinerules/ is spelled correctly and sits in the workspace root that Cline actually opened.
Common mistakes
- Nesting the folder.
.clinerules/must be at the root of the opened workspace. In a monorepo, that may not be where you think. - Writing a novel. Cline carries these rules on every request. Long rules cost tokens on every single call.
- Ignoring the plan. The plan step only helps if you read it. Skimming past it removes the main advantage Cline has here.
What this means for you
You get two layers of protection: the rules file sets the constraint, and plan mode shows you whether the constraint was understood.
Add the file, pick a documented system from the library as your DESIGN.md, and the next UI task starts from your tokens instead of the model's defaults.