How to Write .clinerules That Keep Smaller Open Models on Track

Yes: good .clinerules can make a smaller open model noticeably more useful in Cline, especially on familiar repo work. No: they won’t turn a 7B or 14B model into a model that can safely infer your architecture from three vague sentences; the job is to remove choices before the model has to make them.

The rule of thumb is simple: write down the decisions you would otherwise correct in review, but only in the form needed to make the next action obvious. Smaller models tend to drift when a rule says “follow our conventions”; they do much better when it says which file to inspect, which command to run, what a passing result looks like, and when to stop and ask.

Start with one always-on file that is deliberately boring

Put the smallest set of cross-cutting constraints in an always-active workspace rule, committed at .clinerules/00-project.md. Cline combines workspace rules with global rules, and workspace instructions win when they conflict. Rules are injected into the task context, so a 900-line “engineering handbook” costs attention on every request whether the current task needs it or not.

# .clinerules/00-project.md

# Working agreement

- Before editing, read `package.json`, the nearest README, and one existing file
  in the target directory.
- Make the smallest change that satisfies the request. Do not rename, reformat,
  or modernize unrelated code.
- Reuse existing dependencies. Ask before adding a package or changing a lockfile.
- Do not edit generated files, `dist/`, `coverage/`, or `legacy/`.
- After a code change, run the narrowest relevant check from `package.json`.
- If the check fails, report the command, the relevant failure, and the next
  proposed action. Do not claim the task is complete.
- If requirements conflict or the correct pattern is not visible in the repo,
  ask one concise question before editing.

This works because every line has an observable consequence. “Read X before editing” creates a first move. “Do not change the lockfile” removes a tempting detour. “Run the narrowest relevant check” gives the model a finish line without making it burn tokens on npm test for a two-line docs patch.

Avoid putting aspirational instructions here: “write clean code,” “think deeply,” “be proactive,” and “follow best practices” consume context while leaving the hard choice untouched. The same goes for absolute language you don’t mean. If the model must sometimes modify legacy/, say who can authorize it and what evidence it needs, rather than writing “never” and then teaching everyone to ignore the rule.

Make path-scoped rules do the specialist work

The useful move for smaller models is not more global guidance; it’s less irrelevant guidance. Cline supports YAML paths frontmatter, so a rule can activate only when the prompt, open tabs, edited files, or pending edits match its globs. Split API, UI, migration, test, and documentation guidance into files that only load when they apply.

---
paths:
  - "src/api/**"
  - "src/services/**"
---

# API changes

- Follow the response and error shape in `src/api/errors.ts`.
- Validate request input at the route boundary; services receive typed values.
- Add or update the closest `*.test.ts` file for behavior changes.
- Before editing a route, inspect one sibling route with the same HTTP method.
- Verify with: `npm run test -- --runInBand <closest-test-file>`.
- If the change needs a schema migration, stop after writing a proposed migration
  plan and ask for approval before creating migration files.

Notice that this rule names a reference implementation and a verification command. A small model can imitate a nearby route more reliably than it can reconstruct your error taxonomy from prose. It also has an explicit boundary around migrations, where a plausible-looking edit can become an operational change.

Use narrow globs. src/** is fine while you are discovering the repo, but it eventually becomes another global rule in disguise. If a rule fires at the wrong time, Cline’s docs recommend checking open tabs and paths named in the prompt as well as the glob; “fix src/api/users.ts” is enough to activate an API rule even before Cline edits a file.

Write rules as decision tables, not essays

When the model repeatedly makes the same bad call, don’t add a paragraph explaining why the call is bad. Add a branch it can execute. Keep it close to the form you’d use in a PR comment:

• “If an endpoint returns a new field, update docs/api.md; otherwise do not touch docs.”
• “If a test needs time control, use the fake-timer helper in test/helpers/time.ts; do not mock Date directly.”
• “If pnpm lint fails only in files untouched by this task, report it and continue. If it fails in an edited file, fix it before stopping.”
• “If more than three files outside the named feature need changes, stop and present a plan.”

That last condition matters. Smaller models are often competent at the local edit and unreliable at recognizing when a local edit has expanded into a design decision. A numeric threshold isn’t magic, but it gives the agent a cheap tripwire. Tune it after a week of real tasks: if it interrupts normal work, raise it; if it happily rewrites half the repo, lower it.

Keep long procedures out of always-on rules

Release steps, dependency upgrades, incident triage, and migration execution are not .clinerules material just because they are important. Put them in .clinerules/workflows/ and invoke them intentionally, such as /release-prep.md. Cline workflows are Markdown files run by filename and can combine ordinary instructions with exact command or approval steps.

This is especially helpful with smaller models. A workflow can say: check git status; run pnpm test; stop on failure; ask before git tag; then push. The model gets a fixed sequence only for the task that needs it, instead of carrying release instructions into every CSS fix. Put commands that must be exact in the workflow, but still review it: workflows execute with your permissions.

Test the rule like a small piece of production configuration

Don’t judge a rule by whether it reads well. Open a representative target file, start a new Cline task, and issue a prompt that includes the path: “Update src/api/users.ts to reject empty display names.” Check that the intended conditional rule activates, that the model reads the reference file before editing, and that it runs the exact verification command. Cline shows a notification when a conditional rule is applied; if it does not appear, fix the YAML or the glob before debating model quality.

Then try the failure case on purpose: ask for a migration, request a package addition, or name a forbidden directory. Your rule should produce one of three predictable behaviors: proceed with a known pattern, run a named check, or stop and ask. If it produces a fourth behavior—an eloquent explanation followed by the wrong edit—shorten the rule and replace soft wording with a file path, command, threshold, or example.

Commit the rules with the code they govern and review changes to them like changes to CI. They are not a substitute for model capability, and they are bad at protecting you from a model that ignores tool output or invents facts. But for smaller open models, a 20-line rule that narrows the next action is usually worth more than a giant prompt that tries to encode your whole engineering culture.