3. Add structure

/blast-radius

For a feature: size the change before you build it.

Install this skill Read the skill and templates

When to use it

You’re about to build a feature and want to know how heavy it is.
A change touches code other parts of the app depend on.
You want to know what could break, and how to undo it.

How it works

the change

Callers and dependents what imports, calls, renders, queries or schedules it
Data schema, migrations, backfills, writes to existing records
Contracts API shapes, exports, events, CLI flags, env vars, URLs
Untested neighbours shares code with the change, but no test exercises it
Outside the repo services, cost, permissions, deploy order, flags

1 Locate the change
A description, spec, issue or branch. It finds the code the change will modify.
2 Trace outward
Callers and dependents, data, contracts, untested neighbours, and outside the repo.
3 Report
The size and the one item that drives it, every item confirmed or inferred, then a next step.

Size by the riskiest item

SmallOne area, no data or contract changes. A revert undoes it.
MediumSeveral areas, or an additive schema or contract change callers won’t notice. Revert plus a down migration.
LargeChanges or deletes existing data, breaks a contract, cuts across most of the app, or won’t fit one session.

What you get

A sized report in chat; optionally blast_radius_<name>.md.

blast_radius_<name>.md

in chat, saved if you want it

Size + the one item that drives it
Touched areas
Callers, covered by a test?
Data and contracts at risk
Untested neighbours, each with a check
Reversibility: how to undo it
Recommendation: next step
Not checked

Next step

When it’s done, /blast-radius recommends one of these:

Build directly · small, and fits one session
Write a spec first · with /create-spec
Split into issues · with /create-issues
Add tests first · for the untested neighbours

Install /blast-radius

One prompt installs just this skill and its template. Want the whole system? Install all five from the Planning System page.

Then paste it into a conversation with your agent.

Works with

Claude Code
Codex
Grok Bot

Download blast-radius.zip Unzip into your agent’s skills folder.

Read the installation prompt

Install the blast-radius skill from this manifest for use in the agent I am using now:
https://ainativebuilder.com/plan/resources/blast-radius/manifest.json

Identify this agent and use its supported personal/global skill installation or saved-skill mechanism, so the skill is reusable beyond the current project or conversation. If the correct mechanism is unclear, check this agent's official instructions before proceeding.

Fetch the manifest and download every listed file from the same origin. Preserve the exact contents and relative references of all 2 Markdown files, keeping each skill in its own folder named after the skill. Stage the complete bundle and verify its SHA-256 hashes before installation. If a download or hash check fails, stop and report it without changing existing skills. Back up any existing same-name skills before replacing them; keep filesystem backups outside skill-discovery directories. Install independent copies, not symlinks.

Verify that the skill is saved and discoverable and that every referenced template is accessible. If this host cannot preserve the complete bundle, explain the limitation instead of claiming successful installation. Report any enablement or refresh step still needed.

Confirm what was installed and where, then stop. Do not invoke the skill, start an interview, plan a project, or implement anything.

Install all five skills instead

Full instructions & templates

Read each complete file below. Copy or download the original Markdown to use with your agent.

Blast radius skill

blast-radius/SKILL.md

Select and copy the complete source below.

---
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.

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 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.

Report template

blast-radius/references/report_template.md

Select and copy the complete source below.

# Blast Radius: [Change]

**Date:** [YYYY-MM-DD]
**Input:** [Description, spec link, issue link, or branch]
**Size:** [Small / Medium / Large] — [The one item that drives it]

## Touched Areas
| Area | What changes | Confirmed or inferred | Evidence |
|------|--------------|-----------------------|----------|
| [e.g., expense queries] | [Change] | [Confirmed / Inferred] | [`path:line`, symbol, or reason] |

## Callers and Dependents
| Dependent | How it uses the touched code | Covered by a test? | Evidence |
|-----------|------------------------------|--------------------|----------|
| [Route, job, UI, script] | [Use] | [Yes, with the test / No] | [`path:line` or symbol] |

## Data
- [Schema change, migration, backfill, or write to existing records — or "None"]

## Contracts at Risk
- [API shape, export format, event, CLI flag, env var, or URL others rely on — or "None"]

## Untested Neighbours
_Existing behavior that shares code with the change and has no test. These become verification rows in the spec or issue._

- [Behavior] — [Why it's at risk] — [Suggested check]

## Outside the Repo
- [External service, cost, permission, deploy order, or feature flag — or "None"]

## Reversibility
- **Undo by:** [Revert / Revert plus a down migration / Not cleanly reversible, because…]

## Recommendation
- **Fits one build session:** [Yes / No — why]
- **Next step:** [Build directly / Write a spec first / Split into issues / Add tests for the untested neighbours first]

## Not Checked
- [What you couldn't verify, and why — or "None"]

---

## Size Rubric

Size by the riskiest item, not by how many items there are.

- **Small:** one area, no data or contract changes, and a revert undoes it.
- **Medium:** several areas, or an additive schema or contract change that existing users and callers won't notice; a revert plus a down migration undoes it.
- **Large:** changes or deletes existing data, breaks a contract something else relies on, cuts across most of the app, or won't fit one build session.

Show the report template

Blast Radius: [Change]

Date: [YYYY-MM-DD] Input: [Description, spec link, issue link, or branch] Size: [Small / Medium / Large] — [The one item that drives it]

Touched Areas

Area	What changes	Confirmed or inferred	Evidence
[e.g., expense queries]	[Change]	[Confirmed / Inferred]	[`path:line`, symbol, or reason]

Callers and Dependents

Dependent	How it uses the touched code	Covered by a test?	Evidence
[Route, job, UI, script]	[Use]	[Yes, with the test / No]	[`path:line` or symbol]

Data

[Schema change, migration, backfill, or write to existing records — or “None”]

Contracts at Risk

[API shape, export format, event, CLI flag, env var, or URL others rely on — or “None”]

Untested Neighbours

Existing behavior that shares code with the change and has no test. These become verification rows in the spec or issue.

[Behavior] — [Why it’s at risk] — [Suggested check]

Outside the Repo

[External service, cost, permission, deploy order, or feature flag — or “None”]

Reversibility

Undo by: [Revert / Revert plus a down migration / Not cleanly reversible, because…]

Recommendation

Fits one build session: [Yes / No — why]
Next step: [Build directly / Write a spec first / Split into issues / Add tests for the untested neighbours first]

Not Checked

[What you couldn’t verify, and why — or “None”]

Size Rubric

Size by the riskiest item, not by how many items there are.

Small: one area, no data or contract changes, and a revert undoes it.
Medium: several areas, or an additive schema or contract change that existing users and callers won’t notice; a revert plus a down migration undoes it.
Large: changes or deletes existing data, breaks a contract something else relies on, cuts across most of the app, or won’t fit one build session.