blast-radius
Skill2 starsChanged 4 months agoMITView on GitHub
Enumerate the full impact set of a symbol before or during a change — every reference, caller, implementation/subtype, and reverse import — plus an explicit list of what could NOT be resolved (dynamic dispatch, reflection, generated code). Use before touching a shared / exported / widely-imported symbol, before an interface or signature change, or when the user asks "what breaks if I change this?", "어디까지 영향 가?", "누락 없이 찾아줘", "전부 찾았어?". Produces an evidence table + an "enumeration complete?" checklist; read-only.
111 other projects use a version of this.
Adopted by
Most recently taken up by
- marmot-protocol/mdktheir own version, first seen Nov 9, 2026
- Yeachan-Heo/oh-my-claude-sisyphustheir own version, first seen Nov 8, 2026
- Loner1024/skillstheir own version, first seen Nov 8, 2026
- imranbarbhuiya/skillstheir own version, first seen Nov 8, 2026
- caidanw/skillstheir own version, first seen Nov 8, 2026
- pedrohcgs/claude-code-my-workflowtheir own version, first seen Nov 8, 2026
Used with
Projects with it also use ketchup-video, principle-never-block-on-the-human and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
tristanphvnSkillketchup-video
Catch the user up like /keel:ketchup, with a short silent video of slides for what happened and the waiting calls as text under it. Use for /keel:ketchup-video.
Also in 14 projects that use this
jaydubya818Skillprinciple-never-block-on-the-human
Apply when safe reversible implementation details can proceed inside scope.
Also in 44 projects that use this
ianclearySkillprinciple-explain-the-number
Apply before you trust, report, or act on a number you measured: a speedup, a regression, a throughput, a latency, or an eval result. Find what limits it, and rule out that it measured something other than the work you think.
Also in 29 projects that use this
eryzerzSkillmake-bot-ui
Use when building a custom UI (page, dashboard, buttons) that should wake a Grok Bot over a webhook, when the user must provide a webhook sender key, or when exposing that UI on Tailscale.
Also in 20 projects that use this
bnemaSkillsetup-pstack
Configure which Pi models pstack uses per role. Detects available provider/model specs and writes pstack's user configuration. Use for /setup-pstack, "configure pstack models", or changing pstack model choices.
Also in 25 projects that use this
jaydubya818Skillprinciple-make-operations-idempotent
Apply when an operation must tolerate retries after partial completion.
Also in 46 projects that use this
- +6 more from jaydubya818
Other versions111 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 111
- Yeachan-Heo/oh-my-claude-sisyphus★ 41ksame name
- Yeachan-Heo/oh-my-claudecode★ 41ksame name
- backnotprop/pstack★ 3.8ksame name
- pedrohcgs/claude-code-my-workflow★ 1.7ksame name
- pixeltable/pixeltable★ 1.7ksame name
- moeru-ai/xsai★ 667same name
- savannahfeder/agentbox★ 376same name
- jtaroreh/agystack★ 128same name
- uzairansaruzi/p3-stack★ 126same name
- Dimon94/dverity★ 107same name
101 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
We split this skill into the rules it gives an agent
4 rules. 0 are common, 4 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 106 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 33
Run every layer available.
- Distinctive: line 42
call hierarchy — incoming callers and outgoing callees.
- Distinctive: line 78
Unknowns: every unresolved region + why.
- Distinctive: line 96
Read-only — enumerate and report.
“Common” is measured: kept by at least 6 in 10 of the 106 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
blast-radius — enumerate impact, surface the unknowns
You produce the impact set of a target symbol so a change can be made without missing a callsite. The honest contract of this skill: no tool guarantees omission-free discovery. LSP misses dynamic dispatch; grep misses renames; generated code and reflection defeat both. So you do NOT claim "completeness" — you guarantee all discovered edges, deduped with provenance, plus an explicit list of what you could not resolve. The unknowns section is the point, not an afterthought — it tells the human exactly where to look by hand.
1. Scope the target
Resolve the target symbol(s): a function / method / class / type / constant / API
route / DB field / component / exported name. For a signature or rename change,
capture BOTH the old and the new name. Note the declaring file:line.
2. Enumerate — layered, strongest signal first
Run every layer available; do not stop at the first. Cross-check the counts between layers — a divergence is itself a finding (a match one layer sees and another misses is a candidate omission).
- Code-intelligence (LSP / SCIP), if available — the strongest signal,
because it resolves bindings, not text:
references— every use of the symbol.implementations/ type hierarchy — every impl / subtype (for an interface or base type).- call hierarchy — incoming callers and outgoing callees; traverse recursively with a depth cap and a cycle guard. Record the provider and that support was present. If no LSP/index is available, say so explicitly (it changes the confidence of the result).
- AST inventory (tree-sitter), if available — enumerate declarations, imports/exports, class inheritance, and call-shaped expressions. Use it to catch structural uses and to sanity-check the LSP count.
- Text sweep (ripgrep) — always — grep both the old and new names across the
repo, excluding
node_modules,.venv,dist,build,.next,coverage, and vendored dirs. This catches string/symbol refs the import graph misses (config keys, DI tokens, dynamic route strings, docs). Treat lexical matches as candidates, never as resolved references — never present a grep hit as a precise call edge.
3. Categorize the impact
Bucket every discovered edge so the human can reason about coverage:
- Direct references — uses of the symbol.
- Callers — incoming call sites (who breaks if the signature changes).
- Implementations / subtypes — every type that must change together.
- Reverse imports / dependents — modules that import the declaring module.
- Tests / config / docs — test files, fixtures, config keys, and docs that name the symbol (often missed, often where a change actually breaks).
- UNKNOWN / unresolved — dynamic dispatch, reflection,
eval/metaprogramming, generated or macro-expanded code, framework-convention wiring, cross-language boundaries, and monorepo edges an unconfigured LSP can't cross. List each with why it's unresolved. THIS is where the human verifies by hand.
4. Report contract (BLUF)
- Target: the symbol(s) + declaring
file:line. - Searched scope: which layers ran (LSP? which provider / AST? / ripgrep) and the exclusion set — so the reader knows what was and wasn't covered.
- Impact table: one row per edge —
file:line· category · provider (lsp/ast/grep) · confidence (resolved / candidate). - Unknowns: every unresolved region + why. Non-empty is normal and expected.
- Enumeration complete? checklist — answer each:
- LSP available and used? (if no, recall is reduced — say so)
- Old AND new name swept (for a rename)?
- Tests / config / docs scanned?
- Any layer-count divergence investigated?
- Dynamic / generated / reflective code present and listed as unknown?
Constraints
- Never claim completeness. State "all discovered edges + N unresolved regions (listed)", never "all callsites" / "nothing else uses it". A terminal claim of completeness on a symbol with unresolved dynamic edges is the failure mode this skill exists to prevent.
- Degrade gracefully: no LSP → run AST + ripgrep and lower the stated confidence.
- Consume a code-intelligence index if present; never ship one. Use the host's LSP or an existing SCIP/LSIF index when available — generating/maintaining an index is heavy and out of scope (an enterprise-adapter concern, not the portable kit).
- Read-only — enumerate and report; make no edits.
- Cite every edge with a
file:lineconfirmed by Read/grep; a count with no rows is not evidence.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

