Red-Team the "Behavior Preserved" Claim — refactor-chain · review

Bundle: refactor-chain (self-diagnosing, self-healing fix-it pipeline). Phase: review · Prerequisite: do-the-work produced a diff; a green baseline exists (refactor-safety-net) · Next: the review gate (refactor-review-gate) folds these findings into the go/no-go. Adaptivity / conditional: repo-agnostic, adversarial, read-only for product code (it may add tests). Always relevant when a refactor claims behavior preservation.

Purpose

Every refactor makes one load-bearing promise: "I moved / renamed / split this, and the behavior is exactly the same." This skill assumes that promise is a claim to be attacked, not a fact to be trusted. It reads the diff, extracts the specific behavior-preservation claims it depends on ("callers of the renamed method still resolve", "the extracted function returns the same thing on every path", "the new loop iterates in the same order"), then goes hunting for the ones most likely to be false. It ranks candidate breakages by impact × likelihood × cheapness-to-test, and for the top ones it writes the single cheapest test that would fail if the claim is broken. It is the adversary the refactorer needs: it doesn't take "it compiles" or "looks fine" as proof.

When to use

• A refactor is done and you want to genuinely stress-test that behavior held. Triggers: "did this keep behavior the same", "prove it's safe", "attack this change".
• A rename, extraction, or move touched code with many callers or subtle contracts. Triggers: "red-team this rename", "I don't trust this extraction".
• The review gate asks for the behavior-preservation verdict (this skill supplies it).
• Precondition: a diff and a green baseline. Without a baseline, say so — you can still attack claims by reading, but you can't run the cheapest tests to green.