Rules

Define specific instructions and coding standards for Cline.

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

Use rules when you want Cline to:

• Follow your team’s coding standards (naming conventions, file organization, error handling patterns)
• Understand project-specific context (tech stack, architecture decisions, dependencies)
• Apply consistent documentation or testing requirements
• Remember constraints like “don’t modify files in /legacy” or “always use TypeScript”

New to Rules? Watch Cline Rules Explained to see them in action.

Supported Rule Types

Cline recognizes rules from multiple sources, so you can use 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 organize files but are optional.

When both workspace and global rules exist, Cline combines them. Workspace rules take precedence when they conflict with global rules. See Storage Locations for more guidance.

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

1. Open the Rules menu

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

2. Create a new rule file

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

3. 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.

Toggling Rules

Every rule has a toggle to enable or disable it. This gives you fine-grained control over which rules apply to your current task without deleting the rule file.

For example, you might have a strict testing rule that you want to disable when prototyping, or a client-specific rule you only need when working on 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. If your tech stack changes, update the rules.

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

# Project Guidelines

## Code Style
- Use TypeScript for all new files
- Prefer composition over inheritance
- Use repository pattern for data access
- Follow error handling pattern in /src/utils/errors.ts

## Documentation
- Update relevant docs when modifying features
- Keep README.md in sync with new capabilities

## Testing
- Unit tests required for business logic
- Integration tests for API endpoints
- E2E tests for critical user flows