blast-radiuslisted

# Blast radius Find what a concrete change could break outside its obvious diff, then seek proportionate proof for the assumptions that make the change safe. ## Invocation and target Run only after explicit invocation. Require a bounded, locally available change: - an uncommitted or staged diff; - a commit or commit range; - a branch comparison; - a locally available patch or PR ref. Do not analyze a purely hypothetical change. Route future design questions to an available design workflow instead. Establish the base, target, changed files, and relevant build or runtime context before drawing conclusions. Distinguish behavior introduced by the target change from pre-existing behavior. Ask one focused question when the comparison boundary is materially ambiguous. Record the initial repository status before running checks or creating temporary resources. This skill analyzes and verifies; it does not fix findings, refactor code, or commit changes. ## Preserve the repository Keep tracked project files unchanged by default: - Prefer existing focused tests and repository commands. - When a custom harness is necessary, create it outside tracked files when practical. - Remove only temporary resources created by this analysis. - Never reset, clean, overwrite, stage, or delete pre-existing work. - Report normal generated output according to repository policy when it cannot be removed safely. - Obtain explicit approval before handing persistent tests, scripts, fixtures, or prod