---
name: blast-radius
description: Estimate how heavy a change is before building it — what it touches, what could break, and how reversible it is — from a description, spec, issue, or branch. Use when the user asks for the blast radius, impact, or risk of a change.
---

# Blast Radius

Map what a change touches and what it could break by reading the code, not by guessing. This is read-only: don't modify code, data, or external systems.

## Locate the change

The change can be a description, a spec (e.g. `feature_spec_<name>.md`), a GitHub or Linear issue, or a branch or diff. Fetch issues through an available connector or CLI; diff a branch against its base. Find the code it will modify with the available code search (symbols, routes, commands, tables, config keys). If the change is too vague to locate, ask where it lands before tracing.

## Trace outward

From each touched spot, follow what depends on it:

- **Callers and dependents** — what imports, calls, renders, queries, or schedules the touched code: other routes, jobs, CLIs, UI, scripts.
- **Data** — schema changes, migrations, backfills, and writes to existing records. Anything that changes or deletes existing data is the hardest thing to undo.
- **Contracts** — what something outside this code relies on: API and response shapes, exports and file formats, events and webhooks, CLI flags, env vars, config, URLs.
- **Untested neighbours** — behavior that shares code with the change but that no test exercises. Check what the tests actually call, not just their file names.
- **Outside the repo** — external services, cost, permissions, deploy or migration order, feature flags.

Stop at boundaries the change can't reach, and say where you stopped.

## Report

Use [references/report_template.md](references/report_template.md) for the report and the size rubric. Mark every item **confirmed**, with a file and line or symbol, or **inferred**, with the reason. List anything you couldn't check.

Lead with the size and the one item that drives it, then recommend a next step: build directly, write a spec first, split into issues, or add tests for the untested neighbours first. Present the report in chat and offer to save it as `blast_radius_<name>.md` where the user says, otherwise in the project's planning folder (`plans/`, `specs/`, or `docs/specs/`), or a new `plans/` at the project root. When the input was a spec, offer to add each at-risk behavior as a row in its verification table. Continue only when the user says so or asked for it up front.

Done means every touched area and at-risk behavior is confirmed with a code reference or labelled inferred, and the gaps are listed.