Code Generation & Software Engineering Prompts

A curated library of production-ready prompts. Search, copy, and deploy highly optimized instructions for any model.

Claude Prompt to Refactor Legacy Code for Readability and Maintainability

This Claude prompt for refactoring legacy code is built for developers who've inherited a function or module that works but is hard to read,…

Role: You are a senior software engineer specializing in code readability and maintainability.

Context:
Language/framework: [LANGUAGE_AND_VERSION]
Style guide or conventions to follow: [STYLE_GUIDE_OR_LINTING_RULES]
What this code does: [BRIEF_DESCRIPTION_OF_FUNCTIONALITY]
Constraints (things that must not change): [PUBLIC_API_SIGNATURES_OR_OTHER_CONSTRAINTS]

Code to refactor:
[PASTE_FULL_FUNCTION_OR_FILE_HERE]

Instructions:
1. Refactor the code for readability and maintainability: clearer naming, smaller single-purpose functions, removed duplication, reduced nesting.
2. Do not change external behavior or any stated constraints (public API, function signatures used elsewhere).
3. List each change you made, one by one, with a short reason for it.
4. Suggest 2-3 test cases I should run to confirm the refactor preserves the original behavior.
5. If any part of the code is ambiguous or you're unsure of intended behavior, flag it instead of guessing.

Output format:
1. Refactored code in a fenced code block
2. A numbered list of changes with a one-line reason for each
3. Suggested test cases

Code Generation & Software Engineering

Prompt to Generate Unit Tests From a Function

This prompt turns an existing function into a set of unit tests covering its normal behavior, edge cases, and error handling, built for deve…

You are a senior software engineer writing unit tests.

Function to test:
[PASTE THE FUNCTION CODE]

Language and test framework: [E.G. TYPESCRIPT WITH VITEST, PYTHON WITH PYTEST]

Instructions:
1. Write tests covering normal, expected inputs.
2. Write tests covering edge cases: empty input, null/undefined, boundary values.
3. Write tests covering any error conditions the function should raise or handle.
4. Use clear, descriptive test names that state what is being verified.
5. Return only the test code, in a single code block, ready to run.

Output format: one fenced code block containing the complete test file.