From superpowers-plus
Searches all usages of existing code before modification to prevent breaking unrelated consumers. Use when refactoring, fixing bugs, or changing shared utilities.
How this skill is triggered — by the user, by Claude, or both
Slash command
/superpowers-plus:blast-radius-checkThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> **Wrong skill?** Pre-commit checks → `pre-commit-gate`. Field renames → `field-rename-verification`. Output inspection → `output-verification`.
Wrong skill? Pre-commit checks →
pre-commit-gate. Field renames →field-rename-verification. Output inspection →output-verification.Source:
superpowers-plusPart of: Engineering Rigor skill family
SCOPE YOUR IMPACT BEFORE YOU SCOPE YOUR FIX.
Before modifying ANY existing code, determine the full blast radius — every caller, consumer, and dependent that could be affected.
Common failure: Making changes without checking blast radius. The "fix" breaks multiple unrelated consumers because you only looked at the immediate problem, not the full dependency graph. Never assume a change is isolated without proving it.
# Search ALL repos for the function/class/field you're modifying
grep -rn "functionName\|ClassName\|fieldName" --include="*.ts" .
# Check for imports
grep -rn "import.*functionName\|from.*moduleName" --include="*.ts" .
# Check for interface implementations
grep -rn "implements InterfaceName\|extends BaseClass" --include="*.ts" .
| Dependent Type | Count | Impact if Changed |
|---|---|---|
| Direct callers | ||
| Subclasses/implementations | ||
| Test files | ||
| Config/types |
Wrong skill? Pre-commit checks →
pre-commit-gate. Field renames →field-rename-verification. Output inspection →output-verification.list
grep -c to count)| Blast Radius | Action |
|---|---|
| 1 caller | Safe to modify directly |
| 2-5 callers | Review each caller's usage before modifying |
| 5+ callers | Consider adding new function/parameter instead of modifying |
| Shared utility | Almost NEVER modify — extend or create variant instead |
If you can't answer "How many things use this?" — STOP and find out.
For multi-component changes, trace the full data flow BEFORE implementing:
Data/Control Flow Diagram:
SOURCE → STORAGE → ROUTER → CONSUMER → EXTERNAL
| Layer | File(s) | Change Required |
|---|---|---|
| Schema | ||
| Storage | ||
| Router | ||
| Consumer | ||
| External |
Fill this table BEFORE implementing. Every empty row is a potential bug.
These are files that receive data and pass it along WITHOUT using it locally. They're easy to miss because:
any)Question to ask: "Does this component TRANSFORM the data before passing it?"
If yes → that transform must include new fields.
After implementing, verify with cross-repo grep:
# Search ALL repos for the new field/function
grep -rn "newFieldName" --include="*.ts" --include="*.js" repo1/ repo2/ repo3/
# Include snake_case, camelCase, UPPER_CASE variants
grep -rn "new_field_name\|NewFieldName\|NEW_FIELD_NAME" .
Deleting or renaming a skill is a high blast-radius operation. Skills are referenced in many forms across many file types. Run this exact sequence before any deletion or rename.
SKILL="skill-name" # e.g., engineering-rigor
MERMAID="${SKILL//-/_}" # e.g., engineering_rigor
# All text files — hyphenated skill name
grep -rn "$SKILL" . --include="*.md" --include="*.sh" \
--include="*.js" --include="*.json" --include="*.yaml" 2>/dev/null
# Mermaid node and edge declarations — underscore form
grep -rn "$MERMAID" . --include="*.md" 2>/dev/null
# Structured data files — these FAIL harsh-review if stale
grep -n "\"$SKILL\"" tools/high-cost-skills.json \
docs/composition-manifest.json 2>/dev/null
Build a complete list of every hit before touching a single file. If the count is higher than expected, that's the real blast radius.
Use the inventory from Step 1 as a checklist. Touch every file on the list — including:
| Location | What to check |
|---|---|
skills/*/skill.md | coordination.requires, .enables, .escalates_to |
tools/high-cost-skills.json | Array entries |
docs/composition-manifest.json | Object keys |
docs/skill-dependency-graph.md | Node declarations AND edge declarations (underscore form) |
lib/intent-patterns.js | Skill name strings |
docs/*.md prose | Companion skill tables, "Wrong skill?" headers |
After all edits, re-run the same grep commands from Step 1. Zero hits = done.
grep -rn "$SKILL\|$MERMAID" . --include="*.md" --include="*.sh" \
--include="*.js" --include="*.json" 2>/dev/null | grep -v CHANGELOG
bash tools/harsh-review.sh
CHECK 4c will fail if any structured file still references the deleted skill. A passing gate is mandatory before commit.
pre-commit-gate — Before committing changes
providing-code-review — When reviewing others' PRs
autonomous-chain-controller: Chain-aware refactoring
| Failure | Fix |
|---|---|
| Only checked direct callers, missed transitive consumers | Trace data flow through ALL paths (READ → STORE → PASS) |
| Skipped test impact analysis | Run full test suite, check for tests that exercise changed paths |
| Assumed internal function has no external consumers | Grep for ALL references — internal/external distinction is often wrong |
| Changed API contract without checking client services | Use field-rename-verification for cross-service contract changes |
npx claudepluginhub bordenet/superpowers-plus --plugin superpowers-plusGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.