# Eol Message

Write a right-sized EOL announcement, brief notice through full phased comms, with...

- Repository: https://github.com/deanpeters/Product-Manager-Skills (7825 stars)
- Category: Writing
- License: see repository
- Last updated: 2026-10-16
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add deanpeters/Product-Manager-Skills --skill eol-message -g -a claude-code -y`
Codex: `npx skills add deanpeters/Product-Manager-Skills --skill eol-message -g -a codex -y`
Cursor: `npx skills add deanpeters/Product-Manager-Skills --skill eol-message -g -a cursor -y`
Gemini CLI: `npx skills add deanpeters/Product-Manager-Skills --skill eol-message -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add deanpeters/Product-Manager-Skills`

## 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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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.

The rest: https://github.com/deanpeters/Product-Manager-Skills/blob/HEAD/skills/eol-message/SKILL.md
