ix-impact

ix-claude-plugin shared model

Check command -v ix first. If unavailable, use Grep to find all usages and estimate impact manually.

Argument parsing

Strip --save and any following path token from $ARGUMENTS before resolving the target.

• If --save <path> is present, set SAVE_PATH to that path.
• If --save is present without a path, auto-generate ix-impact-<target-slug>.md in cwd (target slug = the target with spaces and slashes replaced by -).
• If --save is absent, SAVE_PATH is empty — do not write a file.

Pro check (optional)

Run once at the start:

ix briefing --format json 2>&1

If it returns JSON with a revision field, Pro is available. Extract openBugs for use in Pro steps below. If it errors, skip all [Pro] labeled steps.

Goal

Answer: what breaks if this changes, and is it safe to proceed? Stop as early as the risk level allows.

Phase 1 — Risk score (always)

Run in parallel:

ix impact  $ARGUMENTS --format llm
ix explain $ARGUMENTS --format llm

God-module check: If fan_out > 20 AND fan_in < 2 in the ix explain result:

⚠ This symbol has high fan_out and low fan_in — it reaches out to many dependents but has few callers. Standard blast-radius metrics may understate risk. Check callers of its key dependencies, not just direct dependents.

This caveat applies regardless of the ix impact risk classification.

Immediately classify:

Risk level	Action
low + < 3 dependents	STOP — safe to proceed. Report and suggest verification targets.
medium OR 3–10 dependents	Go to Phase 2
high or critical OR > 10 dependents	Go to Phase 2 + 3

Phase 2 — Callers and dependents (medium/high/critical)

Run in parallel:

ix callers  $ARGUMENTS --limit 15 --format llm
ix depends  $ARGUMENTS --depth 2 --format llm

Extract: direct callers by name and subsystem, transitive count.

Stop here if risk is medium: report callers, suggest verification, done.

Phase 3 — Import chain and subsystem spread (high/critical only)

ix imported-by $ARGUMENTS --format llm

Cross-reference callers + dependents + importers to identify:

• Which subsystems are in the blast radius
• Whether the change crosses an architectural boundary
• Any tests that cover the affected paths

Output

## Impact: [target]

**Risk level:** <critical | high | medium | low>
**Verdict:** <SAFE TO PROCEED | REVIEW CALLERS FIRST | NEEDS CHANGE PLAN>

**Blast radius:**
- Direct dependents: N
- Transitive (depth 2): M
- Subsystems affected: [list — only if phase 3 ran]

**Key callers:** [top 5, with subsystem label]

**At-risk behaviors:** [from the ix impact behavior lines]

**Recommended action:**
- low: proceed, verify [specific callers]
- medium: test [caller list] after change
- high/critical: run `/ix-plan $ARGUMENTS` before editing

**Known bugs in blast radius:** [Pro only — list open bugs touching callers/dependents, or omit section if none/Pro unavailable]

Phase 4 — Known bugs in blast radius [Pro]

If Pro is available and openBugs from the briefing is non-empty, check for bugs affecting this target:

ix bugs --format json

Cross-reference open bugs against the direct callers and dependents identified in Phase 2. Any open bug touching the blast radius escalates the risk verdict — flag it explicitly in the output.

Never read source code in this skill. Risk analysis is purely graph-based.

Save step (only if SAVE_PATH is non-empty):

• Write the full output above to SAVE_PATH using the Write tool.
• Confirm to the user: Saved to <SAVE_PATH>.
• Do not write the file if --save was not passed.