Cline Rules: Generate a .clinerules Set (and Know When to Use Workflows)

What Cline Rules Are

Cline rules are plain-text instructions injected into the system prompt of every conversation Cline has in a project. They live in a .clinerules file or a .clinerules/ directory at the project root, and Cline deprecated its older Custom Instructions feature to focus entirely on them. Workspace rules carry team standards; global rules carry personal preferences.

Cline's own rules documentation explains the file layout, the glob-based path scoping, and the formats it accepts. The version-controlled .clinerules writeup covers the concept. Both teach manual rule creation through the UI or a /newrule command. Neither hands you a prompt that generates a scoped rules set from your stack and risk profile.

The Distinction That Decides Everything: Rules vs Workflows

Get this one wrong and every conversation pays for it. Rules append to every system prompt, so they cost tokens on every turn and should hold only what's always true. Workflows inject on demand and cost tokens only when invoked, so they suit procedures you run occasionally.

Cline's team wrote a whole post titled Stop Adding Rules When You Need Workflows, and the title is the lesson. "Always use the repository pattern" is a rule. "Cut a release: bump the version, run the changelog generator, tag, push" is a workflow. Putting the release steps in .clinerules means every chat about an unrelated bug carries your release procedure as dead weight.

The Section Contract for a .clinerules Set

A generator prompt that reads your stack and risk profile can produce a scoped set, not one undifferentiated file:

• Always-on rules. The handful of conventions true everywhere: stack idioms, the patterns reviewers enforce, the non-negotiable style.
• Path-scoped rules. Files with paths frontmatter so frontend rules load on **/*.tsx, test rules on **/*.test.ts, and nothing loads where it doesn't apply.
• A guardrail tier. The Always / Ask-first / Never boundaries, since Cline runs autonomously and can act on its own reading of an ambiguous instruction.
• A workflow shortlist. The procedures that should be workflows, not rules, extracted so they don't bloat the always-on set.

That fourth item is the one the docs don't push you toward, and it's where most setups leak tokens.

The Self-Improving Loop, and Its Catch

One feature sets Cline rules apart: because the files are plain text in your repo, Cline can read and edit them. That unlocks a loop where you correct Cline once in conversation, then tell it to write the correction into .clinerules so it sticks. Over a few weeks the rules file becomes a record of every lesson the project taught the agent.

It's genuinely useful, and it's also where setups drift. An agent editing its own standing instructions can phrase a rule more broadly than you meant, or add a rule that contradicts an older one it didn't re-read. The fix isn't to disable the loop. It's to treat rule edits like any other change Cline makes: read the diff. A rule that quietly grew from "don't touch the auth module without review" to "don't touch auth" is a different policy, and you want to catch that in review, not three sessions later when Cline stops asking.

Start the rules from a generated baseline, then let the loop refine it. That way the always-on set has a coherent structure from day one, and the self-edits are tweaks to a good file rather than accretion on a thin one.

How to Generate Your Cline Rules, Step by Step

1. Gather stack and risk facts

The conventions reviewers enforce, the directories Cline should never touch, and the operations that need a human nod.

2. Fill the variables

The prompt takes {{stack}}, {{conventions}}, and {{risk_profile}}, meaning what's dangerous in this repo, so the guardrail tier reflects reality.

3. Run it against the contract

You get the always-on file, a set of path-scoped files with their globs, a boundary tier, and a list of procedures to make into workflows.

4. Review before trusting

Because Cline can edit its own rules, the self-improving loop is real, and so is drift. Read what the agent writes to .clinerules before you rely on it.

One Opinion: A Guardrail Tier Is Mandatory for Autonomous Agents

Here's a position worth defending. With a completion tool, a vague rule produces a vague suggestion you ignore. With an autonomous agent like Cline that edits files and runs commands, a vague boundary produces an action you have to undo. The risk isn't symmetric, so the rules shouldn't be either.

Every .clinerules set for an autonomous agent needs an explicit Never tier — files it must not modify, commands it must not run, secrets it must not read. Not because Cline is reckless, but because "use good judgment" isn't a boundary the model can enforce against itself. This is the same reasoning behind a dedicated guardrails prompt for AI coding agents: boundaries are policy, and policy has to be explicit.

Variables You'll Set

Getting Started

1. List the always-true conventions and the file-type-specific ones separately.
2. Write down what Cline must never touch.
3. Feed {{stack}}, {{conventions}}, and {{risk_profile}} to a generator prompt with a fixed contract.
4. Take the always-on file, the path-scoped set, and the workflow shortlist it proposes.
5. Move the proposed procedures into workflows; commit the rest.

For the boundary layer specifically, the Coding Agent Guardrails System Prompt produces the Always / Ask-first / Never tiers Cline reads as a ## Boundaries block. If your rules lean on connected tools, the MCP Tool Wiring Playbook wires the agent's instructions to the servers a job actually needs with a least-privilege check.

Why path-scoped rules pay off

A single flat .clinerules file means your Python rules load while Cline edits a React component, and your React rules load while it touches a migration. Both are noise in the wrong context, and noise lowers adherence to the rules that do apply. Splitting by paths frontmatter keeps each conversation carrying only relevant rules — cheaper per turn, and more reliable, because the model isn't filtering out half its own instructions.

Cline rules reward discipline: always-on stays lean, procedures become workflows, and boundaries are explicit because the agent acts on its own. For the related setups, see Windsurf rules for Cascade and GitHub Copilot custom instructions.