/community/astra blast radius
innernet
docsskillscommunitycompanydeveloperssecurityprivacytermscontact

a skill by Dytschgo, brought here by kt

astra blast radius

paste this link into your ai. it will know what to do.

/skills/dytschgo-astra-blast-radius

Trace what a code change could break beyond its direct diff and test the key assumption that makes it safe. Use for risky changes, small diffs with uncertain side effects, or explicit blast-radius reviews.

kindskill
last tended2026-09-30
written byDytschgo
sourcegithub.com/Dytschgo/dytschgo-skills
kept currentwith its source · last read 2026-11-13
brought here bykt
reuseMIT
yours?it stays under your name. to change it or take it down, write to connect@innernet.live
reading2 min

Astra Blast Radius

Find plausible effects of a change outside the lines it edits. Explain which risks are supported by evidence, which were checked and cleared, and what remains uncertain. This is a focused review; it does not grant permission to edit, merge, deploy, or contact anyone.

Trace effects

  1. 1Read the full diff and identify changed behavior, data shape, timing, lifecycle, defaults, and public contracts. Check relevant history and caller context when available.
  2. 2Follow paths that a simple symbol search can miss: serialized values, database fields, network payloads, generated files, feature flags, shared state, teardown, callbacks, and consumers in other packages or languages.
  3. 3For each plausible effect, state a concrete failure path and its likely impact. Link it to a real file and line or mark it as a hypothesis. Do not turn an unsearched possibility into a finding.
  4. 4Prioritize the one or two assumptions on which safety most depends. Prefer a narrow behavioral check against the real implementation over a broad list of speculative concerns.

Gather evidence

Use the cheapest reliable evidence available and say where it stops:

  1. 1Assertion without support.
  2. 2Source or contract evidence with a location.
  3. 3A step-by-step path showing why a failure is or is not reachable.
  4. 4A focused check that calls the real code and fails if the assumption is false.
  5. 5A reproduction through the running application when the behavior depends on runtime integration.

Use existing checks where they answer the question. Add a focused temporary probe only when it is safe, proportionate, and does not leave unrelated files behind. Do not claim a test, build, or runtime path passed unless it was actually run. Avoid testing against production accounts or data.

Report

Return:

  • Change: the consequential behavior introduced, removed, or shifted.
  • Key safety assumption: the claim, strongest evidence reached, and result. Mark it unproven if evidence is insufficient.
  • Risks: concrete failure path, location, likelihood and impact, plus an economical check.
  • Cleared: material risks investigated and the evidence that ruled them out.
  • Before shipping: the smallest relevant check still needed, if any.

Keep the report proportional to the change. A confirmed absence of meaningful downstream risk is a valid result. Do not present a long list of imagined failure modes as rigor.


keep it where your ai can reach it.

innernet is memory your ai tools read live — every skill, every project, every decision, in one place, connected once. save this skill to yours, or publish one of your own as a link like this.

save it to your innernetsee every skill