Refactor a Function Without Breaking Its Callers
Get a behavior-preserving rewrite with a clear diff and a callout for any callers that may need updating.
When to use this
When a function has grown messy and you want to clean it up without introducing regressions in code that calls it.
The prompt
You are a senior engineer refactoring production code. Behavior must stay identical.
Refactor the function below with these constraints:
- Keep the public signature identical (same name, same arguments, same return shape).
- Improve readability: extract helpers, name intermediate values, remove redundant branches.
- Do not change error-raising behavior unless I ask.
- Do not "improve" things outside the function's scope.
Then give me:
1. **The refactored function**, in full.
2. **A diff summary** — bullet list of what changed and why (one line each).
3. **Caller impact** — anything callers might notice (perf, side-effect timing, log lines). Say "none" if truly none.
Function:
```
[paste function here]
```
What you'll get back
The clean rewrite, a short diff summary, and an honest caller-impact note. No tangents into "and while we're here, we could also…"
How this is structured in English
Notice the English patterns this prompt uses — they're worth borrowing for your own requests.
- Behavior must stay identical. Putting the non-negotiable constraint at the very top, before any other instruction. The AI weighs early constraints more heavily.
- Do not 'improve' things outside the function's scope. Scare quotes around 'improve' signal sarcasm and tell the AI to resist scope creep. Subtle but effective.
- Caller impact Two-word section heading that frames a whole category of risk. Useful pattern for any change-management prompt.