blast-radius

Blast Radius Skill

Purpose

Before changing anything, understand everything it touches. The blast radius is the set of systems, files, users, and processes that will be affected by a change.

Step 1: Identify the target

What exactly is being changed?

• A function signature
• A database schema
• An API endpoint
• A configuration value
• A shared utility
• An environment variable

Step 2: Find all consumers

# Find all usages of a function/variable
grep -r "functionName" --include="*.ts" --include="*.js" .

# Find all imports of a module
grep -r "from './module'" --include="*.ts" .

# Find all references to a table
grep -r "table_name" --include="*.sql" --include="*.py" .

# Find all callers of an API endpoint
grep -r '"/api/endpoint"' .
grep -r "fetch.*endpoint" .

Step 3: Map the dependency tree

[Changed thing]
├── Direct consumers (files that use it directly)
│   ├── Consumer A
│   │   └── Who uses Consumer A?
│   └── Consumer B
│       └── Who uses Consumer B?
└── Indirect consumers (things that use consumers)

Step 4: Classify impact

For each consumer:

Consumer	Impact Type	Severity	Action Needed
file.ts	Breaking	HIGH	Update call sites
test.ts	Breaking	MEDIUM	Update tests
api.ts	Breaking	HIGH	Update + version bump

Impact types:

• Breaking: Will fail to compile/run without update
• Behavioral: Will compile but behavior changes
• None: No impact (consumer is isolated)

Step 5: Migration plan

For breaking changes:

1. List all files that need updating
2. Estimate effort per file
3. Define the migration order (what to update first)
4. Plan for parallel operation (old + new) if needed for zero-downtime

Step 6: Risk assessment

BLAST RADIUS REPORT
Target: [what is changing]
Direct consumers: N files
Indirect consumers: M files
Breaking changes: [YES/NO]

HIGH RISK areas:
- [file/system] because [reason]

Estimated effort: [S/M/L]
Migration required: [YES/NO]
Rollback plan: [description or N/A]

RECOMMENDATION: [PROCEED / PROCEED WITH MIGRATION PLAN / STOP AND REDESIGN]