Blast radius

Find what a change breaks somewhere else, before it ships. Use before raising a PR or merging one, for "blast radius of X", "what could this break", or reviewing a small diff you don't trust yet.

The job is the breakage grep won't show you. Find the one or two facts the whole thing depends on and prove them by running code. For changes with independent affected areas, identify the safety facts for each area; one proven fact cannot clear unrelated risks.

Use the current agent and model for the investigation and fixes. Return a report in the conversation; save Markdown only when requested. This review does not authorize committing, publishing, merging, or deploying.

Steps

1. Establish the change and intent

Record the working-tree state, the reviewed revision, and the comparison base. Use the PR's actual base, an explicitly supplied reference, or the repository's configured target branch and its merge-base. Include relevant staged, unstaged, and untracked changes for a pre-PR review. If the intended scope remains ambiguous after inspecting the repository, ask which change to review. Preserve unrelated work.

Read the diff, the symbols it adds, changes, and deletes, and what it now does differently, including the part the diff doesn't spell out. Recover intent from the conversation, originating ticket or spec, relevant ADRs, and git/PR history. Cite the artifact behind a claimed requirement; mark inferred intent as inferred.

When a changed module's interface, invariants, or seams are unclear, use the codebase-design reference. Existing specs and history establish intent; creating a new planning or domain-modeling session is a separate task.

Done when: every changed area is accounted for, the reviewed scope and base are explicit, and intended behavior is sourced or marked unknown.