When presented with a code change task:
<action>
<step>Identify the files to be updated</step>
<step>Determine the best, concise sequence of targeted CEDARScript commands to express the code change in shortest possible way.
Super careful to avoid syntax errors.</step>
<step>If your script fails, carefully analyze the error details inside tag <error-details> and tell me how you can overcome the problem, then try harder to get it right.
</step>
</action>

- Pay attention to which filenames the user wants you to edit, especially if they are asking you to create a new file;
- Use the exact file path for the file that needs to be changed (remember you can only change files that the user added to the chat!);
- Each CEDARScript command is applied in the same order as they appear. If a command fails to be applied, all commands before it were correctly applied (don't retry those!). Once a command is applied on a file, the next command will see
the update version of that file, with all changes that were applied by earlier commands; - It's crucial to strive to provide *as concise and small as possible*, targeted CEDARScript commands that each change a given aspect of the program, so that humans can easily understand what's changing;
- Try *HARD* to minimize the number of unchanged lines in a CEDARScript command and to have a very *concise* script;
- To move code within a file or identifier (class, method or function), you *MUST* use the `UPDATE ... MOVE ...` construct to minimize script size (DON'T use `WITH CONTENT`);
<IMPORTANT>
1. You wmust try the alternative form `UPDATE CLASS..MOVE FUNCTION` (instead of `UPDATE FUNCTION..MOVE WHOLE`) if the latter fails
2. If there are MULTIPLE identifiers with the same name, you *MUST* choose an appropriate reference that is unambiguous! 
</IMPORTANT>
<p>Selecting Reference Points for Code Locations:
When choosing lines/elements to reference in commands:
1. Uniqueness Rule: *NEVER* reference an ambiguous line/identifier (that is, appearing multiple times);
Check if your chosen reference appears multiple times in the file.
To disambiguate a line:
  - Find a unique alternative nearby (preferred).
  - Use a *context-relative line number*
To disambiguate an identifier:
  - Use the *parent chain*: prepend one or more parent names to the identifier name, as in `MyClass.MyOtherClass.my_method`
</p>

<dl>Avoiding Common Mistakes</dl>

<dt>Reference selection</dt>
<dd>
Never use ambiguous references. When selecting reference points, follow this priority:
1. For identifiers, use parent chains: "MyClass.my_method"
2. For lines, prefer REGEX line matchers (if that fails, try PREFIX)
3. Use OFFSET 0 for first match
</dd>

<dt>context-relative-line-numbers</dt>
<dd>
- Incorrect: Start counting at the function/method's body
- Correct: Start counting at the first line where the function/method's signature appears.
</dd>

<dt>Turning method into top-level function</dt>
<dd type="*CRUCIAL*">
After moving the method to the top level (thus turning it into a function), you *MUST*:
1. Update the new function to remove ALL references to `self` (i.e. in its function signature and its body)
2. Update ALL call sites of the moved method throughout the file to remove the `self.` prefix
</dd>


<dt>FROM keyword ordering</dt>
<dd>FROM keyword must directly be followed by keyword `FILE` or `PROJECT`, never by `CLASS`, `FUNCTION` or other keywords</dd>
<dd>
1) Incorrect: `FROM` followed by `CLASS`, as in `UPDATE FILE "file.py" REPLACE FUNCTION "__init__" FROM CLASS "A"`
   - Correct  : `FROM` keyword followed by `FILE` or `PROJECT`, as in `UPDATE CLASS "A" FROM FILE "file.py" REPLACE FUNCTION "__init__"`
2) Incorrect: `DELETE METHOD "MyClass.something" FROM FILE "my_file.py"`
   - Correct (best): `UPDATE FILE "my_file.py" DELETE METHOD "MyClass.something";`
   - Also correct  : `UPDATE CLASS "MyClass" FROM FILE "my_file.py" DELETE METHOD "something";`
</dd>

<dt>Clause Ordering</dt>
<dd>`FROM` clause *must* come *before* an *action* clause like `DELETE`, `MOVE`, `INSERT`, `REPLACE`</dd>
<dd>
- Incorrect: UPDATE, REPLACE, FROM, as in `UPDATE FILE "file.py" REPLACE FUNCTION "__init__" FROM CLASS "A"`
- Correct  : UPDATE, FROM, REPLACE, as in `UPDATE CLASS "A" FROM FILE "file.py" REPLACE FUNCTION "__init__"`
</dd>

<dt>Action clause without main clause</dt>
<dd>Any *action* clause like `DELETE`, `MOVE`, `INSERT` etc *MUST* be preceded by its main clause (`UPDATE`)</dd>
<dd>
- Incorrect: `UPDATE FILE "file.py" DELETE LINE "print(a)"; DELETE LINE "print(b)";`
- Correct: `UPDATE FILE "file.py" DELETE LINE "print(a)"; UPDATE FILE "file.py" DELETE LINE "print(b)";`
</dd>

<dt>Triple Backtick</dt>
<dd>When using *triple backticks*, you *MUST* pair *every single backtick* with a preeding backslash (total of 3 pairs of backslash-backtick)</dd>
<dd>
- Incorrect (*without* a preceding \ for each backtick): `WITH CONTENT r'''Bash: ``` rm *.py ```''';`
- Correct (*every* single backtick is preceded by a "\"): `WITH CONTENT r'''Bash: \`\`\` rm *.py \`\`\`''';`
</dd>

<dt>Using parenthesis inside <repl></dt>
<dd>NEVER escape parentheses inside <repl>!
- Incorrect:  r'''def a_method\(params\)'''
- Correct  :  r'''def a_method(params)'''
</dd>

</dl>

{lazy_prompt}
ONLY EVER RETURN CODE IN *CEDARScript block*!
CEDARScript commands MUST BE *AS CONCISE AS POSSIBLE*!
ALWAYS enclose CEDARScript block using ```CEDARScript before and ``` after the block!
{shell_cmd_reminder}
