When you want Claude to change existing code, specificity is the most important ingredient. To refactor, state the goal explicitly: "Refactor this function to use async/await instead of callbacks" or "Extract this logic into a separate helper function." To direct the assistant toward consistency with the rest of the project, anchor it to a reference: "Match the coding style used in [filename]" or "Follow the same patterns as the existing [controllers/services/models]." For language-specific polish, "Rewrite this in idiomatic [Python/Go/TypeScript] following language best practices and community conventions" pushes Claude away from generic, translated code. For tangled logic, ask "This function is too complex. Break it into smaller, single-responsibility functions, keeping the public interface the same."
For bug fixes, the most effective prompts describe the symptom and the expected behavior: "This function returns null when the user has no orders, but it should return an empty array instead." To add a new feature, give Claude enough context to make good decisions: "Add a [feature] to [component] that [behavior]. It should work like [example] and follow the existing patterns in [reference file]." When creating a new file, the prompt "Create [filename] with [specific content/structure]. It should [behavior/purpose] and follow the conventions in [reference file]" produces output that fits the surrounding code. For boilerplate, the same shape applies: "Generate a [component/class/module] boilerplate for [purpose] following the same structure as [existing example file]." Specialized transformations each have canonical prompts, such as "Convert this synchronous [function/module] to async/await, handling errors properly and preserving all existing behavior" and "Add TypeScript types / type hints to [file], ensuring all function signatures, return types, and variable declarations are typed."
For larger or higher-risk refactors, control the workflow by asking Claude to plan before acting: "Before making any changes, explain exactly what you plan to do and why, then wait for my confirmation." For especially ambitious work, use "First read [files], then plan the refactor, explain the approach, and only start changing code after I approve the plan." You can also invite a dialogue with "Before writing any code, ask me the questions you need answered to implement [feature] correctly," or have Claude surface its reasoning up front with "Before implementing, explain your approach, the key decisions you'll make, and any alternatives you considered." Other useful patterns include "Implement [feature] defensively: validate all inputs at boundaries, handle all error cases explicitly, and never trust external data," "Suggest more descriptive names for these variables: [list]. The names should clearly express intent without abbreviation," and "Write a regex that matches [pattern description] and test it against these examples: [valid examples] vs [invalid examples]." For version control hiccups, "I have a merge conflict in [file]. Read the conflict markers and resolve it by [keeping feature/applying both changes/choosing the correct version]" gives Claude the context it needs to make the right call. Smaller design questions, such as choosing a data structure, fit the same pattern: "I need to store [data type] with [operations needed]. What data structure would be most efficient and why?" Finally, for new standalone programs, "Create a CLI tool in [language] that [behavior]. It should accept [flags/arguments] and output [format]" produces a working starting point.