Before changing anything, it often pays to ask Claude to read the existing code. A simple "Read [filename] and explain what it does" or just "Read [filename]" gets Claude oriented, after which you can drill in with follow-up questions. For specific functions, the prompt "Read [file:line_number] and explain what this function does, including its inputs, outputs, and side effects" produces a focused explanation. To find where a symbol or pattern is used, ask "Find all places where [function/variable/pattern] is used" or "Search for files containing [keyword]."
When the codebase is unfamiliar, prompts that invite summarization are especially effective. "Explain the design patterns used in this codebase, why they were chosen, and how they interact with each other" turns Claude into a tutor. You can also test its understanding with "In your own words, explain how [feature/system] works based on the code. Then identify any gaps or potential issues." When chasing a bug, "Walk me through how data flows from [input] to [output] in this code, and identify where [bug symptom] could originate" is a powerful way to surface the root cause without randomly editing files.
For error messages, the best practice is to paste the full text directly into the prompt: "I'm getting this error: [paste error]. What does it mean and how do I fix it?" This gives Claude everything it needs to interpret the message and suggest concrete next steps. The same principle of providing full context applies whether the error is from a tool, a test runner, or a runtime exception.