Cline rules

1# Cline Rules — Local Model / LM Studio Editing
2 
3## Core Principle
4 
5Make the smallest safe change possible.
6 
7Local models can lose exact file context and frequently fail when generating large SEARCH/REPLACE blocks. Never compensate for a failed patch by generating an even larger or more detailed SEARCH block.
8 
9Prefer:
10 
111. Read the current file.
122. Identify a short, unique anchor.
133. Make a minimal edit.
144. Re-read or inspect the changed area.
155. Verify the result.
16 
17---
18 
19## 1. ALWAYS READ THE CURRENT FILE
20 
21Before modifying an existing file:
22 
23* Read the current file from disk.
24* Do not rely on code previously shown in conversation.
25* Do not assume a file is unchanged since it was last read.
26* If an edit fails, re-read the file before attempting another edit.
27 
28Never construct a SEARCH block from memory.
29 
30---
31 
32## 2. NEVER REPEAT A FAILED SEARCH/REPLACE
33 
34If a SEARCH/REPLACE operation fails:
35 
36DO NOT:
37 
38* Repeat the same SEARCH block.
39* Make the SEARCH block longer.
40* Reconstruct the entire function.
41* Guess at whitespace.
42* Guess at indentation.
43* Assume the previous file contents were accurate.
44 
45INSTEAD:
46 
471. Re-read the file.
482. Find the relevant code again.
493. Use a smaller search anchor.
504. Make the smallest possible replacement.
515. Verify the result.
52 
53Maximum: 2 attempts at an exact SEARCH/REPLACE operation.
54 
55After 2 failures, stop attempting increasingly complicated SEARCH blocks.
56 
57---
58 
59## 3. USE SHORT SEARCH ANCHORS
60 
61Prefer unique anchors such as:
62 
63```text
64const promises = CATEGORIES.map
65```
66 
67or:
68 
69```text
70loader.load(
71```
72 
73or:
74 
75```text
76assets[category.id]
77```
78 
79Do NOT create unnecessarily large SEARCH blocks containing entire functions.
80 
81Bad:
82 
83```text
84const promises = CATEGORIES.map(category => {
85    return new Promise((resolve) => {
86        loader.load(
87            category.planetModel,
88            ...
89            ...
90            ...
91        );
92    });
93});
94```
95 
96Better:
97 
98```text
99const promises = CATEGORIES.map
100```
101 
102The goal is to locate the code, not reproduce the entire file.
103 
104---
105 
106## 4. DO NOT ASSUME WHITESPACE
107 
108Never assume that the file uses:
109 
110* a particular number of spaces
111* tabs
112* LF line endings
113* CRLF line endings
114* a particular blank-line pattern
115* a particular brace style
116 
117Do not use whitespace as the primary matching strategy.
118 
119If an exact replacement depends on whitespace, re-read the file and choose a more stable anchor.
120 
121---
122 
123## 5. PREFER TARGETED EDITS
124 
125When modifying existing code, change only the lines necessary for the requested task.
126 
127Do not rewrite an entire function when one or two lines need changing.
128 
129Do not rewrite an entire file to fix a localized problem.
130 
131Do not reformat unrelated code.
132 
133Do not rename unrelated variables.
134 
135Do not "clean up" surrounding code unless explicitly requested.
136 
137---
138 
139## 6. NEVER RECONSTRUCT LARGE FILES FROM MEMORY
140 
141For files larger than approximately 150 lines:
142 
143* Do not reproduce the entire file in an edit operation.
144* Read the relevant section.
145* Modify only that section.
146* Preserve everything else exactly.
147 
148For files larger than approximately 300 lines:
149 
150* Work section-by-section.
151* Avoid whole-file replacements.
152* Verify each modification before continuing.
153 
154---
155 
156## 7. USE CODE STRUCTURE AS AN ANCHOR
157 
158When possible, identify code using:
159 
160* function names
161* variable names
162* unique strings
163* imports
164* class names
165* object properties
166* distinctive comments
167 
168Examples:
169 
170```text
171const promises =
172```
173 
174```text
175setupScene()
176```
177 
178```text
179category.planetModel
180```
181 
182```text
183assets[category.id]
184```
185 
186These are preferable to matching large blocks of formatted code.
187 
188---
189 
190## 8. AFTER EVERY EDIT, VERIFY
191 
192After making an edit:
193 
1941. Re-read the changed section.
1952. Confirm the intended change exists.
1963. Confirm surrounding code is intact.
1974. Check for syntax errors or obvious malformed structures.
198 
199For JavaScript/TypeScript projects, pay particular attention to:
200 
201* `{}` balance
202* `()` balance
203* `[]` balance
204* commas
205* semicolons where required
206* imports
207* exports
208* function closures
209* callback closures
210* template literals
211 
212Do not assume a successful tool response means the code is correct.
213 
214---
215 
216## 9. DO NOT CHAIN MANY UNVERIFIED EDITS
217 
218Use this cycle:
219 
220```text
221READ
222↓
223EDIT
224↓
225VERIFY
226↓
227NEXT EDIT
228```
229 
230Do NOT do:
231 
232```text
233EDIT
234EDIT
235EDIT
236EDIT
237EDIT
238VERIFY EVERYTHING
239```
240 
241If an early edit is wrong, subsequent edits can compound the problem.
242 
243---
244 
245## 10. KEEP EDIT OPERATIONS SMALL
246 
247For a normal coding task:
248 
249* Prefer 1–10 changed lines.
250* Avoid changing more than one logical area at a time.
251* Separate unrelated fixes.
252* Verify each logical change.
253 
254If a change genuinely requires a larger rewrite, explain why before doing it.
255 
256---
257 
258## 11. DO NOT OVERTHINK PATCH FAILURES
259 
260When a patch fails, do not spend multiple attempts theorizing about:
261 
262* hidden characters
263* indentation
264* encoding
265* line endings
266* trailing spaces
267 
268First inspect the actual file.
269 
270The file on disk is authoritative.
271 
272---
273 
274## 12. IF SEARCH/REPLACE FAILS TWICE
275 
276Stop.
277 
278Do not attempt a third increasingly complicated SEARCH block.
279 
280Instead:
281 
2821. Read the file again.
2832. Identify the smallest unique anchor.
2843. Use another available editing method.
2854. If no safe targeted editing method is available, report the exact blocker instead of repeatedly guessing.
286 
287Never burn tool calls repeatedly attempting the same failed operation.
288 
289---
290 
291## 13. PRESERVE USER CODE
292 
293Unless explicitly requested:
294 
295* Do not change unrelated code.
296* Do not change formatting globally.
297* Do not upgrade dependencies.
298* Do not rename files.
299* Do not rename variables.
300* Do not restructure components.
301* Do not change architecture.
302* Do not replace working implementations with "cleaner" alternatives.
303 
304The requested change takes priority over refactoring.
305 
306---
307 
308## 14. MINIMIZE CONTEXT
309 
310When working with a local model:
311 
312* Read only the files necessary for the current task.
313* Avoid loading huge unrelated files into context.
314* Avoid repeatedly pasting entire files into prompts.
315* Prefer focused code sections.
316* Keep tool requests precise.
317 
318If a file is large, inspect the relevant region rather than repeatedly reading the entire file.
319 
320---
321 
322## 15. DEBUGGING WORKFLOW
323 
324When fixing a bug:
325 
326### Step 1 — Identify
327 
328Determine the exact file and relevant function.
329 
330### Step 2 — Read
331 
332Read the current implementation from disk.
333 
334### Step 3 — Diagnose
335 
336Explain the likely cause briefly.
337 
338### Step 4 — Patch
339 
340Make the smallest change that addresses the cause.
341 
342### Step 5 — Verify
343 
344Read the changed code.
345 
346### Step 6 — Test
347 
348Run the appropriate project command if available.
349 
350### Step 7 — Report
351 
352State:
353 
354* what changed
355* what was verified
356* whether anything remains unresolved
357 
358---
359 
360## 16. THREE-FAILURE RULE
361 
362If the same operation fails three times:
363 
364STOP modifying the code.
365 
366Do not continue blindly.
367 
368Instead:
369 
370* inspect the file again
371* inspect the tool error
372* determine whether the problem is the edit method, file state, or model output
373* explain the blocker
374 
375Never enter an infinite retry loop.
376 
377---
378 
379## 17. JAVASCRIPT / THREE.JS PROJECTS
380 
381For Three.js code:
382 
383* Preserve existing scene architecture.
384* Do not recreate working loaders unnecessarily.
385* Do not replace working asset paths without evidence.
386* Do not modify camera, renderer, lighting, animation, or asset loading code unless relevant to the task.
387* Verify model-loading changes against the actual current implementation.
388* Preserve asynchronous behavior unless the requested fix requires changing it.
389 
390For asset-loading code, prefer modifying one loader operation at a time.
391 
392---
393 
394## 18. WHEN THE USER PROVIDES CODE
395 
396User-provided code is contextual evidence, not necessarily the current file.
397 
398If the task requires modifying the project:
399 
400* Inspect the actual project file.
401* Compare it with the supplied code.
402* Treat the file on disk as authoritative.
403 
404Never assume the supplied snippet is byte-for-byte identical to the current file.
405 
406---
407 
408## 19. LOCAL MODEL SAFETY RULE
409 
410When uncertain, inspect instead of guessing.
411 
412The preferred behavior is:
413 
414```text
415I need to verify the current file before editing.
416```
417 
418not:
419 
420```text
421I'll try another SEARCH block.
422```
423 
424Accuracy is more important than minimizing one read operation.
425 
426---
427 
428## 20. COMPLETION CRITERIA
429 
430Do not declare a task complete merely because an edit command succeeded.
431 
432A task is complete only when:
433 
434* The intended code change exists.
435* The surrounding code remains intact.
436* No obvious syntax errors were introduced.
437* The relevant application behavior has been tested when possible.
438* No repeated failed patch attempts remain unresolved.
439 
440---
441 
442## FINAL RULE
443 
444For local models, reliability beats cleverness.
445 
446READ → SMALL EDIT → VERIFY.
447 
448Never:
449 
450READ → GUESS → HUGE SEARCH/REPLACE → FAIL → BIGGER SEARCH/REPLACE → FAIL → REPEAT.
451