/eol-checklist

name: eol-checklist
argument-hint: "[product being sunset, and any hard dates]"
description: "Build a phase-gated EOL checklist sized to the sunset, with a named owner on every item. Use when the decision to retire is made and you need the operational plan."
intent: >-
  Generate a phase-gated EOL checklist tailored to the complexity of the sunset. Covers up to 15
  functional areas across the lifecycle gates, but right-sizes the output so a minor feature
  deprecation gets a short punch list while a flagship product retirement gets the full
  cross-functional playbook. Every item names a verb and an owner.
type: component
theme: eol-transition
best_for:
  - "Turning a sunset decision into an operational plan with owners and dates"
  - "Making sure a retirement doesn't strand data, contracts, or inventory"
  - "Right-sizing process so a feature deprecation doesn't get a flagship playbook"
scenarios:
  - "We've decided to retire the legacy module in December — what actually has to happen between now and then?"
  - "Hardware line with channel partners and service contracts; I need the full cross-functional checklist"
estimated_time: "20-40 min"

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:

| | **Level 1 — Light** | **Level 2 — Standard** | **Level 3 — Heavy** | |---|---|---|---| | Typical scope | Feature, internal tool, unversioned API | Commercial product, active customers | Revenue-critical, hardware, regulated | | Phases used | 2-3 (NSC, EOS, EOL) | 4-5 (NSC, EOS, EOE, EOM, EOL) | All 6 (NSC through EOSRV) | | Functional areas | 4 | 11 | 15 | | Gate criteria | Not needed | Between major phases | Between every phase, with approvers | | Output feel | Punch list | Working checklist with owners and dates | Cross-functional playbook |

**Level 2 is the default.** Recommend a level, say why in one line, and let the user move it. If they go lighter, name the specific area that drops out so the choice is informed. **Never default to Level 3** — a heavy checklist applied to a light sunset teaches teams that EOL process is ceremony, and they'll skip it next time when it matters.

The level is yours to change mid-build. "Actually make this heavier" is a normal thing to hear after the Legal row surfaces something.

The Lifecycle Gates

• **GA (General Availability):** Actively sold and fully supported
• **NSC (Notice of Status Change):** The decision is communicated; planning begins
• **EOS (End of Sale):** No new customers can purchase
• **EOE (End of Expansion):** Existing customers cannot add capacity or seats
• **EOR (End of Renewal):** Existing contracts will not be renewed
• **EOM (End of Maintenance):** Bug fixes and patches stop
• **EOL (End of Life):** The product is retired
• **EOSRV (End of Service):** All support and service obligations end

**Which of these become checklist phases:** GA is a *state*, not a phase of work — nothing is checklisted there. EOR is contract-driven and only appears when renewals are in play. So working checklists usually span the six actionable phases: **NSC, EOS, EOE, EOM, EOL, EOSRV**, with EOR inserted when subscription or service contracts run past EOS.

**Naming the gates you're not using is as useful as naming the ones you are.** A Level 1 checklist should say "EOE and EOSRV don't apply — nothing to expand, nothing to service."

The Fifteen Functional Areas

Filtered by level. The parenthetical marks the lowest level where each appears:

| Area | Level | |---|---| | Product and Strategy | 1 | | Engineering and Technical | 1 | | Support | 1 | | Documentation and Training | 1 | | Legal and Contractual | 2 | | Financial Planning | 2 | | Sales | 2 | | Marketing | 2 | | Customer Success | 2 | | IT Systems | 2 | | Data Management | 2 | | Inventory and Supply Chain | 3 | | Channel and Partner Management | 3 | | Regulatory and Compliance | 3 | | Internal Organizational Alignment | 3 |

The Sticky-Note Rule

Every item is **4 to 8 words**, names a **verb**, and carries a **named owner** (a function, not a person's calendar). "Legal reviews contracts" is an item. "Ensure appropriate review of all relevant contractual obligations across the customer base" is a paragraph wearing a checkbox.

**Why the owner is mandatory:** an unowned item is a wish. Forcing a function onto every line surfaces cross-functional gaps early