proving-change-safety

Find what a change could break beyond the diff, then prove the one fact it is safe because of by running real code. Apply when the user asks what a change could break, whether a small diff is safe to

SKILL.md

GitHub

Proving change safety

Leading words: one safety fact, prove by running, unproven stays unproven, grep is not enough.

Listing callers is not the job. Grep those in a second. The job is the breakage grep will not show.

Copy these steps into the todo list verbatim. Skip with skip: <reason>.

  1. Read the change: symbols added, changed, deleted, including what the diff does not spell out.
  2. Name the one fact it is safe because of.
  3. Look where grep stops: library source, pinned version, microtasks, wire format, other languages, flags, code three hops down.
  4. Honest risk list: chance, cost, file:line. Cleared items listed separately.
  5. Prove the one fact by calling the real function (script or test). Leave the prove script in the tree. Cite its path in the reply. If you cannot get to "ran it", write unproven. If you ran it and the fact is false, write do not ship — that is not unproven.

How sure

For each safety fact, get as far down this list as is cheap, and say where it stopped.

  1. You said so. Worthless alone.
  2. You pointed at file:line or the library's own source.
  3. You walked the failure and it does not reach.
  4. You ran it. A script or test that imports the same library the app ships and calls the exact function.
  5. You reproduced it in the running app.

Step 4 is the bar. Unproven stays unproven.

Reply contract

  • What it does (including the non-obvious part)
  • The one safety fact, the step you reached, and the proof path (or unproven)
  • do not ship if the fact is false; unproven only if you did not run it
  • Risks that remain
  • Cleared
  • Cheapest check to catch the real bug before merge