GI

gitnexus-debugging

A diagnostic tool for troubleshooting errors and performance issues in the ChronosFlow system.

Install

mkdir -p .claude/skills/gitnexus-debugging && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/14675" && unzip -o skill.zip -d .claude/skills/gitnexus-debugging && rm skill.zip

Installs to .claude/skills/gitnexus-debugging

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

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\"
176 chars✓ has a “when” trigger
Intermediate

Key capabilities

  • →Identify the suspect area for a given symptom in ChronosFlow
  • →Trace incoming calls to a suspect method
  • →Verify architectural patterns like delegates or workers
  • →Read source files to confirm root causes
  • →Check relevant test files for expected behavior

How it works

The skill uses `gitnexus_query` to identify suspect areas based on symptoms and `gitnexus_context` to see callers and callees of a suspect. It then uses `gitnexus_cypher` for custom call chain traces.

Inputs & outputs

You give it
{ "query": "Focus timer broken", "repo": "ChronosFlow" }
You get back
Information about the suspect area, how to trace it, and relevant code patterns for debugging in ChronosFlow.

When to use gitnexus-debugging

  • →Trace why a focus timer session is failing
  • →Debug calendar sync import errors
  • →Investigate slow block edits in ChronosFlow

About this skill

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

Checklist

- [ ] Understand the symptom (error message, unexpected behavior)
- [ ] query for error text or related code
- [ ] Identify the suspect function from returned processes
- [ ] context to see callers and callees
- [ ] Trace execution flow via process resource if applicable
- [ ] cypher for custom call chain traces if needed
- [ ] Read source files to confirm root cause

Debugging Patterns

SymptomGitNexus Approach
Error messagequery for error text → context on throw sites
Wrong return valuecontext on the function → trace callees for data flow
Intermittent failurecontext → look for external calls, async deps
Performance issuecontext → find symbols with many callers (hot paths)
Recent regressiondetect_changes to see what your changes affect
"How does A reach B?"trace between the two symbols — shortest call chain in one call

Tools

query — find code related to error:

query({search_query: "payment validation error"})
→ Processes: CheckoutFlow, ErrorHandling
→ Symbols: validatePayment, handlePaymentError, PaymentException

context — full context for a suspect:

context({name: "validatePayment"})
→ Incoming calls: processCheckout, webhookHandler
→ Outgoing calls: verifyCard, fetchRates (external API!)
→ Processes: CheckoutFlow (step 3/7)

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

trace — shortest call chain between two symbols ("how does A reach B?"), one call instead of chaining context hops:

trace({ from: "processCheckout", to: "fetchRates" })
→ status: ok, hopCount: 3
→ hops: processCheckout → validatePayment → verifyCard → fetchRates
→ edges: CALLS (1.0), CALLS (0.95), CALLS (1.0)

When no path exists, trace reports the furthest reachable node — exactly where the chain breaks (dynamic dispatch, reflection, or an external boundary).

Example: "Payment endpoint returns 500 intermittently"

1. query({search_query: "payment error handling"})
   → Processes: CheckoutFlow, ErrorHandling
   → Symbols: validatePayment, handlePaymentError

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

When not to use it

  • →When the issue is not related to ChronosFlow
  • →When the user is asking for general code explanation not related to a bug
  • →When the user is asking to implement a new feature

Limitations

  • →Requires a Claude Code restart after `npx gitnexus analyze` for MCP server tools.
  • →The cheat sheet is specific to ChronosFlow.
  • →The skill relies on `gitnexus` commands and their functionality.

How it compares

This skill provides a structured, tool-assisted approach to debugging ChronosFlow issues by use GitNexus commands, rather than manual code inspection or generic search.

Compared to similar skills

gitnexus-debugging side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
gitnexus-debugging (this skill)03moNo flagsIntermediate
gh-fix-ci128moReviewIntermediate
git-master43moReviewAdvanced
find-bugs58moNo flagsIntermediate

Try saying

Example prompts that trigger this skill in your AI assistant.

Search skills

Search the agent skills registry