> ## Documentation Index > Fetch the complete documentation index at: https://mintlify.com/cline/cline/llms.txt > Use this file to discover all available pages before exploring further. # Rules > Define persistent coding standards and project constraints that Cline follows automatically across every task. 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](https://youtu.be/xQwsy2vkK5M) 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](https://agents.md/) 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. ```text theme={null} 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 Click the scale icon at the bottom of the Cline panel, to the left of the model selector. Click **New rule file...** and enter a filename (e.g., `coding-standards`). The file is created with a `.md` extension. 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: ```markdown theme={null} # 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 ```markdown coding.md theme={null} # 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 ``` ```markdown testing.md theme={null} # Testing standards ## Requirements - Unit tests required for all business logic - Integration tests for all API endpoints - E2E tests for critical user flows ## Style - Use descriptive test names: "should [expected behavior] when [condition]" - One assertion per test when possible - Mock external dependencies, never internal modules - Use factory functions for test data, not static fixtures ## Coverage - Do not merge without tests for new features - Maintain existing test coverage — do not delete tests without discussion ``` ```markdown architecture.md theme={null} # Architecture constraints ## File organization - Feature code lives in `src/features//` - Shared utilities live in `src/shared/` - Do not import from `src/features/` into `src/shared/` ## Legacy code - Do not modify any files under `/legacy/` — scheduled for removal in Q2 - Do not add new dependencies on legacy modules ## Data access - All database queries must go through repository classes - No raw SQL outside of repository implementations - Repositories live in `src/repositories/` ``` ## 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: ```yaml theme={null} --- 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: ```yaml theme={null} --- 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 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. ```yaml theme={null} # .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 ``` ```yaml theme={null} # .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 ``` Enforce testing standards automatically. This rule activates only when you're writing or modifying tests, so testing guidance appears exactly when you need it. ```yaml theme={null} # .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 ``` Apply documentation standards only when editing docs. Prevents style rules from cluttering your context when you're writing code. ```yaml theme={null} # .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.