Blast Radius
Before and after changing anything shared, a function's return value, a signature, a...
Install
npx skills add pedrohcgs/claude-code-my-workflow --skill blast-radius -g -a claude-code -y- Repository
- pedrohcgs/claude-code-my-workflow1.7k
- Category
- Business
- Updated
- 1mo ago
- License
- MIT
- Context cost
- Lightabout 1,374 tokens
- Runs scripts
- No, instructions only
What it does
Before and after changing anything shared, a function's return value, a signature, a schema, a label set, a config default, a constant, a file format, find every consumer and actually run them. Catches the change that looks purely additive but silently breaks a contract in a file you never opened. Use when editing shared code, adding a field/column/return element, renaming, changing units or defaults, or touching a pipeline that produces reported numbers.
Know the blast radius before you change it
The dangerous change is not the risky-looking one. It is the one that looks purely additive, adding a returned value, a column, an option, and quietly violates a contract three files away that nobody re-read. Compilation and type checks will not catch a positional or length contract; you get either a crash far from the edit, or worse, silently wrong output.
Rule: if you change a shared interface, run its consumers. Reading them is not running them.
1. Enumerate consumers before editing
Grep for every call site, import, and downstream reference, including tests, notebooks, scripts, docs, and anything that regenerates reported results. Note which ones produce numbers that appear in a paper, dashboard, or release: those are the ones where silent breakage is most costly.
If a consumer lives in another repo, another language, or a generated artifact, write it down now; you will not remember at verification time.
A consumer in another repo pins this one by commit SHA. Its verification receipt records the revision it was built against, not a branch, not a version string, both of which keep moving under it. So a change here that moves a number the downstream reports is not finished when this repo goes green: before/after evidence for what moved, regeneration of the downstream artifact, and the re-pin all belong to the same round as the change, release-engineering.md §6 has the ordering within it. A downstream left pinned to the old SHA is an honest, inspectable state; one pointed at a moving reference silently inherits a number nobody re-verified.
2. Name the contract you are about to change
Ask explicitly what downstream code is entitled to assume:
