skills/gitnexus-debugging/SKILL.md
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"
npx skillsauth add shysssthanhtri/AI-tools gitnexus-debuggingInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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
testing
Execute an existing Jira ticket implementation plan phase by phase. Use when asked to "work on ticket CM-1234", "implement the plan for CM-1234", "start working on the plan", or "execute the next phase". Reads the plan from docs/<ticket-id>/plan.md, captures a pre-implementation full test baseline in plan/progress docs, presents each phase for user approval before coding, updates progress after each phase, and operates inside the dedicated git worktree. After the last phase is committed, runs the full test suite, fixes regressions (skipping known pre-existing failures), then presents a full change summary for user review and creates a GitHub draft PR using the create-draft-pr skill.
tools
Generate a complete MCP server project in TypeScript with tools, resources, and proper configuration
tools
Use when starting work on a Jira ticket. Fetches ticket details via Atlassian MCP (for branch naming and a local story snapshot), creates an isolated git worktree with branch feature/<ticket-id>-<slug>-<platform>, and writes docs/<ticket-id>/<ticket-id>.md in the worktree.
documentation
Create a work plan for a Jira ticket. Use when asked to plan work, create a plan for a ticket, break down a Jira issue, or prepare implementation steps for a Jira ticket ID like CM-1234. Reads local ticket details, deeply analyzes requirements and root causes, proposes up to three optimized solutions (not workarounds) with pros and cons, asks the user to choose, then finalizes the plan with that choice under docs/<ticket-id>/.