skills/gitnexus-exploring/SKILL.md
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"
npx skillsauth add shysssthanhtri/AI-tools gitnexus-exploringInstall 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. READ gitnexus://repos → Discover indexed repos
2. READ gitnexus://repo/{name}/context → Codebase overview, check staleness
3. gitnexus_query({query: "<what you want to understand>"}) → Find related execution flows
4. gitnexus_context({name: "<symbol>"}) → Deep dive on specific symbol
5. READ gitnexus://repo/{name}/process/{name} → Trace full execution flow
If step 2 says "Index is stale" → run
npx gitnexus analyzein terminal.
- [ ] READ gitnexus://repo/{name}/context
- [ ] gitnexus_query for the concept you want to understand
- [ ] Review returned processes (execution flows)
- [ ] gitnexus_context on key symbols for callers/callees
- [ ] READ process resource for full execution traces
- [ ] Read source files for implementation details
| Resource | What you get |
| --------------------------------------- | ------------------------------------------------------- |
| gitnexus://repo/{name}/context | Stats, staleness warning (~150 tokens) |
| gitnexus://repo/{name}/clusters | All functional areas with cohesion scores (~300 tokens) |
| gitnexus://repo/{name}/cluster/{name} | Area members with file paths (~500 tokens) |
| gitnexus://repo/{name}/process/{name} | Step-by-step execution trace (~200 tokens) |
gitnexus_query — find execution flows related to a concept:
gitnexus_query({query: "payment processing"})
→ Processes: CheckoutFlow, RefundFlow, WebhookHandler
→ Symbols grouped by flow with file locations
gitnexus_context — 360-degree view of a symbol:
gitnexus_context({name: "validateUser"})
→ Incoming calls: loginHandler, apiMiddleware
→ Outgoing calls: checkToken, getUserById
→ Processes: LoginFlow (step 2/5), TokenRefresh (step 1/3)
1. READ gitnexus://repo/my-app/context → 918 symbols, 45 processes
2. gitnexus_query({query: "payment processing"})
→ CheckoutFlow: processPayment → validateCard → chargeStripe
→ RefundFlow: initiateRefund → calculateRefund → processRefund
3. gitnexus_context({name: "processPayment"})
→ Incoming: checkoutHandler, webhookHandler
→ Outgoing: validateCard, chargeStripe, saveTransaction
4. Read src/payments/processor.ts for implementation details
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>/.