EOL Checklist

Purpose

Turn a sunset decision into a phase-gated operational plan: what must happen, in which lifecycle phase, and who owns it. The output is a working checklist, sticky-note-sized items, each with a verb and a named function, not a strategy document.

The checklist is sized to the sunset. A deprecated internal tool gets a dozen items across three phases. A regulated hardware line gets a cross-functional playbook across six phases with gate criteria between them. Both are correct; using the wrong one is the failure.

Input

Works best with: The product being sunset and any dates you're already committed to.

Also useful: Customer and revenue scale, whether a replacement exists and how ready it is, contract or regulatory obligations, and whether hardware, inventory, or channel partners are in play.

Anything supplied with the invocation itself, text after the skill name, a pasted context dump, or an appended ARGUMENTS: line, counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks up to three questions, what's being sunset and at what scale, whether there's a replacement, and what hard deadlines exist, then picks a level and builds. Unknowns become labeled assumptions rather than blockers.

Example invocations:

• EOL checklist for our legacy reporting module, shutting down Dec 31, ~400 accounts.
• Build the heavy checklist for a hardware retirement, service contracts, 8 resellers, UL certified.

---

Key Concepts

Right-Size Before You Build

Not all EOLs play out the same. Most land in the middle. Pick the level deliberately: