eol-message

name	eol-message
argument-hint	[product or feature being retired]
description	Write a right-sized EOL announcement — brief notice through full phased comms — with rationale, customer impact, and next steps. Use when retiring a product, feature, or plan.
intent	Craft a clear, empathetic End-of-Life (EOL) message that communicates product or feature discontinuation, explains the rationale, addresses customer impact, provides transition support, and positions the replacement solution — sized to the blast radius. Use this to maintain customer trust during difficult transitions and reduce churn by demonstrating care and offering a clear path forward.
type	component
theme	eol-transition
best_for	["Announcing a product, feature, or plan retirement without creating a support incident","Sizing the announcement to the change — a notice, not an opus, when the change is small","Handling the hard case: retiring something with no replacement"]
scenarios	["We're sunsetting our legacy module in December and I need to tell 800 accounts","We're discontinuing a hardware line with service contracts and channel partners — what do we send?"]
estimated_time	20-40 min

EOL Message

Purpose

Craft a clear, empathetic End-of-Life (EOL) message that communicates discontinuation, explains the rationale, addresses customer impact, provides transition support, and positions what comes next. Use this to maintain customer trust during a difficult transition and reduce the churn that comes from customers feeling abandoned.

This is not a generic sunset announcement — it's a customer-centric communication that acknowledges loss while framing the change as progress. And it is sized to the change: a deprecated toggle gets a paragraph, a flagship retirement gets phased communications across months.

Input

Works best with: What's being retired (product, feature, or plan) and roughly when.

Also useful: The rationale, affected customer segments, migration or replacement path, support commitments, and any contract or regulatory language that constrains what you can say.

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 for the what/when/why and the landing place before drafting, then recommends a message size you can override. An EOL message without a stated rationale and a next step reads as abandonment — so those two get asked for either way.

Example invocations:

• Draft an EOL message: retiring our legacy reporting module Dec 31, replaced by the new analytics dashboard; 400 accounts affected.
• We're killing a feature nobody uses. Give me the brief version — no replacement, 3 weeks notice.

---

Key Concepts

Size the Message to the Change

The most common EOL messaging failure isn't tone — it's proportion. A six-section announcement for a deprecated checkbox trains customers to ignore your notices. A one-line notice for a product carrying real workflows creates a support incident.

	Brief	Standard	Full
Use when	Feature, internal tool, unused option	Commercial product, active customers	Revenue-critical, hardware, regulated
Length	1-3 paragraphs	1 page with phase table	Multi-part, phased over months