Cline rules

1---
2description: Guidelines and best practices for creating effective .clinerules to guide Cline's behavior, knowledge, and workflows.
3author: https://github.com/nickbaumann98
4version: 1.1
5category: "Cline Core"
6tags: ["meta", "guideline", "clinerules", "documentation", "best-practices"]
7globs: ["clinerules/**/*.md"] # This rule is relevant when writing or editing any .clinerule
8---
9 
10# Writing Effective .clinerules
11 
12Effective `.clinerules` are the cornerstone of Cline's tailored assistance. They guide Cline's behavior, provide context, and define workflows. This document outlines best practices for creating powerful and understandable rules, ensuring they effectively direct Cline.
13 
14## 1. Getting Started: The Basics
15 
16Refer to the main `README.md` in the `.clinerules` repository for instructions on:
17* Forking the repository.
18* Creating new Markdown files (`.md`) in the `clinerules/` directory.
19* Naming your files using `kebab-case` (e.g., `my-new-rule.md`).
20* Submitting Pull Requests.
21 
22## 2. Core Principles for All ClineRules
23 
24* **Clear Objective:** Every rule should have a well-defined purpose. State this objective clearly at the beginning of the rule, ideally in the frontmatter `description` and reinforced in the introductory text.
25    * *Example:* `cline-for-research.md` starts with an "Objective" section. This document's objective is stated in its frontmatter `description` and introduction.
26* **Structured Content:** Use Markdown effectively to structure your rule.
27    * **Headings and Subheadings:** Organize content logically using `#`, `##`, `###`, etc.
28    * **Lists:** Use bulleted (`*`, `-`) or numbered (`1.`, `2.`) lists for steps, criteria, or key points.
29    * **Code Blocks:** Use fenced code blocks (```) for code examples, commands, or structured data. Specify the language for syntax highlighting (e.g., ```typescript ... ```).
30    * **Emphasis:** Use **bold** and *italics* to highlight important terms or instructions.
31* **Clarity and Precision:** Write in a clear, unambiguous manner. Avoid jargon where possible, or explain it if necessary. If the rule is meant to guide AI behavior, precision is paramount.
32* **Modularity:** Each rule should ideally focus on a specific topic, tool, workflow, or area of knowledge. This makes rules easier to manage, understand, and update.
33 
34## 3. Frontmatter for Metadata
35 
36Use YAML frontmatter at the beginning of your rule file to provide metadata. This helps Cline (and humans) understand the rule's context and applicability.
37 
38```yaml
39---
40description: A brief explanation of what this rule is for.
41author: Your Name/Handle
42version: 1.0
43# Globs can specify file patterns where this rule is particularly relevant.
44# Cline might use this to prioritize or activate rules.
45globs: ["**/*.js", "**/*.ts", "specific-config.json"]
46# Tags can help categorize rules.
47tags: ["coding-guideline", "documentation", "workflow", "supabase"]
48---
49 
50# Rule Title
51... rest of the rule content ...
52```
53 
54* **`description`**: A concise summary of the rule's purpose (as used in this document).
55* **`globs`**: (As seen in `next-js-supabase.md` and this document) An array of file patterns indicating relevance.
56* **Other metadata**: Include `author`, `version`, `tags` as appropriate (see this document's frontmatter for an example).
57 
58## 4. Types of ClineRules and Their Structure
59 
60ClineRules can serve various purposes. Tailor the structure and content to the type of rule you're writing.
61 
62### a. Informational / Documentation Rules
63Provide comprehensive information about a system, architecture, or technology. This document is an example of an informational rule.
64* **Key Elements:**
65    * Overview and project goals.
66    * Detailed explanations of components, concepts, or processes.
67    * Diagrams (e.g., Mermaid.js, as seen in `cline-architecture.md`) to visualize systems.
68    * Code snippets or configuration examples.
69    * Definitions of key terms.
70* **Example:** `cline-architecture.md`, `cline-for-slides.md`, this `writing-effective-clinesrules.md` document.
71 
72### b. Process / Workflow Rules
73Define a sequence of steps for Cline or the user to follow to achieve a specific outcome.
74* **Key Elements:**
75    * A clear start and end point.
76    * Numbered steps for sequential actions.
77    * Decision points with clear options (e.g., "If X, then Y, else Z").
78    * Specification of tools to be used at each step (e.g., `use_mcp_tool`, `write_to_file`).
79    * Expected inputs and outputs for each step.
80    * Notes on dependencies or prerequisites.
81* **Example:** `cline-for-research.md`, `mcp-development-protocol.md`
82 
83### c. Behavioral / Instructional Rules (for Guiding AI)
84These rules directly instruct Cline on how it should behave, process information, or generate responses, especially in specific contexts.
85* **Key Elements:**
86    * **Explicit Instructions:** Use imperative verbs (MUST, SHOULD, DO NOT, NEVER, ALWAYS).
87    * **Critical Warnings:** Use formatting (bold, ALL CAPS, emojis like 🚨, ⚠️, ✅, ❌) to draw attention to critical instructions or prohibitions (as seen in `next-js-supabase.md` and `mcp-development-protocol.md`).
88    * **Positive and Negative Examples:** Show correct and incorrect ways of doing things (e.g., code patterns to use vs. avoid).
89    * **Triggers and Conditions:** Define when the rule or specific instructions within it should be activated.
90    * **Verification Steps:** Include "thinking" blocks or checklists for the AI to verify its actions against the rule's constraints (e.g., the `<thinking>` block in `mcp-development-protocol.md`).
91    * **Context Management:** Define how Cline should manage context, memory, or state if relevant (e.g., `memory-bank.md`).
92* **Example:** `next-js-supabase.md`, `memory-bank.md`
93 
94### d. Meta-Rules
95Rules that define how Cline manages or improves its own rules or processes.
96* **Key Elements:**
97    * Triggers for the meta-process.
98    * Steps involved in the meta-process (e.g., reflection, suggesting improvements).
99    * User interaction points (e.g., asking for confirmation).
100* **Example:** `self-improving-cline.md`
101 
102## 5. Language and Formatting for AI Guidance
103 
104When writing rules intended to directly steer Cline's AI behavior, certain conventions are highly effective:
105 
106* **Be Directive:**
107    * Use **MUST** for absolute requirements.
108    * Use **SHOULD** for strong recommendations.
109    * Use **MAY** for optional actions.
110    * Use **MUST NOT** or **NEVER** for absolute prohibitions.
111    * Use **SHOULD NOT** for strong discouragement.
112* **Highlight Critical Information:**
113    * `next-js-supabase.md` uses "🚨 CRITICAL INSTRUCTIONS FOR AI LANGUAGE MODELS 🚨" and "❌ NEVER GENERATE THIS CODE" / "✅ ALWAYS GENERATE THIS EXACT PATTERN".
114    * `mcp-development-protocol.md` uses "⚠️ CRITICAL: DO NOT USE attempt_completion BEFORE TESTING ⚠️" and "BLOCKER ⛔️".
115* **Provide Concrete Examples:**
116    * Show exact code snippets, commands, or output formats.
117    * For code generation, clearly distinguish between desired and undesired patterns.
118* **Define AI's "Thought Process":**
119    * The `<thinking> ... </thinking>` block in `mcp-development-protocol.md` is a good way to make the AI "pause and check" its understanding or state before proceeding.
120    * The "AI MODEL VERIFICATION STEPS" in `next-js-supabase.md` serve a similar purpose.
121* **Specify Tool Usage:**
122    * If Cline needs to use a specific tool (e.g., `attempt_completion`, `replace_in_file`, `use_mcp_tool`), explicitly state it and provide any necessary parameters or context for that tool.
123 
124## 6. Content Best Practices
125 
126* **Start Broad, Then Narrow:** Begin with a general overview or objective, then delve into specifics.
127* **Use Analogies or Scenarios:** If explaining a complex concept, an analogy or a use-case scenario can be helpful.
128* **Define Terminology:** If your rule introduces specific terms or acronyms, define them.
129* **Anticipate Questions:** Try to think about what questions a user (or Cline itself) might have and address them proactively.
130* **Keep it Updated:** As systems or processes change, ensure the relevant `.clinerules` are updated to reflect those changes. The `self-improving-cline.md` rule encourages this.
131 
132## 7. Referencing Other Rules
133 
134If your rule builds upon or relates to another rule, feel free to reference it by its filename. This helps create a connected knowledge base.
135 
136## 8. Testing Your Rule
137 
138While not always formally testable, consider how your rule will be interpreted:
139* **Human Readability:** Is it clear to another person? If so, it's more likely to be clear to Cline.
140* **AI Interpretation (for behavioral rules):** Does it provide enough specific guidance? Are there ambiguities? Try "role-playing" as Cline and see if you can follow the instructions.
141* **Practical Application:** If it's a workflow, manually step through it. If it's a coding guideline, try applying it to a piece of code.
142* **Self-Review Against These Guidelines:** Does your new rule adhere to the principles and best practices outlined in *this very document* (`writing-effective-clinesrules.md`)?
143