eol-checklist — Product Retirement EOL Checklist Generation Skill

Skill Overview

eol-checklist is an AI skill that turns a “product retirement decision” into a phased, actionable EOL checklist. Every task begins with a verb and identifies a clear owner. Checklist size automatically adapts to retirement complexity, covering everything from feature shutdowns to hardware product-line discontinuations.

Use Cases

1. Retiring legacy modules or internal tools: A decision has been made to retire a legacy module by a certain date, and you need to identify every task that must actually be completed between now and the retirement date—not another strategy document.
2. Retiring a hardware product line: A complex retirement involving channel partners, service contracts, in-transit inventory, and regulatory certifications requires a comprehensive cross-functional playbook with phase-by-phase approval gates.
3. Discontinuing a commercial product with paying customers: Customer contracts and renewals extend beyond the discontinuation date, requiring management of renewal language, SLA terms, data export windows, and customer migration paths.

Core Features

1. Three-tier sizing (Light / Standard / Heavy): Recommends an appropriate checklist size based on customer scale, revenue impact, contractual obligations, hardware, and channel factors. A feature shutdown produces a concise task list of around a dozen items, while retiring a flagship product produces a cross-functional playbook covering 15 functional areas and six phases—avoiding the use of heavyweight processes that overwhelm executors of lightweight retirements.
2. Six-phase lifecycle gates: Organizes work around NSC (Notification of Status Change), EOS (End of Sale), EOE (End of Expansion), EOM (End of Maintenance), EOL (End of Life), and EOSRV (End of Service). Each phase transition explicitly states what conditions must be met to proceed and who approves it, preventing a situation where “an announcement is sent and the system is quietly disconnected six months later.”
3. An owner for every task (sticky-note rule): Each item contains 4–8 words, starts with a verb, and identifies the owning function. If no owner can be identified for a task, that very fact exposes an unclaimed gap in the organization and should be escalated rather than glossed over.

Frequently Asked Questions

What scale of retirement is eol-checklist suitable for?

All three levels are supported, and the skill proactively recommends one: Light is suitable for features, internal tools, or non-versioned APIs, producing a concise checklist across 2–3 phases; Standard is suitable for commercial products with paying customers and contracts and is the default level; Heavy is suitable for revenue-critical, deployed hardware products, or products with channel partners or regulatory oversight, enabling all six phases and assigning approvers at every phase transition. You can have the skill recommend a level first and then adjust it yourself.

How does it differ from a project plan (Gantt chart)?

eol-checklist is not a project management tool: it has no Gantt chart, dependency graph, or resource loading. It answers “what needs to be done, in which lifecycle phase, and by whom,” while scheduling, dependencies, and resource allocation must still be handled through your project management process. It also does not replace communication itself—writing “align with Legal” in the checklist does not mean alignment has already taken place.

What if the EOL date is still uncertain?

Writing TBD is a valid entry. If the date should not be set before the migration path is ready, the skill will write Not scheduled and include a task describing the prerequisite conditions. The skill explicitly rejects inventing dates merely to fill a template—publicly committing to an EOL date and then postponing it will make customers distrust your second announcement.