Promotional expiry — high-level pointers

chimecho tells you what is past its date. This is the minimal high-level fallback for what to do about it — direction only, deliberately not step-by-step, so there is nothing here to drift out of sync with a team wiki.

Triage order

Explicit expiries first. The copy states a date that has passed — there is no judgement call, and a visitor can read it as easily as the scanner did. Fix or remove.
Then seasonal. A “Summer Sale” in November is usually stale, but check whether it is a permanent product name before editing. This is the class that needs a human.
Undated urgency last. “Limited time” with no date is not wrong, but it cannot be verified and it ages badly. Worth a policy decision rather than a one-off edit.

Preventing the recurrence

The ticket this skill exists for — “Remove Holiday Specials”, filed in August — is a process failure, not a copy failure. Two things reduce it:

Put an end date in the copy. A promo that states its own end date becomes machine-checkable, which moves it from the implied class into the explicit one.
Run the scan on a schedule, not on complaint. The whole point is catching it before the client does.

Editing safely

Promotional blocks are often in a page builder module or a global header/footer template. Editing a global template propagates everywhere — confirm scope before changing it.
Removing a promo can leave an empty section with its spacing intact. Check the rendered page, not just the source.
Clear the cache chain after the edit (page cache → CDN) and confirm on the live URL, or it will look like the edit did not take.

Full playbook → the team wiki’s promotional expiry & seasonal-offer standards.