Gitnexus Impact Analysis

Before you refactor that function or rename that class, this skill shows you exactly what will break. It uses GitNexus to trace dependencies upstream and downstream, categorizing risk by depth: d=1 means direct callers that will definitely break, d=2 is likely affected, d=3 needs testing. You can run impact analysis on specific symbols or scan your staged git changes to see what processes and execution flows you're about to affect. The workflow is straightforward: query the target, review the blast radius starting with depth 1, check affected processes, assess risk level. It's basically a pre-commit safety net that saves you from finding out about breaking changes through bug reports.

skills.sh installs: 2K
GitHub stars: 48.4K
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add abhigyanpatwari/gitnexus --skill gitnexus-impact-analysis --agent claude-code

Installs into .claude/skills of the current project.

Files

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

Bind the repository first

Impact analysis is the gate that authorizes an edit, so it must answer for the repository you are about to edit.

Call list_repos {} before the first tool call. With one indexed repository, use the examples below as written. With more than one, pass repo on every call: an omitted repo normally errors, but under an MCP policy with a configured default it resolves to that default silently. If you cannot tell which repository is meant, stop and ask — every result below an ambiguous identity inherits the ambiguity. list_repos is paginated, so page with offset: pagination.nextOffset until hasMore is false before concluding a repository is absent.

SKILL.md on GitHub