Gitnexus Impact Analysis
Run upstream impact and blast-radius analysis on a symbol or module before you edit or commit, so you know what dependents will break.
Overview
GitNexus Impact Analysis is an agent skill most often used in Ship—Review (also Build—Backend, Operate—Iterate) that reports blast radius and dependent breakage risk before you change or commit code.
Install
npx skills add https://github.com/abhigyanpatwari/gitnexus --skill gitnexus-impact-analysisWhat is this skill?
- Workflow: `gitnexus_impact` upstream → read `gitnexus://repo/.../processes` → `gitnexus_detect_changes` → risk report.
- Depth d=1 dependents are labeled WILL BREAK; d=2 is likely impact; prioritize >0.8 confidence edges.
- Pre-commit path maps current git diff to affected execution flows before you land changes.
- Stale index remediation: `node .gitnexus/run.cjs analyze` in terminal when prompted.
- Answers explicit questions: safe to change X, what depends on this, blast radius, who uses this code.
- Depth d=1 classified as WILL BREAK for direct callers/importers
- Checklist prioritizes dependencies with confidence greater than 0.8
Adoption & trust: 912 installs on skills.sh; 41.7k GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to change a function or module but cannot see which callers, importers, and execution flows will fail once the diff lands.
Who is it for?
Solo developers using a GitNexus-indexed repo who want upstream dependency and process-aware safety checks before refactors or commits.
Skip if: Greenfield files with no index yet, trivial typo-only edits where you will not run analyze on stale graphs, or teams without GitNexus tooling in the project.
When should I use this skill?
User asks if it is safe to change something, what depends on it, what will break, blast radius, who uses this code, or needs safety analysis before editing or committing.
What do I get? / Deliverables
You receive a depth- and confidence-scored impact report on upstream dependents plus mapped git changes to affected processes before you edit or commit.
- Upstream impact listing with depth and confidence
- Risk assessment tied to affected execution processes
- Pre-commit summary mapping git changes to impacted flows
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Pre-change safety checks belong on the Ship shelf because they gate merges and releases, even when you run them while still coding. Impact analysis is a structured review activity—assessing dependents, processes, and risk—not writing new features.
Where it fits
Before renaming an exported API helper, list d=1 callers that WILL BREAK if signatures shift.
Run `gitnexus_detect_changes` on your branch diff and attach affected processes to a PR risk summary.
Prioritize regression tests for high-confidence upstream edges flagged after impact analysis.
Assess blast radius on a hotfix path in production code before patching a shared utility.
How it compares
Graph-backed blast-radius checker—not ad-hoc “will this break?” chat without repo indexing.
Common Questions / FAQ
Who is gitnexus-impact-analysis for?
Indie builders and small teams on GitNexus-enabled repositories who need evidence-backed dependency impact before merging risky changes.
When should I use gitnexus-impact-analysis?
Use it in Ship before review or commit, in Build when editing shared backend or API surfaces, and in Operate when iterating on production code paths—especially when asked if a change is safe or what depends on a symbol.
Is gitnexus-impact-analysis safe to install?
It invokes GitNexus tools and may run local analyze scripts against your repo; review the Security Audits panel on this Prism page before allowing shell and git access.
SKILL.md
READMESKILL.md - Gitnexus Impact Analysis
# 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. READ gitnexus://repo/{name}/processes → Check affected execution flows 3. gitnexus_detect_changes() → Map current git changes to affected flows 4. Assess risk and report to user ``` > If "Index is stale" → run `node .gitnexus/run.cjs analyze` in terminal. ## Checklist ``` - [ ] gitnexus_impact({target, direction: "upstream"}) to find dependents - [ ] Review d=1 items first (these WILL BREAK) - [ ] Check high-confidence (>0.8) dependencies - [ ] READ processes to check affected execution flows - [ ] gitnexus_detect_changes() for pre-commit check - [ ] Assess risk level and report to user ``` ## 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 | ## Tools **gitnexus_impact** — the 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. READ gitnexus://repo/my-app/processes → LoginFlow and TokenRefresh touch validateUser 3. Risk: 2 direct callers, 2 processes = MEDIUM ```