Skip to main content
skill CX Codex

blast-radius · pedrohcgs — Claude Code skill: what it does, how to install

Finds every downstream consumer before editing shared interfaces and runs them end to end. Catches quiet contract breaks caused by additive changes.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add pedrohcgs/claude-code-my-workflow --skill blast-radius -a claude-code
Open on GitHub

What blast-radius does

This skill guides the agent to map out the blast radius before altering shared functions, schemas, or config defaults. Using grep and glob, it gathers call sites and downstream scripts across the codebase.

It focuses on fragile contracts such as argument arity and scale. Adding an item to a list or expanding a return tuple often breaks fixed-length consumers without raising compiler errors. Reading code is insufficient: consumers must be executed directly on realistic inputs.

When a downstream consumer references the repository by commit SHA, the workflow requires updating and verifying that pin within the same work session. Verification requires deliberate defect injection so that green test runs genuinely prove that failures are caught.

What it helps with

  • map call sites and downstream consumers before changing a shared function
  • inspect hidden length or positional assumptions in consumer code
  • run tests and regeneration scripts on real inputs across downstream files
  • verify that test suites genuinely fail by injecting synthetic defects

Example prompts for the agent

  • Check the blast radius before altering the signature of parse_payload
  • Find all consumers of the database schema and execute their verification suites
  • Assess downstream impact for changing default retry limits in settings.py

How to install blast-radius

1Skills CLI (Vercel)

npx skills add pedrohcgs/claude-code-my-workflow --skill blast-radius -a claude-code

2Manually: put the files in place

~/.claude/skills/blast-radius/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/blast-radius/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about blast-radius

How to install blast-radius in Claude Code?

Run npx skills add pedrohcgs/claude-code-my-workflow --skill blast-radius -a claude-code in your terminal. You can also save the file directly to ~/.claude/skills/blast-radius/SKILL.md.

What does blast-radius do?

It enforces a disciplined checklist whenever shared code changes. The agent inspects consumer contracts and executes downstream code instead of relying on static scans.

Why does blast-radius require injecting defects during verification?

Skipped tests, swallowed exceptions, or wide tolerances often produce false passes. Seeding a deliberate bug proves that the assertion actually executes and fails when broken.

Source text

SKILL.md · MIT
---
name: blast-radius
description: 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.
allowed-tools: ["Read", "Grep", "Glob", "Bash", "Write"]
metadata:
  protocol: bounded-delegation
---


# 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`](../../references/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:

- **Arity / length** — does anything index positionally, zip against a fixed list, or preallocate a matrix of known width? *Adding an element breaks all three.*
- **Names and order** — does anything match by name, by position, or pair your output against a separate parallel list of labels?
- **Types, units, scale** — dollars vs cents, rate vs percent, seconds vs ms, 0-indexed vs 1-indexed.
- **Nullability and sentinels** — new empty/NA cases a consumer will not expect.
- **Defaults** — changing a default silently changes every caller that relied on it.
- **Identity/ordering guarantees** — row order, sort stability, key uniqueness.

The classic failure: a returned vector grows from 6 to 7, while a consumer pairs it against a hard-coded list of 6 labels. Nothing errors at the edit site; the consumer either throws far away or, worse, recycles and mislabels every row.

## 3. Prefer changes that cannot break a contract

Additive-and-named beats additive-and-positional. Where you control the consumer, match by name rather than position. Where you cannot, version the interface rather than widening it in place.

Do **not** "fix" a mismatch by deriving labels/config from the new data if the old labels were deliberately different — deliberate relabeling exists (display names differing from internal names), and auto-deriving silently changes published output.

## 4. Run the consumers — end to end, on real inputs

A consumer that merely imports is not exercised. Run at least one full path per distinct consumer pattern, and prefer the one that regenerates reported numbers.

Then verify **both** directions:
- The new thing works.
- **The old things are unchanged.** Diff previously-reported outputs; anything that moved must have a reason you can state. If the change was supposed to be behavior-preserving, byte-identical or within a declared tolerance is the evidence — not "it ran".

## 5. Green is uninformative if nothing ran

Confirm the check actually executed and could have failed: a skipped test, a filtered-out case, an exception swallowed into a default, or a tolerance widened after the comparison are all indistinguishable from success in a log. Where the change is consequential, **seed a defect** and confirm the check goes red — a comparison that cannot fail is not evidence.

## 6. Record the contract change

If the interface genuinely changed, say so where consumers will look: a NEWS/CHANGELOG entry, a versioned interface note, or a comment at the definition naming what downstream code may assume. For anything reused or released, freeze inputs (versions, hashes, seeds) and record declared tolerances so the next comparison is reproducible rather than renegotiated.

## Minimum checklist

1. Grep all consumers, including tests, scripts, docs, other repos/languages.
2. Write down the contract: arity, names, order, types, units, defaults, ordering.
3. Make the change name-based/versioned where you can.
4. Run at least one full path per consumer pattern.
5. Diff previously-reported outputs; explain any movement.
6. Seed a defect to prove the check can fail.
7. Record the contract change where consumers will see it.
8. Re-pin every cross-repo consumer to the new SHA — regenerated and re-verified in this round, not the next one.

## Cross-references

- [`verification-ladder.md`](../../references/verification-ladder.md) — rung 2 (wiring)
- [`provenance-and-ground-truth.md`](../../references/provenance-and-ground-truth.md) — never re-bless a baseline in the commit that moves it
- [`release-engineering.md`](../../references/release-engineering.md) — pinning downstream consumers by SHA, and what a number-moving change owes them in the same round

© pedrohcgs · MIT · pedrohcgs/claude-code-my-workflow

Similar skills

All skills for Code review and refactoring →

blast-radius by other authors comes first.

blast-radius cursor A skill that finds what a change breaks elsewhere in the project and proves the one safety fact by executing code, not by describing it. CX Codex +1 5,700installs blast-radius michael-denyer Finds what a change breaks elsewhere, beyond the diff. Useful before a merge and when a brief asserts something about existing code. CX Codex +1 889installs improve-codebase-architecture Matt Pocock This skill scans a codebase for architectural friction, then builds a visual HTML report with refactoring candidates. Use it before a deeper architecture review. 1,163,035installs tdd Matt Pocock Guides the red-green TDD loop: ensures tests are written first, keep them at public interfaces, and avoid coupling to implementation details. 1,141,062installs triage Matt Pocock This skill moves issues and external PRs through triage states, verification, and agent briefs. It fits maintainers managing an issue queue. 990,453installs codebase-design Matt Pocock This skill helps design modules with small interfaces and hidden complexity. Use it when refactoring code, choosing a seam, or making tests easier to write. 850,344installs code-review Matt Pocock Reviews changes from a chosen reference point against repository standards and the originating spec. Use it for a branch, PR, or work in progress. 789,521installs implement Matt Pocock Implements work from a specification or tickets, following a test-driven flow and ending with review and a commit. Use it when a coding task needs a defined delivery routine. 774,700installs

From the same set56

compress-session This skill turns the current conversation into a structured note with decisions, open questions and next steps before auto-compaction eats the context. CX Codex +1 ★ 1,671repo stars compile-latex Compiles Beamer slide decks using XeLaTeX across three passes and BibTeX. Helpful when rendering slides inside Slides/ with custom themes and citations. CX Codex +1 ★ 1,671repo stars commit Runs quality, consistency and passport gates, branches off main, stages named files, and writes a commit whose subject states what now holds true. CX Codex +1 ★ 1,671repo stars coauthor-brief Writes a Markdown handoff brief so a co-author can see what changed, where each artifact stands, and how to run the project on their own machine. CX Codex +1 ★ 1,671repo stars checkpoint Takes a structured snapshot of session state, active plans, and next steps before breaks, model switches, or collaborator handoffs. CX Codex +1 ★ 1,671repo stars capture-environment This skill snapshots language and package versions, seeds and RNG kind into lockfiles so a rerun matches on another machine. Reach for it before releasing a replication package. CX Codex +1 ★ 1,671repo stars audit-reproducibility Checks numerical statements in research manuscripts against R, Stata, and Python results. Useful for catching mismatches before submission or a replication-package release. CX Codex +1 ★ 1,671repo stars adjudicate-review Turns incoming review findings into verified fixes. Every finding stays a candidate until it is checked against the actual source. CX Codex +1 ★ 1,671repo stars

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor