Awesome Claude Prompts Unofficial

Find where something happens in the code

Describe a behavior and let Claude Code find the code that does it, with file paths, the path that leads there and any duplicate implementations.

Task: Find where something happens in the code · Other tasks

Fill in the details

Describe what the code does, in the words the project uses. You do not need a file name.

Optional. A hint about the area, or places you already checked.

Copy your prompt

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

1 required field is empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

When to use this template

  • You know what the product does but not where in the code it does it, and you have no idea which file or folder holds that logic.
  • You are about to change a behavior and want to be sure you have found every place that implements it, not just the first match.
  • A search for an obvious keyword returns too many results, or none, and you want a search guided by what the code actually does.

When not to use it

  • You already know the file and want to understand it. Use the template for explaining unfamiliar code instead.
  • The behavior lives outside the repository, for example in a hosted service or a database trigger Claude Code cannot see. Claude can find where the code calls out, but not what happens on the other side.
  • You are in a plain chat without access to the project. Claude cannot search files it cannot open there.

Why this structure

  • The opening question describes a behavior rather than a file name, so the search still works when you have no idea what the code is called.
  • The optional hint narrows the search when you already know the rough area, and asks Claude to skip places you have ruled out.
  • Point 2 asks for the path from the entry point, because knowing where the code is matters less than knowing when it runs and what calls it.
  • Point 3 asks for other places that do the same thing. Duplicate or partial implementations are a common reason a change works in one place and not another.
  • The closing paragraph covers the two awkward outcomes, no match and several matches, so Claude reports them openly instead of presenting a guess as the answer.

Example input (fictional)

The behavior you are looking for
validate uploaded file types
What you already know
It happens before the file reaches storage, probably in the API layer.

Follow-ups to send Claude

  • Explain how the main location works and what data it receives, step by step.
  • The two implementations behave differently. Which one is correct according to the tests, and what would it take to make them consistent?
  • Add a test that pins the current behavior at the main location before I change it.

Common mistakes

  • Describing the behavior in your own words when the project uses different ones. Use the names from the product or the codebase, such as the model or feature name.
  • Stopping at the first match. Ask for every place that does the same thing before you change one of them.
  • Assuming the code Claude found is the code that runs. Check the entry point it names, and look at feature flags or config that might switch to another path.

See all templates

Sources