Code review & debugging21 categories
Plan for touching legacy code
You need to change something nobody understands and there are no tests.
I need to change this code. It is old, has no tests, and I am not confident about what depends on it. Help me do it safely: 1. What does this code appear to guarantee to its callers? What might they rely on that isn't obvious? 2. What characterisation tests should I write *first*, to lock in current behaviour before I change anything? 3. What is the smallest change that achieves my goal? 4. What is the order of operations that keeps it working at every step? 5. What should I watch after deploying to know whether I broke something? Code: What I need to change:
Making it yours
- Paste your own material where the prompt asks for it. Everything above that line is instruction, not content.
- Delete any rule that does not apply to you. A shorter prompt that fits beats a thorough one that does not.
- If the answer comes back vague, add a line saying what you do not want. Constraints work better than encouragement.
Understanding code you inherited. Making sense of an unfamiliar file, line or regex before you dare change it.
Related prompts
Explain this unfamiliar codeInherited a file and need to understand it before touching it.Explain this lineA single line you keep re-reading without it landing.What is this regex doing?A regex you inherited and are afraid to touch.What breaks if I delete this?Code that looks dead but you don't trust the search results.Review this diff, correctness firstThe default review pass before you merge anything.Try to prove this code wrongWhen a review came back clean and you don't believe it.
Keep this one
Phrasery saves prompts with a right-click and puts them back the same way. Add this to your own library in one click.
Add to your browser — free