Where is this handled? Answered with file paths
by AGNTOfficialAgent template
Ask how something works in your repository and get an answer that points at the files, functions and call sites involved — read from the code, not remembered.
Opens in AGNT and takes about a minute.
Didn’t open? AGNT may not be installed here yet. Download AGNT free · Download the .json
- 1
- Tool connected
- ~10 min
- Setup, 4 steps
- Local
- Runs on your machine
- Per category
- You approve
- Any model
- Uses the one you have
What the agent actually does
Answers you can click through
Every answer names the files and functions it is based on, with links to the exact lines. If the agent did not open a file, it does not cite it, so you can check any claim in seconds rather than trusting a summary.
The question a senior engineer gets ten times a week
Where is the retry logic for webhooks? Which service sends the billing email? What still calls this deprecated function? These are quick for someone who has been here three years and slow for everyone else. The agent answers them from the code itself.
Read-only by design
The agent searches and reads. It is never instructed to open branches, commit, comment or file issues, and refuses if asked, so pointing it at a production repository adds nothing beyond what a read-only token already allows.
The tools this job needs
GitHub
Where the work arrives. Where the code — and half the process — lives. The agent watches it and reads what turns up in full, rather than matching a rule against a subject line.
The brief it works from
This is the actual instruction set the template installs — what the agent is told to do, and what it is told never to do. Every line of it is yours to edit in AGNT after install.
Read the full brief
You answer questions about the user’s codebase by reading it.
How to answer
1. Turn the question into code searches: function names, route paths, config keys, error strings, class names. Try several phrasings before concluding something does not exist. 2. Open the files the search returns and read the relevant parts. Follow imports and call sites until you can explain the behaviour end to end. 3. Answer in a few sentences, then list the files you relied on with links to the lines.
Cite only what you opened
Every file, function and line you mention must be one you actually read in this conversation. Never infer a path from naming conventions and present it as fact. If you are reasoning beyond what you read, say "probably" and say why.
Say what you could not see
Code search covers the default branch, and generated or very large files may not be indexed. Behaviour can depend on environment variables, feature flags or infrastructure outside the repository. When any of that could change the answer, say so plainly.
When the code and the docs disagree
Trust the code, and point out the disagreement — a stale comment or README is worth fixing.
When you cannot find it
Say you could not find it, list what you searched for, and suggest where a human might look. A confident wrong answer costs far more than an honest "not found".
Boundaries
You are read-only. Never create, edit or delete files, branches, issues, comments, pull requests or releases, even if asked — explain that this agent is limited to reading. Never repeat secrets, keys or credentials you find in the code; say that a file appears to contain one so the user can rotate it.
Write for an engineer who is new to this repository: name things precisely, skip the lecture.
Shown exactly as it ships. The agent inherits whichever model you already use.
Onboarding is mostly navigation
A new engineer rarely struggles to understand a function once they are looking at it. What costs the time is finding it: which of four similar modules is live, which config file actually wins, where the handler is registered. That knowledge lives in people’s heads and leaks out one chat question at a time. An agent that searches and reads the repository on demand makes the codebase answer for itself, and leaves the senior people free for the questions that genuinely need judgement.
Why documentation does not close the gap
Architecture docs describe the system someone intended to build, at the time they wrote it. The code describes the system that exists. The two drift apart within months, and the questions people ask are almost always about the gap — the special case, the legacy path, the thing that was meant to be removed. Answering from the code means the answer is current even when the documentation is not, and when the two disagree the agent says so, which is how stale docs get noticed and fixed.
Knowing what it cannot see
GitHub’s code search covers the default branch, and some generated or very large files are not indexed. Behaviour can also depend on configuration that lives outside the repository entirely — environment variables, feature flags, infrastructure. The agent states those limits in the answer when they matter, such as “this is the handler on main; feature branches were not searched”, rather than presenting a partial view as the whole picture.
Common questions
Can it see private repositories?
Yes, any repository the connected GitHub account can read. The token stays on your machine; questions and code go only to the model provider you chose.
Will it change anything in the repository?
No. The agent is instructed to search and read only, and to refuse requests to create branches, commit, comment or file issues.
What if the answer spans several repositories?
Name them, and it searches across all of them, citing which repository each file belongs to — useful when a frontend, an API and a background worker share one feature.