Good code explanation prompts tell the model who the explanation is for, give it the real code (or let an agent read the repo), and ask for a fixed output such as a summary, a step-by-step walkthrough and a list of risks, each tied to line numbers. Below are 13 code explanation prompts for ChatGPT, Claude, Claude Code and Codex, from touring a new repository to explaining a single dense line, reading git history and teaching code to someone else.
How to use these prompts
Copy a prompt, replace each blank in double braces, or keep the default after the colon. {{language:TypeScript}} means TypeScript unless you change it.
Three habits make explanations much more reliable:
- Say who it's for. "A new hire who knows Python but not Django" gets a very different answer from "a senior engineer on this team".
- Ask for evidence. Line numbers, function names and file paths turn a confident paragraph into something you can check.
- Give the surrounding code. A function makes more sense with the types it uses and the code that calls it.
In an agent such as Claude Code or Codex, skip the pasting and name the files. The Claude Code docs on understanding new codebases suggest starting with broad questions, then narrowing to specific areas, and asking for a glossary of project terms. The first three prompts follow that order.
For the general dev workflow, see the coding prompts. This page goes deeper on understanding code you didn't write.
How do you get an overview of a new codebase?
1. Tour a new repository
The first prompt to run on day one. It works best in an agent that can open files and read the build scripts.
I just joined this project. Give me a tour of the repository for
{{role:a backend developer}}.
1. What the project does, in two sentences.
2. How to install, run and test it locally, from the scripts and config.
3. The top-level folders, one line each, and which ones I can ignore.
4. The main entry points (server start, CLI, jobs, UI routes).
5. The three files I should read first, and why.
Only describe what you can see in the files. Mark guesses with "Unsure:".
2. Build a glossary of project terms
Every codebase has words that mean something specific inside it. A glossary saves weeks of confusion.
Read {{scope:the models, types and database schema}} and build a glossary
of the domain terms this project uses.
For each term: the name as it appears in code, a plain-language definition,
where it is defined (file and line), and any synonyms the code uses for the
same thing. Flag terms that look like they mean different things in
different places.
3. Draw how the pieces connect
A diagram helps when a request passes through several layers. GitHub renders Mermaid diagrams placed in a fenced code block tagged mermaid, so the output can go straight into a README or pull request.
Draw a {{diagram:Mermaid sequence diagram}} of what happens when
{{action:a user submits the checkout form}}.
Show each component that takes part (UI, API route, services, queues,
database, third-party calls) in the order they run. Label each arrow with
the function or endpoint called. Below the diagram, list the files involved
and anything that runs asynchronously.
How do you explain a single function or file?
4. Explain at three levels of detail
Useful when you're not sure how deep you need to go. You read the first level, and only continue if you need to.
Explain this {{language:TypeScript}} code at three levels.
Level 1: one sentence on what it does and why it exists.
Level 2: a short paragraph covering inputs, outputs and side effects
(network, disk, database, global state).
Level 3: a walkthrough in order, citing line numbers, for someone who
needs to change it.
Audience: {{audience:a developer who is new to this codebase}}.
{{code}}
5. Annotate code for learning
When you want to study the code itself rather than read a summary. The rule against changing code keeps the output safe to diff.
Add explanatory comments to this {{language:Python}} code so a
{{audience:junior developer}} can learn from it.
Rules:
- Do not change any code, only add comments.
- Explain why each block exists, not just what it does.
- Call out idioms, library calls and patterns a beginner might not know.
- Mark anything that looks like a bug with "POSSIBLE BUG:".
{{code}}
6. Unpack a dense line
For one-liners, chained calls, bit manipulation and clever expressions that are hard to read.
Explain this {{language:JavaScript}} expression piece by piece.
{{expression}}
Break it into its smallest parts and show the value after each step for
this example input: {{example_input}}. Then rewrite it as plain, readable
code with the same behavior, and say whether the readable version has any
performance cost.
7. Trace a real input through the code
Explanations stay abstract until you follow one concrete value. A table of variable values is easy to check against a debugger.
Trace this input through the code below, step by step.
Input: {{input}}
{{code}}
Give a table with one row per step: line number, what runs, and the value
of each relevant variable after that line. Note every branch taken and
why. End with the final return value or side effect.
8. Explain a construct by comparing it to one you know
When you know one language or framework well and are reading another.
I know {{known:Python and Django}} well. Explain this
{{unfamiliar:Rust}} code by mapping each construct to its closest
equivalent in what I know.
Where there is no real equivalent (for example, ownership or lifetimes),
say so clearly and explain the new idea in its own terms instead of forcing
a comparison.
{{code}}
9. Explain every setting in a config file
Config files are full of options nobody remembers adding. This finds the ones that matter.
Explain each setting in this {{config:tsconfig.json}} file.
For every key: what it does, the default if it were removed, and whether
it looks deliberate or copied from a template. Then list the settings
that most affect {{concern:build output and type safety}}, and any that
conflict with each other.
{{file}}
How do you find out why code was written this way?
10. Read the history of a function
The code shows what it does. The history shows why. Git's git log -L :<funcname>:<file> traces the evolution of a function or line range and prints each change as a patch.
Below is the output of git log -L for the function {{function}} in
{{file}}. It lists every commit that changed this function, with messages
and diffs.
Summarize how the function evolved: the original purpose, each meaningful
change and the reason given in the commit message. Separate what the
history shows from what you are inferring. Point out any change that looks
like a fix for a specific bug or incident.
{{git_log_output}}
11. Find the reason behind odd-looking code
Before deleting a strange check or workaround, find out what it protects against. Git's git log -S finds commits that change the number of occurrences of a string, which is a fast way to find when a line first appeared.
This code looks unnecessary to me:
{{suspicious_code}}
Context (surrounding code, commit messages, linked issues):
{{context}}
What problem might it be solving? Give the most likely reasons, ranked,
with the evidence for each. Tell me what to check (tests, logs, issue
tracker, a specific input) before I remove it, and what would break if
I'm wrong.
How do you explain code to other people?
12. Explain a change to a non-technical stakeholder
For product managers, support teams or anyone who needs to know what changed without reading code.
Explain what this code change does for {{audience:a product manager}}.
Cover: what users will notice, what they won't notice but matters (speed,
reliability, security), any risk, and anything support should know. No
jargon; if a technical term is unavoidable, define it in a few words. Keep
it under {{length:150 words}}.
{{diff_or_description}}
13. Check your understanding with a quiz
Explanations feel clear while you read them. A quiz shows whether anything stuck.
I've been studying this code. Write {{count:5}} questions that test whether
I really understand it, not just whether I read it: what happens with an
unusual input, what breaks if a line is removed, why a design choice was
made. Wait for my answers before giving yours, then grade each one and
explain what I missed.
{{code}}
How do you check that an AI explanation is right?
Models explain code fluently even when they misread it. These checks catch most errors:
| Check | How |
|---|---|
| Claims point at real code | Ask for line numbers and open each one |
| The trace is correct | Run the code with the same input, or step through it in a debugger |
| Edge cases are real | Turn "returns empty on null" into a one-line test |
| History claims hold up | Read the commits yourself; ask the model to quote the message it relied on |
| Nothing is invented | Search the repo for every function name the explanation mentions |
If an explanation is wrong, paste the evidence back into the same conversation. The model corrects itself much faster with the real output in front of it. Once you understand the code, the documentation prompts help you write it down, and the refactoring prompts help you change it safely.
Turn your favorite one into a skill
If you onboard onto new codebases often, the repository tour and glossary prompts make good skills: Claude Code or Codex can apply them whenever you ask to understand a project. Paste one into the free SKILL.md generator to get a valid SKILL.md. For more on working with agents in a large repo, see Claude Code best practices.
Kipt keeps prompts like these as Markdown in a private GitHub repo you own. Blanks like {{audience:a junior developer}} stay fillable, Cmd+K finds any prompt, and skills you save there install into Claude Code or Codex with one command.