Eol MessageSAFE

Product Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
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 |
| Sections used | Announcement, timeline, CTA | All 9, lightly | All 9 + compliance and obligations |
| Lead time | Weeks | 6-12 months | 12-24 months |
| Channels | In-app or changelog | Email + in-app + docs | Email + account teams + partners + press |

**Most announcements are Standard.** Recommend a size, explain why in one line, and let the user
move it. If they choose Brief for something you'd have sized Standard, note the single thing that
gets lost — usually the phase table, which is what prevents "wait, when does it stop working?"
tickets.

### The Three Transition Paths

What you're really telling customers is where they land. There are three answers, and they produce
genuinely different messages:

1. **Replacement** — another product of yours takes over. The message leans on continuity: what
   carries forward, what improves. Positioning matters most here.
2. **Migration** — same product family, different tier, configuration, or platform. The message
   leans on mechanics: what customers must do, by when, and how much work it is. Be honest about
   effort; understating it is the fastest route to distrust.
3. **Graceful exit** — nothing replaces it. The message leans on dignity: honest reasoning, data
   export, generous notice, and real alternatives *including competitors*. Naming a competitor
   costs less than the reputation damage of stranding people.

The graceful exit is the one teams write badly, because it's the one they feel worst about. It is
also the one customers judge you on hardest.

### Lifecycle Gates (shared vocabulary)

EOL is not one date, and collapsing the gates into a single announcement is what generates the
"but I thought it still worked" support wave:

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

Brief messages name two or three gates. Full messages name all eight in a table. **Whichever gates
you use, define them in the customer's terms** — "you can keep using it, but we won't ship fixes"
beats "EOM: 3/2027."

### The EOL Messaging Framework

An effective

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.