Refactoring prompt template

Paste this into a chat window and replace each {{variable}}, or open it in the prompt builder to fill them in a form. Sections are marked with XML tags, which every major model reads well.

You are a senior {{language}} engineer who refactors in small, safe steps and keeps behaviour identical.

<context>
<code>
{{code}}
</code>
</context>

<constraints>
- Preserve the public interface: names, parameters, return values, errors raised and side effects, unless the goal says otherwise.
- Make the minimum change that achieves the goal. Don’t add abstractions, options or files that the goal doesn’t need.
- Keep the project’s existing conventions: {{conventions}}.
- If a step could change behaviour (error order, evaluation order, floating-point results, timing), flag it instead of doing it silently.
</constraints>

<output_format>
The refactored code in one block. Then a numbered list of the changes, one line each, with any risky step marked “check:”.
</output_format>

<task>
Refactor this code to {{goal}}. Keep its behaviour exactly the same for every caller.
</task>

You are a senior {{language}} engineer who refactors in small, safe steps and keeps behaviour identical.

<constraints>
- Preserve the public interface: names, parameters, return values, errors raised and side effects, unless the goal says otherwise.
- Make the minimum change that achieves the goal. Don’t add abstractions, options or files that the goal doesn’t need.
- Keep the project’s existing conventions: {{conventions}}.
- If a step could change behaviour (error order, evaluation order, floating-point results, timing), flag it instead of doing it silently.
</constraints>

<output_format>
The refactored code in one block. Then a numbered list of the changes, one line each, with any risky step marked “check:”.
</output_format>

<context>
<code>
{{code}}
</code>
</context>

<task>
Refactor this code to {{goal}}. Keep its behaviour exactly the same for every caller.
</task>

{{language}}

The language, such as Java or Python.

{{code}}

The code to refactor. Include its callers if the interface might change.

{{goal}}

One concrete goal, such as “split the 200-line handler into functions that can be tested separately” or “remove the duplicated retry logic”. One goal per run works far better than “clean this up”.

{{conventions}}

Rules from your codebase the result must follow, such as “dataclasses, not dicts; no new dependencies”. Write “none in particular” if you have none.

{{language}}

Python

{{code}}

def price(order):
    if order["country"] == "GB":
        tax = order["subtotal"] * 0.2
    elif order["country"] == "DE":
        tax = order["subtotal"] * 0.19
    elif order["country"] == "FR":
        tax = order["subtotal"] * 0.2
    else:
        tax = 0
    return round(order["subtotal"] + tax, 2)

{{goal}}

replace the country conditional with a lookup table so new countries are a one-line change

{{conventions}}

type hints on public functions; no new dependencies

What to look for. A careful result uses a dict of rates with a default of 0 and keeps the final round exactly where it was. Moving the rounding, or rounding the tax separately, would change some totals by a penny, which is the kind of step the template asks to be flagged.

You are a senior Python engineer who refactors in small, safe steps and keeps behaviour identical.

<context>
<code>
def price(order):
    if order["country"] == "GB":
        tax = order["subtotal"] * 0.2
    elif order["country"] == "DE":
        tax = order["subtotal"] * 0.19
    elif order["country"] == "FR":
        tax = order["subtotal"] * 0.2
    else:
        tax = 0
    return round(order["subtotal"] + tax, 2)
</code>
</context>

<constraints>
- Preserve the public interface: names, parameters, return values, errors raised and side effects, unless the goal says otherwise.
- Make the minimum change that achieves the goal. Don’t add abstractions, options or files that the goal doesn’t need.
- Keep the project’s existing conventions: type hints on public functions; no new dependencies.
- If a step could change behaviour (error order, evaluation order, floating-point results, timing), flag it instead of doing it silently.
</constraints>

<output_format>
The refactored code in one block. Then a numbered list of the changes, one line each, with any risky step marked “check:”.
</output_format>

<task>
Refactor this code to replace the country conditional with a lookup table so new countries are a one-line change. Keep its behaviour exactly the same for every caller.
</task>

• Claude

  Anthropic’s guide reports that Claude Opus 4.5 and 4.6 can overengineer and suggests asking for minimal changes. If you’re on those models and see new helper classes appear, repeat the minimal-change rule in stronger terms.

• OpenAI GPT

  Non-reasoning GPT models need very precise instructions, according to OpenAI’s guide. Spell out the goal as an end state (“each function under 30 lines”) rather than a direction (“make it shorter”).

• All models

  Compare the before and after with the prompt diff or your usual diff tool, and run the tests. A refactor that changes behaviour is a bug, however tidy it looks.

• Write unit testsTests for normal cases, edge cases and errors in your framework, focused on behaviour rather than implementation.
• Code reviewReview a diff for bugs, risky changes and missing tests, ranked by severity with line references.
• Convert code to another languageTranslate code idiomatically into another language, map libraries, and list every behaviour difference.

Edited the template? Compare your version with this one in the prompt diff, and count it for your model with the token counter. Browse all 29 prompt templates.