agentleFS
vasceannievasceannie/slopgate/.agents/skills/gitnexus-impact-analysis/SKILL.md

gitnexus-impact-analysis

Skill1 starsChanged 51 days agoMITView on GitHub

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?\"

We split this skill into the rules it gives an agent

2 rules. 2 are common, 0 are distinctive, and 0 are very specific to this project.

  • 2

    Common

    Most of the 10 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Before making non-trivial code changes

    line 14
  2. Common:

    Before committing — to understand what your changes affect

    line 15

“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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. impact({target: "X", direction: "upstream"}) or `node .gitnexus/run.cjs impact "X" --direction upstream --repo .`
2. READ gitnexus://repo/{name}/processes                   → Check affected execution flows
3. detect_changes({scope: "all"}) or `node .gitnexus/run.cjs detect-changes --scope all --repo .`
4. Assess risk and report to user

If "Index is stale" → run node .gitnexus/run.cjs analyze in terminal. If .gitnexus/run.cjs is missing, replace node .gitnexus/run.cjs with npx gitnexus in the fallback commands.

Checklist

- [ ] impact({target, direction: "upstream"}) or CLI fallback to find dependents
- [ ] Review d=1 items first (these WILL BREAK)
- [ ] Check high-confidence (>0.8) dependencies
- [ ] READ processes to check affected execution flows
- [ ] detect_changes({scope: "all"}) or CLI fallback for pre-commit check
- [ ] Assess risk level and report to user

Understanding Output

DepthRisk LevelMeaning
d=1WILL BREAKDirect callers/importers
d=2LIKELY AFFECTEDIndirect dependencies
d=3MAY NEED TESTINGTransitive effects

Risk Assessment

AffectedRisk
<5 symbols, few processesLOW
5-15 symbols, 2-5 processesMEDIUM
>15 symbols or many processesHIGH
Critical path (auth, payments)CRITICAL
Zero callers foundUNKNOWN

UNKNOWN is not a low rung on this scale — it means the walk could not answer. An empty caller set is equally consistent with "genuinely unused" and "the callers are not resolvable by the index" (plain-object property access, dynamic dispatch, cross-language calls), so few-callers ⇒ LOW does not apply. The result carries a riskNote saying so. Confirm with a text search before treating the symbol as safe to change or delete.

Tools

impact — the primary tool for symbol blast radius. If MCP is unavailable, use node .gitnexus/run.cjs impact <symbol> --direction upstream --repo . instead:

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%]

detect_changes — git-diff based impact analysis. If MCP is unavailable, use node .gitnexus/run.cjs detect-changes --scope all --repo . instead:

detect_changes({scope: "all"})

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

partial: true (a graph query failed) or truncated: true (the changed-symbol listing was capped) means the result is short of the truth, and reads like UNKNOWN above: a zero there means unseen, not unaffected. Re-run it rather than tick the pre-commit check.

Example: "What breaks if I change validateUser?"

1. impact({target: "validateUser", direction: "upstream"}) or `node .gitnexus/run.cjs impact "validateUser" --direction upstream --repo .`
   → 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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.