# Ask the codebase a product question

Say your role and a user action, and Claude Code walks you through what the product does from the interface down to the result, from the source.

Paste into: **Claude Code**, started in your project folder

## Prompt template

How the builder on the page fills in this template, so you can do the same:

- `{{key}}` becomes the text entered for that field, exactly as typed. Empty text, or text that is only whitespace (spaces, tabs or line breaks), counts as empty: a required field then becomes `[fill in: <label>]` with its label, and an optional field becomes nothing.
- For a choice field, `{{key}}` becomes the text of the chosen option, or of the default when none is chosen.
- Text between `{{#key}}` and `{{/key}}` stays only when that field is not empty; a choice field always counts as filled. The markers themselves are removed, and a marker that stands alone on its line takes its line break with it.
- Each value is inserted once, as it is: `{{…}}` inside a value stays as typed.

```text
I am a {{role}}. Walk me through what happens when a user {{action}}, from the UI down to the result.
{{#interest}}

In particular I want to know:
{{interest}}
{{/interest}}

Use {{detail}}. Answer from the source code, not from how the feature is supposed to work. Only read; do not change any files.

Structure the answer like this:
1. The steps in order, from the user's action to the final result, with what the user sees at each step.
2. The rules the code applies along the way: permissions, limits, validation, feature flags and defaults.
3. What happens when something fails, and what the user is told.
4. Anything that surprised you, or where the code seems to differ from what a user would expect.

Mark anything you inferred rather than read in the code. If part of the flow happens outside the code you can see, such as an external service or settings stored elsewhere, say so. If the action is ambiguous or matches more than one feature, ask me which one I mean before answering.
```

## Fields

- `{{role}}` (required): Your role. Claude pitches the explanation at this level.
- `{{action}}` (required): What the user does.
- `{{interest}}`: What you want to know in particular. Optional. Limits, failure cases, permissions or anything else you need answered.
- `{{detail}}`: Technical detail. Choose one:
  - plain language only, with file names collected at the end (default)
  - plain language, naming files and functions where that helps

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

## When to use this template

- You work on the product but do not read code, and you need to know what the product actually does today rather than what the original spec said.
- You are writing a spec, a help article or a support answer and want the real limits, defaults and error messages behind a feature.
- You want to answer a question yourself instead of interrupting an engineer, and you have Claude Code running in the repository.

## When not to use it

- The answer depends on live data or production settings, such as how many users hit a limit. Claude Code reads the code, not your production database, unless you have connected it to one.
- You need a decision about how the feature should work. This prompt explains what the code does now; the decision belongs to the team.
- You are in a plain chat without access to the repository. Claude would describe how such a feature usually works, not how yours does.

## Why this structure

- Stating your role first sets the level of the explanation, so you do not get a tour of function names when you wanted the product behavior.
- The user action is phrased the way a user would describe it, and the prompt asks for the path from the interface down to the result, which matches how a product question is usually asked.
- Saying "from the source code, not from how the feature is supposed to work" keeps the answer grounded in the current code rather than in general knowledge about similar products.
- Points 2 and 3 ask for rules and failure cases, which are the details product and support work most often needs and the ones a quick demo does not show.
- Marking inferences, flagging what happens outside the visible code and asking which feature you mean keep a non-technical reader from taking a guess as a fact.

## Example input (fictional)

Your role:

```
product manager
```

What the user does:

```
clicks Export to PDF on a report
```

What you want to know in particular:

```
What happens with very large reports, and what the user sees if the export fails.
```

Technical detail:

```
plain language only, with file names collected at the end
```

## Follow-ups to send Claude

- Write this up as a one-page explanation for the support team, with the error messages users can see.
- Where does the code differ from the behavior described in the help center article I am pasting next? List each difference.
- Which of these rules can be changed in settings without a code change, and where are those settings?

## Common mistakes

- Describing the action vaguely, such as "exports something". Name the screen and the button so Claude follows the right flow.
- Treating the answer as a description of production. Feature flags and settings can make the live product behave differently; check point 2 for the ones Claude found.
- Asking for plain language and then quoting it to engineers as a specification. Use the detail setting with file names when the answer will feed into engineering work.

## Related templates

- [Get oriented in a new codebase](https://awesomeclaudeprompts.com/prompts/codebase-overview/): Ask Claude Code to map an unfamiliar repository: its architecture, key directories, how the parts connect, and where to start for your task.
- [Explain a concept](https://awesomeclaudeprompts.com/prompts/explain-concept/): Get a concept explained at your level, in the format that helps you most, with a quick self-check and the common misconceptions.
- [Scope a change before you start](https://awesomeclaudeprompts.com/prompts/scope-a-change/): Ask Claude Code which files a change would touch and how big it is, so you can size the work before it goes on a roadmap or into a sprint.

## Sources

- [Claude Code docs: Prompt library](https://code.claude.com/docs/en/prompt-library) (Anthropic documentation)
- [How Anthropic teams use Claude Code](https://claude.com/blog/how-anthropic-teams-use-claude-code) (Anthropic documentation)
- [Claude Code best practices: Ask codebase questions](https://code.claude.com/docs/en/best-practices#ask-codebase-questions) (Anthropic documentation)

---

Awesome Claude Prompts is an independent project. It is not affiliated with, endorsed by, or sponsored by Anthropic. Claude is a trademark of Anthropic, PBC.