impact

name	impact
description	Analyze system-wide impact of changes before making them. Use before modifying shared utilities, changing APIs, or refactoring core functionality.
allowed-tools	Read, Grep, Glob
user-invocable	true

Impact Analysis

Analyze the system-wide impact of proposed or recent changes before you make them.

Philosophy

Code doesn't exist in isolation. A "small fix" in a shared utility can break ten components. A type change can cascade through the entire codebase.

"What else depends on this? What might break?"

This skill isn't about being cautious—it's about being informed. Make changes with full knowledge of their ripple effects.

When to Use

Run /impact before:

• Modifying shared utilities or types
• Changing API signatures
• Refactoring core functionality
• Deleting or renaming exports
• Making changes that "seem small but might ripple"

Input

The user will provide:

• File path(s) being changed, OR
• Function/class/type name being modified, OR
• Description of planned change

If nothing provided, analyze uncommitted changes.

Process

1. Identify Change Scope

Determine what's being modified:

• File(s) affected
• Exports being changed (functions, types, classes)
• API signatures being modified
• Data structures being altered

2. Find Direct Dependents

Search for code that directly uses the modified code:

• Files that import from the changed file
• Functions/components that call the modified code
• Types that extend or reference modified types

3. Check Test Coverage

Find related tests:

• Unit tests for the modified code
• Integration tests that exercise this path
• Tests that might need updating

4. Trace Downstream Effects

Follow the impact chain:

• Direct dependents → their dependents
• API routes that expose this functionality
• UI components that consume this data

Output Format

Keep it compact. Tables for findings, clear risk assessment.

## Impact Analysis: [Change Description]

**Scope**: [What's being changed]
**Risk Level**: Low | Medium | High

---

### Direct Dependents

| File | Usage | Risk |
|------|-------|------|
| `consumer.ts:45` | Calls `modifiedFunction()` | Medium |
| `component.tsx:23` | Uses `ModifiedType` | Low |

### Test Coverage

**Tests found:**
- `__tests__/file.test.ts` - Direct unit tests ✓

**Tests that may need updates:**
- `integration/flow.test.ts` - Uses affected flow

### Breaking Change Assessment

| Check | Status |
|-------|--------|
| Public API changes | Yes / No |
| Type signature changes | Yes / No |
| Behavioral changes | Yes / No |
| Database/schema changes | Yes / No |

---

### Recommendations

1. **Before changing**: [Specific prep work]
2. **Update alongside**: [Files that need coordinated changes]
3. **Tests to run**: [Specific test commands]
4. **Communicate to**: [Teams or people who should know]

### Summary

[1-2 sentences: X dependents found, Y tests affected, overall risk level and why]

Why This Matters

Impact analysis prevents:

• Surprise breakages in unrelated parts of the codebase
• Incomplete migrations where some consumers are missed
• Test failures that could have been anticipated
• Team friction when changes affect others' work

The five minutes spent on impact analysis saves hours of debugging and rollbacks.