gitnexus-debugging

用于调试代码错误、追踪异常来源及分析失败原因。通过查询相关执行流、查看函数调用上下文及使用自定义Cypher语句，定位根因并确认修复方案。

用户询问某功能为何失败需要追踪错误来源调查Bug或意外行为分析特定端点返回错误

skills/gitnexus-debugging/SKILL.md

npx skills add tintinweb/pi-gitnexus --skill gitnexus-debugging -g -y

SKILL.md

Frontmatter

{
    "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. gitnexus_cypher({query: "MATCH path..."})         → Custom traces if needed
4. Read source files to confirm root cause

If index is stale → run /gitnexus analyze to rebuild.

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	`gitnexus_detect_changes` to see what your changes affect

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
- [ ] gitnexus_cypher for custom call chain traces if needed
- [ ] Read source files to confirm root cause

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:

gitnexus_cypher({query: "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. Root cause: fetchRates calls external API without proper timeout

gitnexus-exploring

用于探索和理解代码库架构、执行流程及未熟悉代码的 Skill。通过查询概念、深入特定符号上下文及自定义图查询，帮助用户理清函数调用关系和项目结构。

询问代码工作原理或架构追踪执行流程探索不熟悉的功能模块查找函数调用者或被调用者

skills/gitnexus-exploring/SKILL.md

View Skill ›

npx skills add tintinweb/pi-gitnexus --skill gitnexus-exploring -g -y

SKILL.md

Frontmatter

{
    "name": "gitnexus-exploring",
    "description": "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\""
}

Exploring Codebases with GitNexus

When to Use

"How does authentication work?"
"What's the project structure?"
"Show me the main components"
"Where is the database logic?"
Understanding code you haven't seen before

Workflow

1. gitnexus_list_repos()                                   → Discover indexed repos
2. gitnexus_query({query: "<what you want to understand>"}) → Find related execution flows
3. gitnexus_context({name: "<symbol>"})                     → Deep dive on specific symbol
4. Read source files for implementation details

If index is stale → run /gitnexus analyze to rebuild.

Checklist

- [ ] gitnexus_query for the concept you want to understand
- [ ] Review returned processes (execution flows)
- [ ] gitnexus_context on key symbols for callers/callees
- [ ] Read source files for implementation details

Tools

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)

gitnexus_cypher — custom graph queries for deeper exploration:

gitnexus_cypher({query: "MATCH (f:Function)-[:CodeRelation {type: 'CALLS'}]->(g) WHERE f.name = 'main' RETURN g.name, g.filePath"})

Example: "How does payment processing work?"

1. gitnexus_query({query: "payment processing"})
   → CheckoutFlow: processPayment → validateCard → chargeStripe
   → RefundFlow: initiateRefund → calculateRefund → processRefund

2. gitnexus_context({name: "processPayment"})
   → Incoming: checkoutHandler, webhookHandler
   → Outgoing: validateCard, chargeStripe, saveTransaction

3. Read src/payments/processor.ts for implementation details

gitnexus-impact-analysis

用于代码修改前的安全分析，评估变更影响范围。通过上游依赖查询和Git差异检测，识别潜在破坏点并分级风险（低/中/高/关键），辅助用户决策是否提交或测试。

询问修改某功能是否安全想知道修改X会导致什么后果查看代码的爆炸半径谁使用了这段代码进行非平凡代码更改前提交代码前检查影响

skills/gitnexus-impact-analysis/SKILL.md

View Skill ›

npx skills add tintinweb/pi-gitnexus --skill gitnexus-impact-analysis -g -y

SKILL.md

Frontmatter

{
    "name": "gitnexus-impact-analysis",
    "description": "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?\""
}

Impact Analysis with GitNexus

When to Use

"Is it safe to change this function?"
"What will break if I modify X?"
"Show me the blast radius"
"Who uses this code?"
Before making non-trivial code changes
Before committing — to understand what your changes affect

Workflow

1. gitnexus_impact({target: "X", direction: "upstream"})  → What depends on this
2. gitnexus_detect_changes()                               → Map current git changes to affected flows
3. Assess risk and report to user

If index is stale → run /gitnexus analyze to rebuild.

Understanding Output

Depth	Risk Level	Meaning
d=1	WILL BREAK	Direct callers/importers
d=2	LIKELY AFFECTED	Indirect dependencies
d=3	MAY NEED TESTING	Transitive effects

Risk Assessment

Affected	Risk
<5 symbols, few processes	LOW
5-15 symbols, 2-5 processes	MEDIUM
>15 symbols or many processes	HIGH
Critical path (auth, payments)	CRITICAL

Checklist

- [ ] gitnexus_impact({target, direction: "upstream"}) to find dependents
- [ ] Review d=1 items first (these WILL BREAK)
- [ ] Check high-confidence (>0.8) dependencies
- [ ] gitnexus_detect_changes() for pre-commit check
- [ ] Assess risk level and report to user

Tools

gitnexus_impact — primary tool for symbol blast radius:

gitnexus_impact({
  target: "validateUser",
  direction: "upstream",
  minConfidence: 0.8,
  maxDepth: 3
})

→ d=1 (WILL BREAK):
  - loginHandler (src/auth/login.ts:42) [CALLS, 100%]
  - apiMiddleware (src/api/middleware.ts:15) [CALLS, 100%]

→ d=2 (LIKELY AFFECTED):
  - authRouter (src/routes/auth.ts:22) [CALLS, 95%]

gitnexus_detect_changes — git-diff based impact analysis:

gitnexus_detect_changes({scope: "staged"})

→ Changed: 5 symbols in 3 files
→ Affected: LoginFlow, TokenRefresh, APIMiddlewarePipeline
→ Risk: MEDIUM

Example: "What breaks if I change validateUser?"

1. gitnexus_impact({target: "validateUser", direction: "upstream"})
   → d=1: loginHandler, apiMiddleware (WILL BREAK)
   → d=2: authRouter, sessionManager (LIKELY AFFECTED)

2. Risk: 2 direct callers, 2 processes = MEDIUM
   → Recommend: update loginHandler and apiMiddleware first, then run tests

gitnexus-pr-review

用于审查 Pull Request，评估合并风险、变更影响范围及测试覆盖率。通过获取 Diff、映射受影响流程并分析依赖关系，提供包含正确性、破坏性变更及最终审批建议的结构化评审报告。

用户请求审查 PR 询问 PR 的具体变更内容评估合并 PR 的安全性或风险

skills/gitnexus-pr-review/SKILL.md

View Skill ›

npx skills add tintinweb/pi-gitnexus --skill gitnexus-pr-review -g -y

SKILL.md

Frontmatter

{
    "name": "gitnexus-pr-review",
    "description": "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?\""
}

PR Review with GitNexus

When to Use

"Review this PR"
"What does PR #42 change?"
"Is this safe to merge?"
"What's the blast radius of this PR?"
Reviewing someone else's code changes before merge

Workflow

1. gh pr diff <number>                                                → Get the raw diff
2. gitnexus_detect_changes({scope: "compare", base_ref: "main"})     → Map diff to affected flows
3. gitnexus_impact({target: "<symbol>", direction: "upstream"})       → Blast radius per change
4. gitnexus_context({name: "<key symbol>"})                           → Understand callers/callees
5. Summarize findings with risk assessment

If index is stale → run /gitnexus analyze before reviewing.

Checklist

- [ ] Fetch PR diff (gh pr diff or git diff base...head)
- [ ] gitnexus_detect_changes to map changes to affected execution flows
- [ ] gitnexus_impact on each non-trivial changed symbol
- [ ] Review d=1 items (WILL BREAK) — are callers updated?
- [ ] gitnexus_context on key changed symbols to understand full picture
- [ ] Check if affected processes have test coverage
- [ ] Assess overall risk level
- [ ] Write review summary with findings

Review Dimensions

Dimension	How GitNexus Helps
Correctness	`context` shows callers — are they all compatible with the change?
Blast radius	`impact` shows d=1/d=2/d=3 dependents — anything missed?
Completeness	`detect_changes` shows all affected flows — are they all handled?
Test coverage	`impact({includeTests: true})` shows which tests touch changed code
Breaking changes	d=1 upstream items that aren't updated in the PR = potential breakage

Risk Assessment

Signal	Risk
Changes touch <3 symbols, 0-1 processes	LOW
Changes touch 3-10 symbols, 2-5 processes	MEDIUM
Changes touch >10 symbols or many processes	HIGH
Changes touch auth, payments, or data integrity code	CRITICAL
d=1 callers exist outside the PR diff	Potential breakage — flag it

Review Output Format

## PR Review: <title>

**Risk: LOW / MEDIUM / HIGH / CRITICAL**

### Changes Summary
- <N> symbols changed across <M> files
- <P> execution flows affected

### Findings
1. **[severity]** Description of finding
   - Evidence from GitNexus tools
   - Affected callers/flows

### Missing Coverage
- Callers not updated in PR: ...
- Untested flows: ...

### Recommendation
APPROVE / REQUEST CHANGES / NEEDS DISCUSSION

Example: "Review PR #42"

1. gh pr diff 42
   → 4 files changed: payments.ts, checkout.ts, types.ts, utils.ts

2. gitnexus_detect_changes({scope: "compare", base_ref: "main"})
   → Changed symbols: validatePayment, PaymentInput, formatAmount
   → Affected processes: CheckoutFlow, RefundFlow
   → Risk: MEDIUM

3. gitnexus_impact({target: "validatePayment", direction: "upstream"})
   → d=1: processCheckout, webhookHandler (WILL BREAK)
   → webhookHandler is NOT in the PR diff — potential breakage!

4. gitnexus_impact({target: "PaymentInput", direction: "upstream"})
   → d=1: validatePayment (in PR), createPayment (NOT in PR)
   → createPayment uses the old PaymentInput shape — breaking change!

5. Review summary:
   - MEDIUM risk — 3 changed symbols affect 2 execution flows
   - BUG: webhookHandler not updated for new validatePayment signature
   - BUG: createPayment depends on changed PaymentInput type
   - OK: formatAmount change is backwards-compatible

gitnexus-refactoring

用于安全地重命名、提取、拆分或移动代码的重构技能。通过GitNexus分析依赖和影响范围，提供预演与验证步骤，确保重构过程的安全性与准确性。

用户要求安全地重命名函数或符号用户需要将代码提取为新模块用户希望拆分服务或函数用户需要移动代码到不同文件

skills/gitnexus-refactoring/SKILL.md

View Skill ›

npx skills add tintinweb/pi-gitnexus --skill gitnexus-refactoring -g -y

SKILL.md

Frontmatter

{
    "name": "gitnexus-refactoring",
    "description": "Use when the user wants to rename, extract, split, move, or restructure code safely. Examples: \"Rename this function\", \"Extract this into a module\", \"Refactor this class\", \"Move this to a separate file\""
}

Refactoring with GitNexus

When to Use

"Rename this function safely"
"Extract this into a module"
"Split this service"
"Move this to a new file"
Any task involving renaming, extracting, splitting, or restructuring code

Workflow

1. gitnexus_impact({target: "X", direction: "upstream"})  → Map all dependents
2. gitnexus_query({query: "X"})                            → Find execution flows involving X
3. gitnexus_context({name: "X"})                           → See all incoming/outgoing refs
4. Plan update order: interfaces → implementations → callers → tests

If index is stale → run /gitnexus analyze to rebuild.

Checklists

Rename Symbol

- [ ] gitnexus_rename({symbol_name: "oldName", new_name: "newName", dry_run: true}) — preview all edits
- [ ] Review graph edits (high confidence) and ast_search edits (review carefully)
- [ ] If satisfied: gitnexus_rename({..., dry_run: false}) — apply edits
- [ ] gitnexus_detect_changes() — verify only expected files changed
- [ ] Run tests for affected processes

Extract Module

- [ ] gitnexus_context({name: target}) — see all incoming/outgoing refs
- [ ] gitnexus_impact({target, direction: "upstream"}) — find all external callers
- [ ] Define new module interface
- [ ] Extract code, update imports
- [ ] gitnexus_detect_changes() — verify affected scope
- [ ] Run tests for affected processes

Split Function/Service

- [ ] gitnexus_context({name: target}) — understand all callees
- [ ] Group callees by responsibility
- [ ] gitnexus_impact({target, direction: "upstream"}) — map callers to update
- [ ] Create new functions/services
- [ ] Update callers
- [ ] gitnexus_detect_changes() — verify affected scope
- [ ] Run tests for affected processes

Risk Rules

Risk Factor	Mitigation
Many callers (>5)	Use gitnexus_rename for automated updates
Cross-area refs	Use detect_changes after to verify scope
String/dynamic refs	gitnexus_query to find them
External/public API	Version and deprecate properly

Example: Rename `validateUser` to `authenticateUser`

1. gitnexus_rename({symbol_name: "validateUser", new_name: "authenticateUser", dry_run: true})
   → 12 edits: 10 graph (safe), 2 ast_search (review)

2. Review ast_search edits (config.json: dynamic reference!)

3. gitnexus_rename({symbol_name: "validateUser", new_name: "authenticateUser", dry_run: false})
   → Applied 12 edits across 8 files

4. gitnexus_detect_changes({scope: "all"})
   → Affected: LoginFlow, TokenRefresh
   → Risk: MEDIUM — run tests for these flows

tintinweb/pi-gitnexus

tintinweb/pi-gitnexus

Install All Skills

Skills in Collection (5)

gitnexus-debugging

Debugging with GitNexus

When to Use

Workflow

Debugging Patterns

Checklist

Tools

Example: "Payment endpoint returns 500 intermittently"

gitnexus-exploring

Exploring Codebases with GitNexus

When to Use

Workflow

Checklist

Tools

Example: "How does payment processing work?"

gitnexus-impact-analysis

Impact Analysis with GitNexus

When to Use

Workflow

Understanding Output

Risk Assessment

Checklist

Tools

Example: "What breaks if I change validateUser?"

gitnexus-pr-review

PR Review with GitNexus

When to Use

Workflow

Checklist

Review Dimensions

Risk Assessment

Review Output Format

Example: "Review PR #42"

gitnexus-refactoring

Refactoring with GitNexus

When to Use

Workflow

Checklists

Rename Symbol

Extract Module

Split Function/Service

Risk Rules

Example: Rename validateUser to authenticateUser

文库

Example: Rename `validateUser` to `authenticateUser`