Blast radius

Listing callers is not the job; rg does that in a second. The job is the breakage a search won't show you.

When

• The reviewer runs it before signing off a PR that touches shared code, SQL or queries, migrations, env or config, background jobs, a public API or a data format.
• The integrator checks that the PR carries it before the merge gate. For risky-tier PRs it is required.

Steps

1. Read the change. The diff, the symbols it adds, changes and deletes, and what the code now does differently, including what the diff doesn't spell out.
2. Find the one fact it is safe because of. Most risky-looking changes are safe because of one fact, like "this migration only adds a nullable column" or "this helper is only called from the admin page". If that fact holds, most risks go away at once. Spend your time here.
3. Look where search stops. A database column read by another service or a report. JSON that a client or a stored job parses. An env var another deploy target sets differently. A cron job or queue consumer that runs later. A library's pinned version or local patch. Code three calls downstream.
4. Rate each risk. How it breaks, the real file:line, how likely, how bad, and how to check. Keep confirmed risks separate from the ones you checked and cleared. A search that finds nothing is an answer; say what you searched. Never invent a caller or an API.
5. Prove the one fact. Write a small script, test or read-only query that exercises the real code or data, run it, and paste the output. Queries go against the development database only (.env.local), never production.

How sure you are

Say how far the safety fact got:

1. You said so. This proves nothing.
2. You pointed at the line (file:line, or the library's own source).
3. You walked the failure case step by step and showed it can't happen.
4. You ran code that calls the real function and fails loudly if you are wrong.
5. You reproduced it in the running app.

Aim for 4. If you stop earlier, write "unproven" next to the fact.

What goes in the PR

A ## Blast radius comment or section:

• What changed, including the part that isn't obvious.
• Safe because: the one fact, the level it reached, and the proof output.
• Risks: each with how it breaks, file:line, likelihood, cost and how to check.
• Cleared: what you checked and why it is fine.
• Before merge: the cheapest test or repro that would catch the real bug.

Write it with the unslop skill. No secrets or production data in the comment.

Adapted from blast-radius in pstack by Lauren Tan (v0.15.5, commit fae2c6e, 2026-09-29), MIT licence; the licence text is in LICENSE beside this file. Changes: tied to our reviewer and integrator steps, the result posted on the PR, queries limited to the development database; references to pstack's how, why and arena skills removed.