/eol-readiness-advisor

name: eol-readiness-advisor
argument-hint: "[product or feature under EOL consideration, and what triggered it]"
description: "Run a go/no-go assessment for retiring a product or feature, then right-size the effort. Use when someone says \"we should probably kill this\" and nobody has made the call."
intent: >-
  Structured go/no-go assessment for sunsetting a product or feature. Determines whether EOL is the
  right call, how intense the sunset effort needs to be, and which organizational functions need to
  be involved. Prevents both premature kills and expensive delays on products that should have been
  retired sooner.
type: interactive
theme: eol-transition
best_for:
  - "Deciding whether a declining product should actually be retired — or held, harvested, or fixed"
  - "Right-sizing an EOL effort so a feature deprecation doesn't get a flagship playbook"
  - "Naming the obligations and landmines that make a sunset harder than it looks"
scenarios:
  - "Leadership keeps saying we should kill this module but nobody will make the call — help me assess it"
  - "We're retiring a hardware line with service contracts and channel partners; how big does this effort need to be?"
estimated_time: "15-25 min"

EOL Readiness Advisor

Purpose

Decide whether a product or feature should actually be retired — and if so, how much machinery the retirement deserves. This skill produces a go/no-go verdict with named evidence, an **intensity level** you choose, and a short list of the obligations that will bite you if ignored.

Most EOL guidance assumes the decision is already made and jumps to the plan. This skill sits earlier: it is the conversation where "we should probably kill this" becomes a decision someone will defend in a room.

It is equally willing to tell you **not** to retire. A "hold" or "harvest" verdict is a real outcome here, not a consolation prize.

Input

**Works best with:** The product or feature under consideration and what triggered the conversation (a declining number, a strategy shift, a support-cost complaint, an exec offhand remark).

**Also useful:** Revenue and customer counts, whether a replacement exists, contract or regulatory commitments, and any political sensitivities you already know about.

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 opens by asking what's under review and why, then walks you through blast radius, intensity, and transition path one question at a time. You do not need the numbers in front of you — "I don't know" is a valid answer that becomes a labeled assumption in the verdict.

**Example invocations:**

• `Should we retire our legacy reporting module? Usage is down 60% and support costs are climbing.`
• `EOL readiness check on our NFA-200 controller line — 120 installs, channel partners, UL certified.`

---

Key Concepts

The Right-Sizing Dial

**Not all EOLs play out the same.** Some are a changelog entry and a support macro. Some consume the whole company for three quarters. Most land in the middle. The single most common EOL failure in either direction is a mismatch between the size of the sunset and the size of the response — a flagship retirement run as a Jira ticket, or a feature deprecation that spawns a steering committee.

So the intensity is a **dial you set**, not a verdict the framework hands you:

| Dimension | Level 1 — Light | Level 2 — Standard | Level 3 — Heavy | |---|---|---|---| | Typical scope | Feature, internal tool, unversioned API | Commercial product with active customers | Revenue-critical, hardware, regulated | | Stakeholder stops | 3-4 | 7-8 | 10+ | | Lifecycle gates used | 2-3 (NSC, EOS, EOL) | 4-5 (NSC, EOS, EOE, EOM, EOL) | All 8 (GA through EOSRV) | | Functional areas | Product, Eng, Support, Docs | + Sales, Marketing, CS, Finance, Legal, IT, Data | + Supply Chain, Channel, Regulatory, Org | | Enablement | Support FAQ only | + Sales talking points, objections, escalation | + Channel brief, account tiers, training | | Customer message | Brief notice | Standard with phase table | Full with compliance section | | Typical lead time | Weeks | 6-12 months | 12-24 months |

**Level 2 is where most sunsets belong.** Treat it as the default and argue your way up or down.

**The dial is yours to move.** Recommend a level, explain the reasoning, then let the user override in either direction — and let them move it again later. A PM who says "give me the light version, I know my org" is exercising judgment, not making an error. Honor it, and note in one line what the lighter level leaves uncovered so the choice is informed rather than blind.

Lifecycle Gates (shared vocabulary)

EOL is not one date. It is a series of gates, and most customer anger comes from collapsing them into a single announcement:

• **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

Light sunsets use three of these. Heavy sunsets use all eight. Naming the gates you're *not* using is as useful as naming the ones you are.

The Four Retire Signals

Evidence that supports a go verdict. Two or more, strongly present, is a real case:

1. **Financial viability** — costs exceed revenue; support load drains disproportionate resources 2. **Strategic alignment** — conflicts with company direction; you are exiting this market 3. **Solution replacement** —