floomhq 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:
- List all files that need updating
- Estimate effort per file
- Define the migration order (what to update first)
- 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]
Common Gotchas
- Serialized data: If you change a data structure that's stored (database, localStorage, cache), old data won't match new code
- External contracts: If the API is public or used by external systems, breaking changes need versioning
- Implicit contracts: Types that aren't enforced (e.g., "this object always has a
namefield") but are expected by consumers - Environment variables: Renaming/removing env vars requires coordinated deploy
- Database migrations: Column renames require code + migration to deploy atomically