Rules

Rules are custom instruction files that provide Cline with guidelines about your coding preferences, standards, and best practices. These instructions get added to Cline’s context when working on tasks.

What are Rules?

Rules are simple markdown files stored in a .clinerules/ directory that contain your team’s conventions, preferences, and guidelines. They help Cline understand your:

Coding style and conventions
Preferred libraries and frameworks
Architectural patterns
Testing strategies
Documentation standards
Communication preferences

Rules are just .md files - no complex configuration needed!

Quick Example

Here’s a simple rule file that guides TypeScript development:

# TypeScript Conventions

## Code Style
- Use 2-space indentation
- Prefer `const` over `let`
- Always use explicit return types for functions
- Use named exports instead of default exports

## Testing
- Write unit tests for all utility functions
- Use Vitest as the testing framework
- Aim for 80%+ code coverage

## Dependencies
- Prefer native TypeScript features over external libraries
- Use Zod for runtime type validation
- Use date-fns for date manipulation

Creating Rules

Using /newrule Command
Manual Creation

The easiest way to create a rule is with the /newrule command:

During a conversation with Cline, type /newrule
Cline will analyze your conversation and preferences
It creates an appropriately named .md file in .clinerules/

Example:

/newrule

Based on our conversation, create a rule for React component structure

You can also create rule files manually:

Create a .clinerules/ directory in your repository root
Add markdown files with your guidelines
Use descriptive names like react-patterns.md or api-conventions.md

File structure:

your-repo/
├── .clinerules/
│   ├── typescript-style.md
│   ├── testing-standards.md
│   └── code-review-checklist.md
└── src/

Global vs Workspace Rules

Workspace Rules

Location: .clinerules/ in your repositoryScope: Specific to that projectUse for: Project-specific conventions and patterns

Global Rules

Location: Documents/Cline/ directoryScope: All your projectsUse for: Personal preferences that apply everywhere

Managing Rules

Toggling Rules

You can enable or disable individual rule files:

Click the rules icon in Cline’s interface
Toggle rules on/off as needed
Changes apply immediately to new tasks

Disabling a rule removes it from Cline’s context, but keeps the file intact. You can re-enable it anytime.

Enterprise Remote Rules

Enterprise deployments can configure remote global rules that apply to all team members. These are managed through your infrastructure configuration and cannot be toggled off by individual developers.See Self-Hosted Configuration for details on remote rules.

Compatible Formats

Cline also respects rules from other AI coding tools:

File/Directory	Tool	Location
`.cursorrules`	Cursor	Workspace root (single file)
`.cursor/rules/`	Cursor	Workspace directory (`.mdc` files)
`.windsurfrules`	Windsurf	Workspace root (single file)
`AGENTS.md`	Various	Workspace root + recursive search

AGENTS.md behavior: Cline only searches for nested AGENTS.md files recursively if a top-level AGENTS.md exists in your workspace root. If found, all AGENTS.md files are combined with their relative paths as headers.

These files work the same way as .clinerules/ files and can be toggled on/off independently.

Best Practices

Keep Rules Focused

Each rule file should focus on one topic:

✅ typescript-conventions.md
✅ react-component-structure.md
❌ everything-about-our-codebase.md

Be Specific, Not Generic

Base rules on actual team preferences, not assumptions:

✅ “We use React Query for server state management”
❌ “Use best practices for state management”

Update Rules as Projects Evolve

Review and update rules periodically:

When adopting new technologies
After major architectural changes
When team conventions evolve

Don't Overdo It

Too many rules can overwhelm Cline’s context:

Start with 3-5 essential rules
Add more only when truly needed
Remove outdated rules promptly

Example Rule Files

API Design Standards

# API Design Standards

## REST Conventions
- Use plural nouns for endpoints (`/users`, not `/user`)
- Use HTTP methods semantically (GET, POST, PUT, DELETE)
- Return appropriate status codes

## Response Format
\`\`\`typescript
{
  data: T,
  error?: string,
  metadata?: {
    page: number,
    total: number
  }
}
\`\`\`

## Error Handling
- Always return error messages in `error` field
- Use 4xx for client errors, 5xx for server errors
- Include request ID in error responses

Testing Requirements

# Testing Requirements

## Test Organization
- Place tests next to source files (`Button.test.tsx`)
- Use `describe` blocks to group related tests
- Write descriptive test names

## Coverage Requirements
- Unit tests for all utility functions
- Integration tests for API endpoints
- E2E tests for critical user flows
- Minimum 80% coverage for new code

## Mocking Strategy
- Mock external API calls
- Use test fixtures for complex data
- Prefer dependency injection for testability

Enterprise Solutions

What are Rules?

Quick Example

Creating Rules

Global vs Workspace Rules

Workspace Rules

Global Rules

Managing Rules

Toggling Rules

Enterprise Remote Rules

Compatible Formats

Best Practices

Example Rule Files

Next Steps

Workflows

Remote Configuration

Enterprise Solutions

​What are Rules?

​Quick Example

​Creating Rules

​Global vs Workspace Rules

Workspace Rules

Global Rules

​Managing Rules

​Toggling Rules

​Enterprise Remote Rules

​Compatible Formats

​Best Practices

​Example Rule Files

​Next Steps

Workflows

Remote Configuration

What are Rules?

Quick Example

Creating Rules

Global vs Workspace Rules

Managing Rules

Toggling Rules

Enterprise Remote Rules

Compatible Formats

Best Practices

Example Rule Files

Next Steps