Explain code prompt template

Paste this into a chat window and replace each {{variable}}, or open it in the prompt builder to fill them in a form. Sections are marked with XML tags, which every major model reads well.

You are a patient senior engineer explaining code to a colleague who is {{audience}}.

<context>
<code>
{{code}}
</code>
</context>

<constraints>
- Start with the purpose in one or two sentences before any detail.
- Explain the flow in the order it runs, not line by line. Group lines that do one job.
- Point out side effects (I/O, network, global state, mutation of arguments) and anything surprising: implicit conversions, error handling that swallows failures, order-dependent behaviour.
- If the purpose isn’t clear from the code alone, say what you would need to know rather than guessing.
- Match the depth to the reader. Define a term the first time you use it if they might not know it.
</constraints>

<output_format>
Short paragraphs with a few headings: Purpose, How it works, Side effects, Watch out for. Quote identifiers in backticks. No more than about 400 words unless the code needs it.
</output_format>

<task>
Explain what this code does and how it works, so the reader could safely change it. Focus on {{focus}}.
</task>

You are a patient senior engineer explaining code to a colleague who is {{audience}}.

<constraints>
- Start with the purpose in one or two sentences before any detail.
- Explain the flow in the order it runs, not line by line. Group lines that do one job.
- Point out side effects (I/O, network, global state, mutation of arguments) and anything surprising: implicit conversions, error handling that swallows failures, order-dependent behaviour.
- If the purpose isn’t clear from the code alone, say what you would need to know rather than guessing.
- Match the depth to the reader. Define a term the first time you use it if they might not know it.
</constraints>

<output_format>
Short paragraphs with a few headings: Purpose, How it works, Side effects, Watch out for. Quote identifiers in backticks. No more than about 400 words unless the code needs it.
</output_format>

<context>
<code>
{{code}}
</code>
</context>

<task>
Explain what this code does and how it works, so the reader could safely change it. Focus on {{focus}}.
</task>

{{audience}}

Who is reading, such as “new to Rust but experienced in Python” or “a product manager”. It sets the depth and vocabulary.

{{code}}

The function, file or snippet to explain. Include imports and type definitions it relies on when you can.

{{focus}}

What you need from the explanation, such as “how errors are handled” or “why it’s slow”. Use “the overall behaviour” if you have no specific question.

{{audience}}

comfortable with JavaScript but new to Go

{{code}}

func (c *Cache) Get(key string) (string, bool) {
	c.mu.RLock()
	e, ok := c.items[key]
	c.mu.RUnlock()
	if !ok || time.Now().After(e.expires) {
		return "", false
	}
	return e.value, true
}

{{focus}}

why there is a lock and what the two return values mean

What to look for. A good answer explains the read lock in terms a JavaScript developer recognises (Go runs goroutines in parallel, so a map can be read and written at the same time), explains Go’s comma-ok idiom, and points out that expired entries are never deleted here, which is a real trap for someone about to change the code.

You are a patient senior engineer explaining code to a colleague who is comfortable with JavaScript but new to Go.

<context>
<code>
func (c *Cache) Get(key string) (string, bool) {
	c.mu.RLock()
	e, ok := c.items[key]
	c.mu.RUnlock()
	if !ok || time.Now().After(e.expires) {
		return "", false
	}
	return e.value, true
}
</code>
</context>

<constraints>
- Start with the purpose in one or two sentences before any detail.
- Explain the flow in the order it runs, not line by line. Group lines that do one job.
- Point out side effects (I/O, network, global state, mutation of arguments) and anything surprising: implicit conversions, error handling that swallows failures, order-dependent behaviour.
- If the purpose isn’t clear from the code alone, say what you would need to know rather than guessing.
- Match the depth to the reader. Define a term the first time you use it if they might not know it.
</constraints>

<output_format>
Short paragraphs with a few headings: Purpose, How it works, Side effects, Watch out for. Quote identifiers in backticks. No more than about 400 words unless the code needs it.
</output_format>

<task>
Explain what this code does and how it works, so the reader could safely change it. Focus on why there is a lock and what the two return values mean.
</task>

• Gemini

  Gemini’s prompting guide recommends always including examples. If you explain code often for the same team, add one short example of an explanation in your house style; keep its format identical to what you want back.

• OpenAI GPT

  OpenAI’s reasoning models avoid Markdown unless asked, from o1-2024-12-17 on. Since this format uses headings, add “Formatting re-enabled” on the first line of the developer message if you call a reasoning model through the API.

• All models

  For a whole repository, explain one entry point at a time. Context windows are large, but an explanation of everything at once is rarely one you can act on.

• Write docstrings and code commentsDocstrings in your project’s style covering parameters, returns, errors and the non-obvious why.
• Refactor codeRestructure code toward one stated goal without changing behaviour, with risky steps flagged.
• Debug from a stack traceRank likely root causes from an error and stack trace, say what to check first, and suggest the smallest fix.

Edited the template? Compare your version with this one in the prompt diff, and count it for your model with the token counter. In the glossary: system prompt. Browse all 29 prompt templates.