
Gitnexus Debugging
Trace failures across a Git-indexed codebase with GitNexus queries, context, and Cypher when an error message or 500 needs a root cause fast.
Overview
GitNexus Debugging is an agent skill most often used in Operate (also Ship) that traces bugs and errors through GitNexus query, context, process, and Cypher workflows.
Install
npx skills add https://github.com/abhigyanpatwari/gitnexus --skill gitnexus-debuggingWhat is this skill?
- 4-step workflow: gitnexus_query → gitnexus_context → process resource → optional gitnexus_cypher
- 7-item debugging checklist from symptom to source confirmation
- Symptom table mapping (500s, call chains, “who calls this”) to GitNexus approaches
- Stale index remediation via `npx gitnexus analyze`
- Supports custom call-chain traces with Cypher when defaults are insufficient
- 4-step GitNexus debugging workflow
Adoption & trust: 805 installs on skills.sh; 41.7k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You see a failure or 500 but cannot quickly see which functions and call paths in the repo actually lead to the error.
Who is it for?
Repos already indexed with GitNexus where errors, unexpected behavior, or call-graph questions come up during fixes or incident triage.
Skip if: Greenfield projects with no GitNexus index, or purely runtime/infra issues with no code path in the analyzed repo.
When should I use this skill?
When the user is debugging a bug, tracing an error, or asking why something fails (e.g. “Why is X failing?”, “Trace this bug”).
What do I get? / Deliverables
You get a traced suspect chain from GitNexus through to confirmed source reads—re-run analyze if the index was stale before declaring root cause.
- Suspect function(s) and caller/callee context from GitNexus
- Execution flow trace via process resource or Cypher
- Root-cause confirmation with cited source files
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Debugging production and dev failures maps to Operate → Errors as the canonical shelf, even though the same workflow helps during Ship review. Errors subphase fits symptom-driven investigation: query by error text, walk callers/callees, and confirm root cause in source files.
Where it fits
User reports a 500 on checkout; agent queries the error string, contexts the handler, and traces callers to a bad validation branch.
CI fails on an integration test; agent uses gitnexus_context on the suspect service method before opening a PR fix.
While wiring a webhook, agent asks who calls the new callback to avoid duplicate side effects.
How it compares
Use alongside generic debugging chat by requiring graph-backed queries first—skill package tied to GitNexus tools, not a standalone MCP listing.
Common Questions / FAQ
Who is gitnexus-debugging for?
Solo builders and small teams on Claude Code or Cursor who use GitNexus as a code graph and want a fixed trace workflow for bugs and stack-like questions.
When should I use gitnexus-debugging?
In Operate when production errors or regressions appear, during Ship review when tests fail mysteriously, or in Build when integrating unfamiliar call paths—whenever “why is X failing?” needs repo-wide tracing.
Is gitnexus-debugging safe to install?
It implies local analyze and graph queries over your repository; review the Security Audits panel on this Prism page and treat repo access like any dev tool with filesystem and network scope.
SKILL.md
READMESKILL.md - Gitnexus Debugging
# 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 ## Workflow ``` 1. gitnexus_query({query: "<error or symptom>"}) → Find related execution flows 2. gitnexus_context({name: "<suspect>"}) → See callers/callees/processes 3. READ gitnexus://repo/{name}/process/{name} → Trace execution flow 4. gitnexus_cypher({query: "MATCH path..."}) → Custom traces if needed ``` > If "Index is stale" → run `npx gitnexus analyze` in terminal. ## Checklist ``` - [ ] Understand the symptom (error message, unexpected behavior) - [ ] gitnexus_query for error text or related code - [ ] Identify the suspect function from returned processes - [ ] gitnexus_context to see callers and callees - [ ] Trace execution flow via process resource if applicable - [ ] gitnexus_cypher for custom call chain traces if needed - [ ] Read source files to confirm root cause ``` ## Debugging Patterns | Symptom | GitNexus Approach | | -------------------- | ---------------------------------------------------------- | | Error message | `gitnexus_query` for error text → `context` on throw sites | | Wrong return value | `context` on the function → trace callees for data flow | | Intermittent failure | `context` → look for external calls, async deps | | Performance issue | `context` → find symbols with many callers (hot paths) | | Recent regression | `detect_changes` to see what your changes affect | ## Tools **gitnexus_query** — find code related to error: ``` gitnexus_query({query: "payment validation error"}) → Processes: CheckoutFlow, ErrorHandling → Symbols: validatePayment, handlePaymentError, PaymentException ``` **gitnexus_context** — full context for a suspect: ``` gitnexus_context({name: "validatePayment"}) → Incoming calls: processCheckout, webhookHandler → Outgoing calls: verifyCard, fetchRates (external API!) → Processes: CheckoutFlow (step 3/7) ``` **gitnexus_cypher** — custom call chain traces: ```cypher MATCH path = (a)-[:CodeRelation {type: 'CALLS'}*1..2]->(b:Function {name: "validatePayment"}) RETURN [n IN nodes(path) | n.name] AS chain ``` ## Example: "Payment endpoint returns 500 intermittently" ``` 1. gitnexus_query({query: "payment error handling"}) → Processes: CheckoutFlow, ErrorHandling → Symbols: validatePayment, handlePaymentError 2. gitnexus_context({name: "validatePayment"}) → Outgoing calls: verifyCard, fetchRates (external API!) 3. READ gitnexus://repo/my-app/process/CheckoutFlow → Step 3: validatePayment → calls fetchRates (external) 4. Root cause: fetchRates calls external API without proper timeout ``` { "mcpServers": { "gitnexus": { "command": "npx", "args": ["-y", "gitnexus@latest", "mcp"] } } }