The prompt
Score 10 of 10, Excellent
Use it when You have inherited code you did not write and need to understand what it really does before touching it.
- {{language}}
- {{file_path}}
- {{code}}
- {{related_context}}
- {{planned_change}}
Full prompt and why it works
System prompt
You are a patient senior engineer explaining code to a colleague who knows {{language}} well but is new to this codebase.
User message
<code path="{{file_path}}"> {{code}} </code> <related_context> {{related_context}} </related_context> I need to change this code to {{planned_change}}, and I want to understand it first. Explain it in this order: 1. Purpose: what this code is for, in 2 to 3 sentences, in terms of what it does for the rest of the system. 2. Walkthrough: the main path through the code, step by step, naming functions and line numbers. Skip boilerplate. 3. Inputs, outputs and side effects: what it reads, returns, writes, calls or changes, including anything global, cached or sent over the network. 4. Gotchas: assumptions, edge cases, gaps in error handling, and surprising behavior that someone changing it should know about. 5. Where my change fits: the part I will most likely need to touch, and what could break if I do. Write in prose and short lists, under 600 words in total. Quote short snippets of the code where it helps. Describe what the code actually does, not what its names or comments claim. Where the two differ, point it out, because that is where bugs hide. The explanation should be accurate enough that I could predict what the code returns for a given input. Do not suggest rewrites unless something is clearly broken. If the behavior depends on code you cannot see, say so and state the assumption you are making, for example "Assuming save() writes to the database before it returns, ...".
Variables
- {{language}}
- The language and framework, for example "TypeScript with React".
- {{file_path}}
- The file's path, so the explanation can refer to it.
- {{code}}
- The code to explain, with line numbers if your editor can copy them.
- {{related_context}}
- Anything that helps: the caller, the types, a README section. Leave it empty if you have nothing.
- {{planned_change}}
- What you intend to change, in one sentence.
Why it works
- Who it's for. Stating the change you plan to make focuses the explanation on the parts you will touch and what they could break.
- What good looks like. It asks for what the code does rather than what its names claim, and sets a bar you can check: you could predict its output.
- If unsure. Behavior that depends on code the model cannot see is stated as an explicit assumption you can verify.