Menu
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"
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when the user needs to run GitNexus CLI commands like analyze/index a repo, check status, clean the index, generate a wiki, or list indexed repos. Examples: "Index this repo", "Reanalyze the codebase", "Generate a wiki"
Use when the user wants to review a pull request, understand what a PR changes, assess risk of merging, or check for missing test coverage. Examples: "Review this PR", "What does PR #42 change?", "Is this PR safe to merge?"
Use when the user needs to run GitNexus CLI commands like analyze/index a repo, check status, clean the index, generate a wiki, or list indexed repos. Examples: "Index this repo", "Reanalyze the codebase", "Generate a wiki"
Use when the user asks how code works, wants to understand architecture, trace execution flows, or explore unfamiliar parts of the codebase. Examples: "How does X work?", "What calls this function?", "Show me the auth flow"
Use when the user asks about GitNexus itself โ available tools, how to query the knowledge graph, MCP resources, graph schema, or workflow reference. Examples: "What GitNexus tools are available?", "How do I use GitNexus?"
Use when the user wants to know what will break if they change something, or needs safety analysis before editing code. Examples: "Is it safe to change X?", "What depends on this?", "What will break?"
| 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" |
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 analyzein terminal.
- [ ] 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
| 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 |
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:
MATCH path = (a)-[:CodeRelation {type: 'CALLS'}*1..2]->(b:Function {name: "validatePayment"})
RETURN [n IN nodes(path) | n.name] AS chain
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