home / skills / adibfirman / dotfiles / gitnexus-debugging

gitnexus-debugging skill

/claude/.claude/skills/gitnexus-debugging

This skill helps you debug failures by tracing error sources with gitnexus queries, contexts, and cypher traces to pinpoint root causes quickly.

npx playbooks add skill adibfirman/dotfiles --skill gitnexus-debugging

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.2 KB
---
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

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

Overview

This skill helps you debug bugs, trace errors, and find the root cause of failing code paths using GitNexus tools. It connects error symptoms to execution flows, shows callers and callees for suspect symbols, and lets you trace processes and custom call chains. Use it to turn an error message or intermittent failure into a concrete investigation plan.

How this skill works

Run targeted queries for error text or symptoms to discover related processes and symbols. Inspect a suspect with context to see incoming and outgoing calls, then read process traces or run custom cypher traces to follow execution paths. If the index is stale, refresh analysis (e.g., npx gitnexus analyze) before querying.

When to use it

  • You get an error message and need to know where it originates
  • A function returns wrong data or behaves unexpectedly
  • An endpoint returns 500 or another HTTP error intermittently
  • You must find who calls a method or what a method calls
  • You want to trace a regression to recent changes

Best practices

  • Start by clearly capturing the symptom (exact error text, stack, or failing input)
  • Run gitnexus_query for the error text, then pick the most relevant symbol or process
  • Use gitnexus_context on suspects to reveal callers, callees, and external dependencies
  • Trace process flows via READ gitnexus://repo/.../process/... before inspecting source files
  • Use gitnexus_cypher for tailored call-chain queries when default traces miss relationships

Example use cases

  • Investigate a 500 from the payment endpoint: query error text → inspect validatePayment → find external fetchRates without timeout
  • Track down a wrong return value by starting with the function name, view callers to see upstream data sources
  • Diagnose intermittent failures by looking for external calls or async dependencies in context
  • Find who calls a deprecated helper to plan safe removal or refactor
  • Map hot paths for a performance issue by finding symbols with many callers

FAQ

What if gitnexus_query returns no results?

Confirm the exact error text and try broader keywords; refresh the index with npx gitnexus analyze if the repository has changed.

When should I use gitnexus_cypher?

Use custom cypher when you need a specific call-chain pattern or multi-hop relationships not shown by standard traces.

How do I verify the root cause after tracing?

Read the implicated source files, reproduce the failure locally with the same inputs, and add logging or tests to confirm the fix.