Ask for the rollback plan in the same prompt as the change plan, not after

A change request usually gets written as a forward-only document: what's changing, why, and when. The rollback plan, if it exists at all, tends to get written afterwards - or worse, worked out live, mid-incident, by whoever's on call when the change doesn't go the way it was supposed to.

Ask for the rollback plan in the same prompt as the change plan, not as a follow-up. Give the model the change itself and ask for two things back side by side: the steps to make the change, and the exact steps to undo it, including anything that can't cleanly be undone at all - a schema change with data already written into new columns, a permission change that's already been acted on, a certificate that's already been rotated out. Forcing both into one answer surfaces the changes that don't have a clean undo before you've made them, which is exactly when that's still useful to know.

If the honest answer is "there is no clean rollback for this step, only a forward fix", that's a genuinely useful thing to have written down before the change window starts, not a gap to discover while it's already gone wrong.