| name | gitnexus-debugging |
| description | Use when the user is debugging a bug, tracing an error, or asking why something fails. Examples: "Why is X failing?", "Where does this error come from?", "Trace this bug" |
Debugging with GitNexus
When to Use
- "Why is this function failing?"
- "Trace where this error comes from"
- "Who calls this method?"
- "This endpoint returns 500"
- Investigating bugs, errors, or unexpected behavior
Bind the repository first
A root cause traced in the wrong repository is a wrong root cause.
Call list_repos {} before the first tool call. With one indexed repository,
use the examples below as written. With more than one, pass repo on every
call: an omitted repo normally errors, but under an MCP policy with a
configured default it resolves to that default silently. If you cannot tell
which repository is meant, stop and ask. This matters most for cypher, whose
statement carries no in-band hint of which database it ran against.
list_repos is paginated, so page with offset: pagination.nextOffset until
hasMore is false before concluding a repository is absent.
A stale index describes the code from before your bug, so refresh before
trusting a trace, and state the repository and index freshness with the
diagnosis.
Workflow
0. list_repos {} → Bind repo
1. query({search_query: "<error or symptom>"}) → Find related execution flows
2. context({name: "<suspect>"}) → See callers/callees/processes
3. READ gitnexus://repo/{name}/process/{name} → Trace execution flow
4. cypher({statement: "MATCH path..."}) → Custom traces if needed
If "Index is stale" → run node .gitnexus/run.cjs analyze in terminal.