Coupon housekeeping: find and disable stale coupons

Coupon lists grow the way junk drawers do. A launch code, three test coupons a developer made, last year’s Black Friday code that technically still works, a “one-time” discount you gave a customer and forgot. Most stores have a pile of them and no idea which are live. This prompt reads the whole list, flags the ones that look dead, and disables only the ones you sign off, so the code keeps working for the coupons you actually still run.

Help me tidy up coupons. Read first, then let me approve before you disable
anything.

List every coupon with its code, discount, expiry, and how many times it has
been used. Then read the ones that look stale by this rule: [expired more than
30 days ago, or created over a year ago and never used]. Build me a table of
the ones you would disable, with the code, why it qualifies, and its usage
count. Do not change anything yet.

I will tell you which ones to disable. Only those. Disable them (do not delete
them) in batches of [10], and show me each batch after you do it. At the end,
list every coupon you disabled so I can double-check.

Why this is safe to run

The whole first pass is reads. Listing the coupons and reading each candidate’s terms and usage changes nothing, so you approve the disable list before a single coupon is touched. Disabling is a reversible write, unlike a delete: it flips the coupon off so the code stops working while the coupon and its usage history stay in place, and you can turn it back on if you disabled one too eagerly. It is still gated the careful way, with explicit approval of the list, small batches, and a pause to show you each batch, and the coupon write ability stays off until you enable it for a run you are watching. Every call is checked against the capability of the user you bound the agent to and lands in the Activity Log, so you can see exactly which coupons changed and when.

Already connected? Skip the paste. Ask your agent for the “coupon housekeeping” recipe, set your own rule for what counts as stale, and it runs the same read-first, approve-the-list flow on your own store.