Mmcp.market

blast-radius skill

by pedrohcgs·pedrohcgs/claude-code-my-workflow·1.6k stars·MIT

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.

A100/100content scan

Is the blast-radius skill safe?

Clean: nothing in its files matched our rules. We read 1 file in the folder on 2026-09-28.

No findings.

Install the blast-radius skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description. 

git clone --depth 1 https://github.com/pedrohcgs/claude-code-my-workflow.git /tmp/claude-code-my-workflow
mkdir -p ~/.claude/skills
cp -r /tmp/claude-code-my-workflow/.claude/skills/blast-radius ~/.claude/skills/blast-radius
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

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:

  • 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 — rung 2 (wiring)
  • provenance-and-ground-truth.md — never re-bless a baseline in the commit that moves it
  • release-engineering.md — pinning downstream consumers by SHA, and what a number-moving change owes them in the same round

More skills from pedrohcgs/claude-code-my-workflow

  • Aadjudicate-reviewTurn an incoming set of findings — from an AI reviewer, a referee report, a code review, a linter, or a second model — into verified fixes, without letting a confident misread damage correct work. Every finding is a CANDIDATE until checked against the actual source. Use whenever you receive review comments, audit findings, or a critique you did not write yourself, especially when the reviewer is a model or when the volume is too large to check by feel.
  • Aaudit-reproducibilityEnforce the replication-protocol.md rule by cross-checking numeric claims in a manuscript against the actual R / Stata / Python outputs. Report PASS/FAIL per claim against tolerance thresholds. Use before submission and before releasing a replication package.
  • Acapture-environmentSnapshot the computational environment for a replication package — detects the analysis stack (R / Stata / Python) and emits the right lockfiles (renv.lock + sessionInfo.txt, requirements.txt / environment.yml / uv.lock, Stata version + ado package list), records seeds and RNG kind, optionally writes a pinning Dockerfile, and produces a paste-ready "Computational requirements" block. Use when user says "capture the environment", "snapshot my dependencies", "pin the versions", "make a renv.lock / requirements.txt", "make this byte-reproducible", or before releasing a replication package to openICPSR / the AEA Data Editor.
  • AchallengeStress-test a finding against the choices you did not make. Enumerates the discrete forks a competent analyst could have taken (measure definition, sample filter, control set, clustering level, weighting, functional form), runs the specification grid, and reports the distribution rather than a point estimate — then attacks the identifying assumption with named, computable sensitivity statistics. Use when the user says "is this robust", "challenge this result", "specification curve", "multiverse", "how sensitive is this", "what if I'd used a different measure", "stress-test my estimate", or before a result becomes a headline claim. NOT a reviewer of prose or code — it challenges the CLAIM.
  • AcheckpointSave a structured state snapshot before stopping or handing off. Captures the active plan, recent decisions, file pointers (with line numbers), open questions, and the next 1–3 actions into a checkpoint file under `quality_reports/checkpoints/`. Optionally proposes `[LEARN]` entries to add to MEMORY.md. Use when user says "checkpoint", "save state", "snapshot before I stop", "where am I", "wrap up the session for handoff", or before a long break / model switch / collaborator handoff. Companion to (NOT replacement for) the narrative session-log workflow.
  • Acoauthor-briefGenerate a co-author / collaborator handoff brief for a multi-author, multi-machine project — summarizing what changed since the last brief (git delta), the current state of each artifact (manuscript, analysis, slides), open questions, how to reproduce locally, and any restricted-data access steps. Use when user says "coauthor brief", "handoff brief", "bring my coauthor up to speed", "what changed since last week", "onboard a collaborator", "write a handoff for [name]", or before sending a co-author the repo. NOT a commit or a checkpoint — it is the cross-machine, cross-person summary `meta-governance.md` only partially covers.
  • AcommitCommit the current work — runs the quality, consistency and passport gates, branches off main if needed, stages specific files, and writes a commit whose subject states what is now true. Pushes and opens a pull request only with --pr or when the user asks; never merges — a merge happens only when the user explicitly says to merge. Use ONLY on explicit commit intent — user says "commit", "let's commit this", "open a PR", or prefixes with `/commit`. Do NOT auto-invoke on vague end-of-task phrases ("we're done", "wrap up") — those require explicit confirmation first. Never force-pushes or skips hooks.
  • Acompile-latexCompile a Beamer LaTeX slide deck with XeLaTeX (3 passes + bibtex). Use when user says "compile", "build the slides", "rebuild the PDF", "run latex", "render the tex", or asks why a `.tex` file isn't producing a PDF. Operates on `Slides/*.tex`.
  • Acompress-sessionDistill the current conversation into a structured note (decisions made, open questions, file pointers with line numbers, next 1–3 actions) and save to `quality_reports/session_logs/` before auto-compression. Differs from `/checkpoint` (explicit stop-point snapshot) and from auto-compaction (which truncates rather than distills). Use when context is approaching auto-compact threshold, when a long pipeline has accumulated many decisions, or when the user says "compress", "distil this session", "before we hit auto-compact", "structured handoff before context resets".
  • Acontext-statusShow current context status and session health. Use to check how much context has been used, whether auto-compact is approaching, and what state will be preserved.
  • Acreate-lectureCreate a new Beamer lecture `.tex` from source papers and materials, with notation consistency checks and the project's preamble wired in. Use when user says "create a lecture on X", "new lecture from these papers", "start a deck on topic Y", "scaffold a new Beamer file", "build me a lecture from these PDFs". Scaffolds the full deck — NOT for compiling existing `.tex` (use `/compile-latex`).
  • Acredible-claimsResearch-brief + claim-record discipline for delegated or AI-assisted research work. Use when starting any substantive research task or long autonomous run (write the brief first), and when reporting results that will support a claim in a paper or decision (produce the claim record). Keeps faster execution from being confused with credible evidence.

All agent skills → · MCP servers