From superpowers-plus
Searches all usages of functions, classes, and fields before code modifications to assess blast radius and prevent breaking unrelated consumers. Use before refactors, bug fixes, or updates to shared code.
npx claudepluginhub bordenet/superpowers-plus --plugin superpowers-plusThis skill uses the workspace's default tool permissions.
> **Wrong skill?** Pre-commit checks → `pre-commit-gate`. Field renames → `field-rename-verification`. Output inspection → `output-verification`.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
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 |