Cline Rules: how to write project rules in .clinerules

If you keep typing "use type hints", "do not touch the legacy folder" and "run the tests after editing" at the start of every Cline task, that is a job for a rules file. Cline rules live in plain markdown files and are added to the context of each task. Below: where to put them, how to word them, and how many tokens they use.

Paths and formats come from the Cline documentation (docs.cline.bot) as of October 18, 2026. The extension UI changes, so check menu names against your own version.

Where rules live

Cline reads rules from several places:

• .clinerules/ or .cline/rules/ in the project root: rules you can commit and share with a team;
• a global folder (~/Documents/Cline/Rules on macOS and Linux, Documents\Cline\Rules on Windows): personal preferences for every project;
• .cursorrules and .windsurfrules files if the repository already has them;
• AGENTS.md in the project root.

When both project and global rules exist, Cline combines them, and project rules win on conflict. Numeric prefixes (01-coding.md) are optional but keep the order readable.

There are two ways to create a file: click the scale icon to the left of the model selector in the Cline panel and create a new rule file, or type /newrule in the chat and go through a short dialogue. You can also simply create .clinerules/coding.md by hand.

How to word rules

The Cline documentation gives a few simple pieces of advice, and they hold up in practice:

1. Be specific. "Use clear names" is useless, "functions and variables in snake_case, classes in PascalCase" can be followed.
2. Put the reason next to the prohibition. "Do not edit legacy/, we delete it in Q2" helps the agent decide edge cases.
3. Point to a reference file instead of describing a pattern: "handle errors like src/utils/errors.py".
4. One file per topic: style, tests, architecture. Any of them can then be switched off with a toggle without deleting it.
5. Keep it short. Rules take space in the context, and stale ones only confuse.

A Python example

File .clinerules/python.md:

## Python: project rules

## Style
- Python 3.12, type hints required in every new function.
- Formatter and linter: ruff. Do not add new dependencies without asking.
- Handle errors the way src/utils/errors.py does.

## Prohibitions
- Do not change files in migrations/ or legacy/ (a separate process generates them).
- Never print secrets or the contents of .env in a reply or in logs.

## Checks after edits
1. `ruff check .`
2. `mypy src`
3. `pytest -q`
If a check fails, fix the cause instead of disabling the check.

The ruff, mypy and pytest commands are an example: substitute the ones your project really uses.

A TypeScript example with a conditional rule

Rules can be bound to paths. Add a YAML paths block at the top, and the rule is active only when matching files are in the context (open tabs, paths mentioned in your message, files Cline edits).

File .clinerules/frontend.md:

---
paths:
  - "src/components/**"
  - "src/hooks/**"
---
## React component rules

- Function components and hooks only.
- Move shared logic into custom hooks.
- Describe props with `type`, no `any`.
- After edits: `npx tsc --noEmit`, then `npm test`.

A rule without a paths block is always active. An empty paths: [] means "never", which is a handy way to disable a file temporarily. The documentation also advises naming paths explicitly in the message: "update src/services/user.ts" triggers more reliably than "update the user service".

Memory Bank and skills

Searches around rules often mention cline memory bank and cline skills. They are related but different.

Memory Bank, according to the Cline documentation, is not a separate feature but a method: a set of markdown files (projectbrief.md, activeContext.md, progress.md and others) that Cline reads at the start of a task, plus an instruction stored in an ordinary rules file. The project description and current state live next to the code, so a new task does not start from zero.

Skills are also written in markdown (SKILL.md in a skill folder such as .cline/skills/), but unlike rules they load on demand: only a short description is always in context, and the full text is pulled in when a request matches. Rules, by contrast, are active all the time. So permanent requirements ("always use types") belong in rules, while rare long instructions ("how to cut a release") fit a skill better.

What rules cost

Rules go into the task context, so you pay for them as input tokens on every agent request. An example with prices as of October 18, 2026.

Say the rule files take 1,500 tokens and Cline makes 40 requests in a task. Formula: 1,500 × 40 = 60,000 input tokens. On claude-sonnet-5-5 (input $0.4 per 1M) that is 60,000 / 1,000,000 × 0.4 = $0.024. On deepseek-v4.1-flash (input $0.013 per 1M) it comes to $0.00078.

If overgrown rules take 8,000 tokens: 8,000 × 40 = 320,000 tokens, which is $0.128 per task on claude-sonnet-5-5 and $0.00416 on deepseek-v4.1-flash. In the OpenAI format, Claude input is billed at the full input price, with no cache discount. The sums are small, but across dozens of tasks a day they add up, and more importantly, excess rules dilute the model's attention. Conditional rules with paths keep frontend instructions out while you work on the backend.

For current prices use GET https://api.zukko.pro/v1/models or the Models page in the dashboard.

Connecting Cline to Zukko

Rules do not depend on the provider, but you need a model. In Cline choose the OpenAI Compatible provider, set Base URL to https://api.zukko.pro/v1, your fetch_... key, and a model id such as claude-sonnet-5-5. Enter the address in full, including /v1: without it requests go to the wrong path and return 404. Step-by-step setup is in the VS Code extensions docs↗, and a longer walkthrough is in Cline: connecting to Claude and GPT with your own key↗. Create the key in the dashboard↗.

A similar approach to instructions is covered in the articles on CLAUDE.md↗ and Cursor rules↗.

FAQ

Cline ignores my rules, what should I check?

Make sure the file is in .clinerules/ or .cline/rules/ and enabled with its toggle in the rules panel. For files with paths, check that the matching paths are in context: name them in your message. If the YAML block is malformed, the documentation says the rule still activates, but with the raw content visible.

Can I keep rules in git?

Yes, project rules are meant for that: commit .clinerules/ and the whole team gets the same requirements. Keep personal preferences in the global folder.

How many rules should I write?

As many as change behavior. If a rule does not affect the result, remove it. One sentence with a reason is usually worth more than a paragraph of general wishes.

Do rules work with any model?

Rules reach the model as text, so technically they work with any model. How closely a particular model follows them, check on your own tasks.

To try it, create a key in the Zukko dashboard, connect it in Cline, and start with one short rules file.