Rules

Rules are markdown files that provide persistent instructions across all conversations. Instead of repeating the same preferences every time you start a new task, define them once and Cline follows them automatically. Use rules to:

Enforce team coding standards (naming conventions, file organization, error handling patterns)
Capture project-specific context (tech stack, architecture decisions, constraints)
Apply consistent documentation or testing requirements
Set hard boundaries like “never modify files in /legacy” or “always use TypeScript”

Watch Cline Rules Explained to see rules in action.

Supported rule formats

Cline recognizes rules from multiple sources, so you can reuse existing rule files from other tools:

Rule type	Location	Description
Cline Rules	`.clinerules/`	Primary rule format
Cursor Rules	`.cursorrules`	Automatically detected
Windsurf Rules	`.windsurfrules`	Automatically detected
AGENTS.md	`AGENTS.md`	Standard format for cross-tool compatibility

All detected rule types appear in the Rules panel, where you can toggle them individually.

Where rules live

Rules can be stored in two locations: your project workspace or globally on your system. Workspace rules go in .clinerules/ at your project root. Use these for team standards, project-specific constraints, and anything you want to share with collaborators via version control. Global rules go in your system’s Cline Rules directory. Use these for personal preferences that apply across all projects.

your-project/
├── .clinerules/              # Workspace rules
│   ├── coding.md             # Coding standards
│   ├── testing.md            # Test requirements
│   └── architecture.md       # Structural decisions
├── src/
└── ...

Cline processes all .md and .txt files inside .clinerules/, combining them into a unified set of rules. Numeric prefixes like 01-coding.md help with organization but are optional. When both workspace and global rules exist, Cline combines them. Workspace rules take precedence when they conflict with global rules.

Global rules directory

Operating system	Default location
Windows	`Documents\Cline\Rules`
macOS	`~/Documents/Cline/Rules`
Linux/WSL	`~/Documents/Cline/Rules`

Linux/WSL users: if you don’t find global rules in ~/Documents/Cline/Rules, check ~/Cline/Rules.

Creating rules

Open the Rules menu

Click the scale icon at the bottom of the Cline panel, to the left of the model selector.

Create a new rule file

Click New rule file… and enter a filename (e.g., coding-standards). The file is created with a .md extension.

Write your rule

Add your instructions in markdown format. Keep each rule file focused on a single concern.

You can also use the /newrule slash command to have Cline create a rule interactively based on your description.

Toggling rules

Every rule has a toggle to enable or disable it. This gives you fine-grained control without deleting the rule file — useful when you want to disable a strict testing rule during prototyping, or a client-specific rule you only need for that client’s features.

Writing effective rules

Structure

Rules work best when they’re scannable and specific. Use markdown structure to organize instructions:

# Rule title

Brief context about why this rule exists (optional but helpful).

## Category 1
- Specific instruction
- Another instruction with example: `like this`
- Reference to file: see /src/utils/example.ts

## Category 2
- More instructions
- Include the "why" when it's not obvious

Cline reads rules as context, so formatting matters. Headers help Cline understand the scope of each instruction. Bullet points make individual requirements clear. Code examples show exactly what you want.

Best practices

Be specific, not vague. “Use descriptive variable names” is too broad. “Use camelCase for variables, PascalCase for classes, UPPER_SNAKE for constants” gives Cline something concrete to follow. Include the why. When a rule might seem arbitrary, explain the reason. “Don’t modify files in /legacy (this code is scheduled for removal in Q2)” helps Cline make better decisions in edge cases. Point to examples. If your codebase already demonstrates the pattern you want, reference it. “Follow the error handling pattern in /src/utils/errors.ts” is more effective than describing the pattern from scratch. Keep rules current. Outdated rules confuse Cline and waste context. If a constraint no longer applies, remove it. One concern per file. Split rules by topic: coding.md for style, testing.md for test requirements, architecture.md for structural decisions. This makes it easy to toggle specific rules on or off.

Rules consume context tokens. Avoid lengthy explanations or pasting entire style guides. Keep rules concise and link to external documentation when detailed reference is needed.

Example rule files

# Code style

## TypeScript
- Use TypeScript for all new files — no plain `.js`
- Prefer composition over inheritance
- Use the repository pattern for data access
- Follow the error handling pattern in /src/utils/errors.ts

## Naming
- camelCase for variables and functions
- PascalCase for classes, interfaces, and type aliases
- UPPER_SNAKE_CASE for module-level constants
- Prefix private class members with `_`

## Imports
- Use path aliases (`@/`) instead of relative imports for src code
- Group imports: external packages first, then internal modules

Conditional rules

Conditional rules let you scope instructions to specific parts of your codebase. Rules activate only when you’re working with matching files, keeping context focused and relevant.

Without conditionals: every rule loads for every request.
With conditionals: rules activate only when your current files match their defined scope.

For example, documentation style rules should only appear when you’re editing docs, not when you’re writing application code or tests. As your rule library grows, loading every rule for every request wastes context tokens. Conditional rules give Cline only the instructions that matter for the files you’re actually touching.

How it works

Conditional rules use YAML frontmatter at the top of your rule files. When Cline processes a request, it gathers context from your current work (open files, visible tabs, mentioned paths, edited files), evaluates each rule’s conditions, and activates matching rules.

When a conditional rule activates, you’ll see a notification: “Conditional rules applied: workspace:frontend-rules.md”

Writing conditional rules

Add YAML frontmatter to the top of any rule file in your .clinerules/ directory:

---
paths:
  - "src/components/**"
  - "src/hooks/**"
---

# React component guidelines

When creating or modifying React components:
- Use functional components with React hooks
- Extract reusable logic into custom React hooks
- Keep components focused on a single responsibility

The --- markers delimit the frontmatter. Everything after the closing --- is your rule content.

The `paths` conditional

Currently, paths is the supported conditional. It takes an array of glob patterns:

---
paths:
  - "src/**"           # All files under src/
  - "*.config.js"      # Config files in root
  - "packages/*/src/" # Monorepo package sources
---

Glob pattern syntax:

Pattern	Matches
`src/*/.ts`	All TypeScript files under `src/`
`*.md`	Markdown files in root only
`*/.test.ts`	Test files anywhere in the project
`packages/{web,api}/**`	Files in web or api packages
`src/components/*.tsx`	TSX files directly in components (not nested)

Multiple patterns: a rule activates if any pattern matches any file in your context. No frontmatter: rules without frontmatter are always active. Empty paths array: paths: [] means the rule never activates — use this to temporarily disable a rule.

Practical examples

Frontend vs backend rules

Keep frontend and backend rules separate to avoid noise. Frontend rules only load when working with UI code; backend rules only load when working with API or service code.

# .clinerules/frontend.md
---
paths:
  - "src/components/**"
  - "src/pages/**"
  - "src/hooks/**"
---

# Frontend guidelines

- Use Tailwind CSS for styling
- Prefer server components where possible
- Keep client components small and focused

# .clinerules/backend.md
---
paths:
  - "src/api/**"
  - "src/services/**"
  - "src/db/**"
---

# Backend guidelines

- Use dependency injection for services
- All database queries go through repositories
- Return typed errors, not thrown exceptions

Test file rules

Enforce testing standards automatically. This rule activates only when you’re writing or modifying tests, so testing guidance appears exactly when you need it.

# .clinerules/testing.md
---
paths:
  - "**/*.test.ts"
  - "**/*.spec.ts"
  - "**/__tests__/**"
---

# Testing standards

- Use descriptive test names: "should [expected behavior] when [condition]"
- One assertion per test when possible
- Mock external dependencies, not internal modules
- Use factories for test data, not fixtures

Documentation rules

Apply documentation standards only when editing docs. Prevents style rules from cluttering your context when you’re writing code.

# .clinerules/docs.md
---
paths:
  - "docs/**"
  - "**/*.md"
  - "**/*.mdx"
---

# Documentation guidelines

- Use sentence case for headings
- Include code examples for all features
- Keep paragraphs short (3-4 sentences max)
- Link to related documentation

Combining with rule toggles

Conditional rules work alongside the rule toggle UI. Toggle off a conditional rule to disable it entirely — it won’t activate even if paths match. This provides two levels of control: manual toggles and automatic condition-based activation.

Troubleshooting conditional rules

Rule not activating:

Check that file paths in your context match the glob pattern
Verify the rule is toggled on in the rules panel
Ensure YAML frontmatter has proper --- delimiters

Rule activating unexpectedly:

Review glob patterns — ** is recursive and may match more than intended
Check for open files that match the pattern
File paths mentioned in your message also count as context

Frontmatter showing in output:

YAML couldn’t be parsed
Check for syntax errors (unquoted special characters, improper indentation)

Be explicit about file paths in your prompts. “Update src/services/user.ts” reliably triggers path-based rules; “update the user service” may not.

Get Started

Core Workflows

Features

Customization

MCP

Models & Providers

Cline CLI

Troubleshooting

Supported rule formats

Where rules live

Global rules directory

Creating rules

Toggling rules

Writing effective rules

Structure

Best practices

Example rule files

Conditional rules

How it works

Writing conditional rules

The `paths` conditional

Practical examples

Combining with rule toggles

Troubleshooting conditional rules

Build docs developers (and LLMs) love

Get Started

Core Workflows

Features

Customization

MCP

Models & Providers

Cline CLI

Troubleshooting

​Supported rule formats

​Where rules live

​Global rules directory

​Creating rules

​Toggling rules

​Writing effective rules

​Structure

​Best practices

​Example rule files

​Conditional rules

​How it works

​Writing conditional rules

​The paths conditional

​Practical examples

​Combining with rule toggles

​Troubleshooting conditional rules

Build docs developers (and LLMs) love

Supported rule formats

Where rules live

Global rules directory

Creating rules

Toggling rules

Writing effective rules

Structure

Best practices

Example rule files

Conditional rules

How it works

Writing conditional rules

The `paths` conditional

Practical examples

Combining with rule toggles

Troubleshooting conditional rules