# GitNexus Debugging

Traces a bug or error through a code graph to explain why something fails.

- Repository: https://github.com/abhigyanpatwari/GitNexus (48173 stars)
- Category: Engineering
- License: see repository
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add abhigyanpatwari/GitNexus --skill gitnexus-debugging -g -a claude-code -y`
Codex: `npx skills add abhigyanpatwari/GitNexus --skill gitnexus-debugging -g -a codex -y`
Cursor: `npx skills add abhigyanpatwari/GitNexus --skill gitnexus-debugging -g -a cursor -y`
Gemini CLI: `npx skills add abhigyanpatwari/GitNexus --skill gitnexus-debugging -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add abhigyanpatwari/GitNexus`

## 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\

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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.

Bind once using a confirmed registry name/path or configured MCP default. Call
`list_repos {}` if the target is not yet known; reuse that binding across calls. 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. Bind the repo once (list_repos only if not already known)
1. If the suspect is unknown, query for the error/symptom with small result limits
2. context({name: "<suspect>"})                    → See callers/callees/processes
3. Read a process resource only if its trace resolves an open question
4. cypher({statement: "MATCH path..."})                 → Custom traces if needed
```

> If "Index is stale" → run `node .gitnexus/run.cjs analyze` in terminal.
> Hot-tool `staleness` names which index answered (`branch`/`lastCommit`) and how fresh it is (`status`). Re-analyze only for `behind` or `diverged`, `current` is identity, `unknown` is unmeasurable.

## Checklist

The rest: https://github.com/abhigyanpatwari/GitNexus/blob/HEAD/gitnexus-claude-plugin/skills/gitnexus-debugging/SKILL.md