Refine coder prompt

[JonasHelming]

fixed #15357

What it does

Improve Coder prompt.
Clarifies, that the changes are presented in a diff to the user. Otherwise, some LLMs tend to avoid search/replace, as they assume it i hard to read for the user.

How to test

Reset the Coder prompt and check that this sentence is there:
"The changes will be presented as a applicable diff to the user in any case."

Follow-ups

Breaking changes

• This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Attribution

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[colin-grant-work]

The phrase 'applicable diff' doesn't seem very natural to me. Although applicable < apply, it's almost only used to mean 'relevant.'

Maybe

Regardless of replacement method, the changes will be presented to the user in a comparative diff view highlighting changed regions.

[JonasHelming]

4o says:

Here's a summary of the instructions, key points, and how I would choose between the functions:

---

🔍 Understanding the Instructions

There are two functions used to propose file changes to the user:

• ~{changeSet_replaceContentInFile}:
  Replaces content within a file (likely at a line or pattern level).

• ~{changeSet_writeChangeToFile}:
  Writes or rewrites the full content of a file.

Both functions result in a diff being shown to the user, regardless of which is used.

---

✅ Important Points

1. Only One Final Call per File:
   Each function call overrides previous ones on the same file. So, exactly one successful call per file is required to represent all the proposed changes.

2. Diff Will Be Presented Anyway:
   No matter which function is used, the end result for the user is a diff they can review and apply.

3. Fallback Strategy:

   • Use ~{changeSet_replaceContentInFile} by default.

   • If it fails repeatedly, switch to ~{changeSet_writeChangeToFile}.

---

🤔 How I Would Choose Between the Functions

Situation | Function to Use | Reason -- | -- | -- Small, targeted edits (e.g. changing a line, fixing typos, updating a method) | ~{changeSet_replaceContentInFile} | It's more precise and efficient for small edits. replaceContentInFile fails repeatedly (e.g. can't find the pattern) | ~{changeSet_writeChangeToFile} | Ensures changes still get proposed even if pattern matching is unreliable. Making large-scale edits (e.g. replacing the entire content, restructuring) | ~{changeSet_writeChangeToFile} | More practical and safer for large or ambiguous changes.

---

[JonasHelming]

Claude:

Based on the instructions provided, I understand you're asking about two functions for proposing file changes:

~{changeSet_writeChangeToFile}: Used to propose file changes to users
~{changeSet_replaceContentInFile}: Also used to propose file changes to users

Key points about using these functions:

Both functions allow you to suggest modifications to files
If ~{changeSet_replaceContentInFile} repeatedly fails, you should switch to using ~{changeSet_writeChangeToFile} as a fallback
When you call either function on a file, it will override any previous function calls on that same file
You need exactly one successful call with all proposed changes per file you want to modify
Regardless of which function you use, the changes will be presented to the user as an applicable diff (showing the differences between original and modified content)
You should consolidate all changes for a single file into one function call rather than making multiple calls for the same file

Would you like me to explain more about how to choose between these functions or provide more specific guidance on when to use each one?

[JonasHelming]

We have evaluate the current version in practise, so if it is not "wrong" from your POV, I would go with it now and imporve the wording later, but we should first evaluate any new wording