Continue is the tool people reach for when they want to pick their own model. That flexibility is the point, and it creates a specific problem: every model has different default taste.
A rules file makes the output consistent regardless of which model you swapped in this week.
Where rules live
Continue reads project rules from .continue/rules/ in your workspace. Each file is Markdown with optional front matter.
You can also define rules inline in config.yaml under a rules key. Older setups used .continuerc.json, and it still loads in many versions, but the rules directory is the current shape and it is easier to review in a pull request.
The setup
Save DESIGN.md in your repository root, then create .continue/rules/design-system.md:
---
name: Design system
alwaysApply: true
---
The visual contract for this project is DESIGN.md in the repository root.
Read it before writing or editing any UI code.
- Use only the color tokens, spacing scale, radius values, and type styles it defines.
- Follow its component rules for states, density, and layout.
- Do not introduce a font family, shadow, or gradient it does not define.
- If a value is missing from DESIGN.md, say so instead of picking one.With alwaysApply: true, the rule joins the system message on every request, so it survives model switches.
Scoping with globs
For a repo where UI is a subset of the code, attach the rule to the files that need it:
---
name: Design system
globs: "src/**/*.{tsx,jsx,css}"
---This is worth doing if you run a local model with a small context window. Every token you do not spend on rules is a token available for the actual code.
Verify it worked
Open a new chat and ask for something specific:
Give me the exact hex value for the primary action color in this project.The right value means the rule is live. A generic answer means it is not, and the usual cause is a typo in the folder name or invalid front matter.
If you use several models, run the same check after switching. Rules apply per request, so a working setup should behave identically across providers.
Common mistakes
- Assuming autocomplete follows rules. Chat and edit modes use them reliably. Inline completion is a different code path and is far less predictable, so review UI completions.
- Keeping both `.continuerc.json` and `.continue/rules/`. Pick one, or you will spend an afternoon debugging which one won.
- Very long rules on small local models. A 7B model with a 4K window cannot hold your design system and your file. Trim the contract or scope it.
What this means for you
Continue's strength is choice. The cost of choice is inconsistency, and a rules file is the cheapest way to buy the consistency back.
Set it once, and Claude, GPT, or a local Qwen all produce UI in the same visual language. Pick a documented system from the library if you need a DESIGN.md to start from.