AI Prompts for Cursor for Code Refactoring

Read this file and identify the top five refactoring opportunities, ranked by impact and risk. For each opportunity, describe: what is wrong with the current code, what the improved version would look like, and the risk level of making this change. Do not make any changes yet. File: [PASTE FILE CONTENTS].

Analyze the files I have open and identify any logic that is duplicated or nearly duplicated across multiple places. For each duplication, tell me: where it appears, what the extracted abstraction should look like, and whether the differences between versions are meaningful or just incidental. I will review the list before deciding what to extract.

Review this file and flag any functions or methods that violate the single responsibility principle. For each flagged function, explain what responsibilities it currently has and how you would split it into smaller, focused functions. Do not refactor yet, just give me the analysis: [PASTE FILE].

I want to refactor [DESCRIBE THE CODE AREA OR FEATURE]. Before we change anything, create a refactoring plan that lists: (1) the changes to make in order of dependency, (2) which changes are safe to make independently versus which depend on others, (3) what tests I should run after each step to verify nothing broke. I want a clear sequence before we begin.

Read this file and flag any variable, function, or class names that are unclear, misleading, or inconsistent with the naming conventions in the rest of the code. For each one, suggest a better name and explain why the current name is problematic. Do not make changes, just produce the list: [PASTE FILE].

Extract the following code block into a separate, well-named function. The extracted function should: have a descriptive name that makes its purpose obvious, take only the inputs it needs, return a clear output, and have a JSDoc or equivalent comment if the logic is non-obvious. Show the extracted function and the updated call site: [PASTE CODE BLOCK].

Simplify this conditional logic without changing its behavior. Options to consider: extracting conditions into well-named boolean variables, using early returns instead of deep nesting, replacing chained conditionals with a lookup table or map, or restructuring the logic to be easier to follow. Show the before and after with a brief explanation of what you changed: [PASTE CONDITIONAL].

These code blocks are doing nearly the same thing in multiple places: [PASTE EXAMPLES]. Create a single reusable function or component that covers all cases. Show the abstraction and all the updated call sites. Flag any differences between the current versions that the abstraction needs to handle.

Update this code to use current [LANGUAGE/FRAMEWORK] patterns and syntax without changing its behavior. Specific patterns to apply where appropriate: [LIST, e.g. async/await instead of callbacks, optional chaining, destructuring, const/let instead of var, arrow functions, template literals]. Show the modernized version and note each change made: [PASTE CODE].

Improve the error handling in this function. The current version: [DESCRIBE CURRENT BEHAVIOR]. It should: handle each failure mode explicitly rather than letting errors propagate silently, use descriptive error messages that include the relevant context, and either throw with full context or return a typed error result depending on the pattern used elsewhere in this codebase. Refactored function: [PASTE FUNCTION].

Before I refactor this function, write a test suite that captures its current behavior so I can verify the refactored version behaves identically. Include: the happy path, edge cases, and any currently untested scenarios you can infer from the implementation. Use [TEST FRAMEWORK]. Function to test: [PASTE FUNCTION].

Here is the original code: [PASTE ORIGINAL]. Here is the refactored version: [PASTE REFACTORED]. Verify that these are logically equivalent by: tracing through at least three distinct inputs, checking that all edge cases are handled the same way, and flagging any paths through the original that the refactored version handles differently. Tell me if they are equivalent or where they diverge.

I have refactored [FUNCTION NAME]. Before it was: [PASTE ORIGINAL]. Now it is: [PASTE REFACTORED]. Identify all the places in the codebase where this function is called and check whether the refactored version is a drop-in replacement. Flag any call sites that may behave differently because of: changed parameter signatures, different return values, or modified error behavior.

Review this refactored code for any issues introduced by the change. Look for: new edge cases that were not present in the original, performance regressions, type errors or implicit coercion issues, and anything that would not be caught by the existing tests. Refactored code: [PASTE]. Original code for comparison: [PASTE].

Write the pull request description for this refactoring change. Include: what changed and why, what the behavior before and after is (identical for pure refactoring), what tests were run or added, and what a reviewer should focus on. Keep it factual and brief. Changes made: [DESCRIBE OR PASTE DIFF SUMMARY].

I refactored [FUNCTION A] to use this pattern: [PASTE REFACTORED VERSION]. Find all other functions in this file that follow the same old pattern and apply the same refactoring to each. Show each refactored function separately so I can review them one at a time. File: [PASTE FILE].

Apply this naming convention to the entire file: [DESCRIBE CONVENTION, e.g. camelCase for variables, PascalCase for components, SCREAMING_SNAKE_CASE for constants, verb-first for function names]. Show every rename needed and the updated file. Do not change any logic, only names: [PASTE FILE].

Write a brief Architecture Decision Record (ADR) for this refactoring decision. The decision: [DESCRIBE WHAT YOU CHANGED AND WHY]. Format: title, context (why a decision was needed), decision (what was chosen), consequences (what improves, what trade-offs exist). Keep it under 200 words so it is actually read.

Based on the refactoring we just completed, write a brief coding standards note I can add to CLAUDE.md or a team wiki. It should describe: the pattern we are now using, the pattern it replaces, and a short code example of each so future contributors know what to follow. Keep it concise and practical.

Based on the refactoring work we did today, what should be the priority for the next refactoring session in this codebase? Look at what we changed, what we decided not to change, and what other parts of the code have similar issues. Give me a prioritized list of the next five things to tackle, with a one-sentence rationale for each priority.