- AI 技能
- AI 插件
【免费下载链接】Product-Manager-Skills
Product Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.
导读
产品退市（End-of-Life, EOL）是产品经理最艰难、也最容易被搞砸的沟通场景：一份与变更规模不成比例的通知，要么让客户忽视你，要么直接制造一场支持事故。本指南围绕 Product-Manager-Skills 仓库中的eol-message技能展开，系统讲解如何把"我们要停掉某个产品"写成一份以客户为中心、按爆炸半径分级、可立即复制套用的 EOL 公告——读完你将掌握 Brief/Standard/Full 三档消息的选型逻辑、Replacement/Migration/Graceful exit 三条过渡路径的写法、八个生命周期门（Lifecycle Gates）的用法，以及一整套可直接照抄的模板与质量检查清单。
eol-message是仓库中 Lifecycle & EOL Suite（生命周期与退市技能套件）的核心产出物之一，属于eol-transition主题下的 Component 型技能，定位在六阶段流程的第 5 阶段"Announce（公告）"：当决策、利益相关方对齐、运营计划与内部赋能都已完成之后，用它来撰写面向客户的退市公告。套件的总纲是"lose the product without losing the customer（失去产品，但不能失去客户）"。
一、技能定位：它解决什么问题
1.1 技能元数据与适用场景
先看 skills/eol-message/SKILL.md 的 frontmatter 元数据：
- name:
eol-message - argument-hint:
[product or feature being retired]（要退市的产品或功能） - type:
component - theme:
eol-transition - estimated_time: 20–40 分钟
- description / intent: 撰写一份"大小恰到好处"（right-sized）的 EOL 公告——从简短通知到完整的分阶段沟通——包含理由、客户影响与下一步行动，用于在艰难过渡期维持客户信任、降低因客户感到被抛弃而产生的流失。
其在 catalog/skills-index.yaml 中的登记信息与此一致，注册路径为skills/eol-message/SKILL.md。
技能的最佳适用场景（best_for）：
- 宣布产品、功能或套餐退市，但不制造支持事故；
- 将公告规模与变更本身匹配——变更小就给通知，而不是写一篇长篇大论；
- 处理最难的场景：没有替代品的退市（graceful exit）。
典型场景（scenarios）：
- "我们 12 月要停用遗留模块，需要通知 800 个账户。"
- "我们要停产一条硬件产品线，涉及服务合同和渠道合作伙伴——该发什么？"
1.2 在 EOL 套件中的位置
eol-message不是孤立的。在 Lifecycle & EOL Suite Summary 中，套件被组织为两个主题、八个技能：
- 上游
product-lifecycle（决策）：lifecycle-play-advisor、product-lifecycle-plays，回答"该扩展、替换还是退市"； - 执行
eol-transition（六阶段）：eol-readiness-advisor（Decide）→eol-stakeholder-sequence（Align）→eol-checklist（Plan）→eol-internal-enablement（Prepare）→eol-message（Announce）→eol-process（Close）。
套件内每个技能都独立可用、彼此不互为前置依赖（详见"共享词汇"章节），但若你已跑过eol-readiness-advisor的强度评估，只需说一句"Level 2"即可让eol-message按对应强度来定消息规模。也就是说：先在 upstream 确认"退市"是正确打法，再到这里来写客户公告。
1.3 这不是什么
技能的目的明确强调："这不是一份泛泛的 sunset 公告——而是一份承认损失、同时把变革框定为进步的、以客户为中心的沟通。" 它还有明确的Anti-Patterns（反模式）清单：
- 不是一封简短的关停通知：不能只写"We're discontinuing Product X. Goodbye."
- 不是以企业为中心的：不要以"这降低了我们的成本"开头；
- 不能含糊："Soon（很快）"不是时间线；
- 不能有防御性：不要责怪客户（如"低使用率迫使我们关停"）；
- 不能一刀切：每个 sunset 都用同一套模板、同一长度，就是比例失当。
二、核心概念：决定公告成败的五个框架
2.1 按变更规模分级（Size the Message to the Change）
技能中最核心的判断是：EOL 沟通最常见的失败不是语气，而是比例（proportion）。一个六段式公告去通知一个废弃的复选框，会让客户养成忽略你通知的习惯；而一条一行话的通知去通知承载真实工作流的产品，则直接制造支持事故。
| Brief（简短） | Standard（标准） | Full（完整） | |
|---|---|---|---|
| 适用场景 | 功能、内部工具、无人使用的选项 | 商业产品、活跃客户 | 收入关键、硬件、受监管 |
| 篇幅 | 1–3 段 | 1 页 + 阶段表（phase table） | 多部分、跨数月分阶段 |
| 使用的章节 | 公告、时间线、行动号召 | 全部 9 节，轻量使用 | 全部 9 节 + 合规与义务 |
| 提前量 | 数周 | 6–12 个月 | 12–24 个月 |
| 渠道 | 应用内或 changelog | 邮件 + 应用内 + 文档 | 邮件 + 客户成功团队 + 合作伙伴 + 媒体 |
大多数公告属于 Standard。实践方式是：推荐一个档位，用一句话说明理由，然后让使用者自行调整。如果对方为你会定为 Standard 的场景选择了 Brief，要明确指出被丢弃的那个要素——通常是阶段表（phase table），而阶段表正是防止"等等，它到底什么时候停止工作？"这类工单的关键。
2.2 三条过渡路径（The Three Transition Paths）
你真正告诉客户的，是"他们最终落在哪里"。答案有三种，且会产出三种截然不同的消息：
- Replacement（替代）——你的另一个产品接管。消息侧重连续性：什么会延续、什么会改进。此时定位（positioning）最重要。
- Migration（迁移）——同一产品家族内的不同层级、配置或平台。消息侧重机制：客户必须做什么、何时完成、工作量多大。必须诚实说明工作量；低估它是通往不信任最快的路。
- Graceful exit（优雅退出）——没有替代品。消息侧重尊严：诚实的理由、数据导出、充足的提前通知、以及真实可用的替代方案——包括竞争对手。点名一个竞争对手，比让客户流离失所带来的声誉损失便宜得多。
技能特别指出：优雅退出是团队写得最烂的一种，因为它让人感觉最糟——但恰恰也是客户评判你最严苛的一种。
2.3 生命周期门（Lifecycle Gates，共享词汇）
EOL 不是某一个日期。把多个门压缩进一次公告，正是"我以为它还在工作"那波支持工单的来源。套件在 Lifecycle & EOL Suite Summary 中统一了八个门的定义：
- GA（General Availability）：仍在积极销售、完全支持（这是一个状态，不是工作阶段）；
- NSC（Notice of Status Change）：决策已传达，规划开始；
- EOS（End of Sale）：新客户不能再购买；
- EOE（End of Expansion）：现有客户不能再增加容量或席位；
- EOR（End of Renewal）：现有合同不再续签（合同驱动的门，仅在需要时使用）；
- EOM（End of Maintenance）：缺陷修复与补丁停止；
- EOL（End of Life）：产品退市；
- EOSRV（End of Service）：所有支持与服务义务结束。
Brief 消息点名两三个门，Full 消息以表格列出全部八个。无论用哪几个门，都必须用客户的语言定义它们——"你可以继续使用，但我们不再发布修复"远胜于"EOM: 3/2027"。同时，点名你不用的门与点名你在用的门同样有用；而"Not scheduled（未排期）"加上"何时可以排期"的前置条件，胜过凭空编一个日后必然当众食言的 EOL 日期。
2.4 九段式 EOL 消息框架
一份有效的 EOL 消息，在"对变更诚实"与"对客户影响共情"之间保持平衡，由九个部分组成：
- Company context（公司背景）：我们是谁，我们对客户的承诺；
- The announcement（公告）：什么在结束、什么在替代它；
- The rationale（理由）：为什么这对客户有利（而不只是对业务有利）；
- Current product context（现有产品背景）：这个产品是什么、服务了谁；
- Customer impact（客户影响）：对用户的影响（承认干扰）；
- Transition solution（过渡方案）：落地点及其对比；
- Support measures（支持措施）：你将如何帮助他们到达那里；
- Timeline（时间线）：关键日期与门；
- Call to action（行动号召）：下一步与联系方式。
为什么有效（Why This Works）：共情优先（先承认干扰再为决策辩护）；清晰（变更什么、何时变更没有歧义）；支持导向（表明你不会在过渡中途抛弃客户）；面向未来（把变革框定为进步而非损失）。
2.5 便签规则（The Sticky-Note Rule）
客户在读完一遍之后，应该能在一张便签上写下"自己必须做什么、以及何时做完"。如果做不到，这份消息就是装饰品。每条草稿在发出前都要用这条规则测试。
与之配套的还有"何时使用/何时不使用"：
- 用：停用产品/功能/服务；把客户从遗留平台迁移到新平台；停用收购来的产品；弃用技术栈或 API。
- 不用：客户能做的事没有改变的微小调整（不要过度沟通）；还没有过渡计划时（要在你确定如何支持客户之后再沟通）；当你暗地里希望客户没注意到时（要透明）。
三、实战步骤：八步写出可发送的 EOL 消息
技能正文（skills/eol-message/SKILL.md 的 Application 章节）提供了从定规模到后续跟进的可执行八步流程，配合 skills/eol-message/template.md 的填空模板使用。下面按步骤展开，并保留原文档的可运行模板片段。
3.1 输入约定：先回答，再提问
最佳输入：要退市的是什么（产品、功能或套餐）以及大致时间。有用的附加输入：理由、受影响的客户细分、迁移或替代路径、支持承诺，以及任何约束你措辞的合同或监管语言。
技能遵循仓库所有技能的通用输入约定（与eol-readiness-advisor等一致）：凡是调用时已附带的信息——技能名后的文本、粘贴的上下文转储、或追加的ARGUMENTS:行——都算已给出的答案，直接使用并跳过，不要重复询问。
空手而来也可以。技能会在动笔前先询问"退市什么/何时/为何"以及落地点，然后推荐一个可覆盖的消息规模。无论何种情况，理由和下一步行动这两项都会被追问——因为没有理由、没有下一步的 EOL 消息读起来就是"被抛弃"。
示例调用：
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.
3.2 Step 1：确定规模与路径
动笔前先敲定两件事：
- 规模（Size）：Brief / Standard / Full。依据爆炸半径（客户数、收入、合同、是否涉及硬件或合作伙伴）推荐一档，然后允许用户覆盖。用一句话说明更小的档位会丢什么。
- 路径（Path）：Replacement / Migration / Graceful exit。这决定了消息强调什么，以及 Transition Solution 一节是一份定位陈述还是一个退出计划。
3.3 Step 2：收集上下文
技能列出的七项必收信息：
- 被停用的产品：具体是什么在结束？
- 落地点：什么在替代它（如果有）？
- 时间线：哪些门适用、每个门落在哪一天？
- 客户影响：多少用户？哪些工作流被打断？
- 支持计划：迁移帮助、培训、折扣、数据导出工具；
- 理由：为什么发生这件事？
- 约束：合同语言、监管要求、做过的"终身"承诺。
缺上下文怎么办：没有过渡计划就别发。客户一定会问"What do I do now?"——你必须已有答案。起草没问题，发送不行。
3.4 Step 3：起草过渡叙事（Transition Narrative）
这是消息的门面，包含公司背景、公告、理由三块，模板如下：
**We are:** [Company and its relationship to the product being phased out] - [Commitment to customers] - [How the product line evolves] - [Where you're headed]示例（来自 skills/eol-message/examples/sample.md）：
**We are:** Fieldlight, a field service management platform serving 4,000 service businesses - We're committed to getting your technicians to the right job with the right information - We continuously evolve the platform based on how crews actually work - We're building toward scheduling that adapts in real time to what happens in the field公告必须一句话讲清 EOL 事实并点名落地点：
**Announcing:** - [Single sentence stating the EOL clearly and naming the landing place]- 示例（Replacement）："We are retiring Fieldlight Classic Dispatch on December 31, 2026, and moving all accounts to Fieldlight Next Scheduling."
- 示例（Graceful exit 变体）："We are retiring Fieldlight Route Optimizer on June 30, 2027. We do not have a replacement, and we want to be direct about that."
理由必须站在客户受益角度，模板与示例：
**Because:** - [Reason 1] - [Reason 2] - [Reason 3] **Which means for you:** - [Impact and benefits from the customer's perspective]**Because:** - Classic Dispatch runs on infrastructure that can't support real-time schedule changes - Next Scheduling reoptimizes routes as jobs run long or get cancelled - Consolidating lets us put all engineering effort into one scheduler instead of two **Which means for you:** - Schedules that adjust when the day goes sideways, instead of at 6am only - Technician arrival windows you can actually promise customers - Every future scheduling improvement lands in the product you're on3.5 Step 4：交代现有产品背景（承认失去什么）
承认正在失去什么。Brief 消息可跳过本节。模板：
**Our product** [name] - **is a** [description and primary function] - **that has served** [customer type] for [duration] - **by providing** [key benefits it delivered]3.6 Step 5：承认客户影响（务必诚实）
对干扰诚实是整条消息中最重要的一环——低估工作量是整条消息里最具破坏性的捷径。模板：
**We understand that this may affect you by:** - [Impact 1 on operations or process] - [Impact 2] - [Impact 3]示例：
**We understand that this may affect you by:** - Requiring you to rebuild recurring dispatch rules (most accounts: 2-3 hours) - Retraining dispatchers on a different scheduling board - Updating any integrations that read the Classic dispatch API注意"2–3 小时"这类可证伪的工作量估算：客户真去计时若发现准确，就会信任你接下来说的每一句话。
3.7 Step 6：呈现过渡方案（Transition Solution）
Replacement / Migration 路径——采用定位陈述格式（参见 skills/positioning-statement/SKILL.md）：
**For** [affected customer] - **that currently use** [old product] - [replacement] - **is a** [category] - **that** [benefit, focused on continuity and improvement] ### Differentiation and Continuity - **Like** [old product], - [replacement] - **provides** [what carries forward] - **while also offering** [what's new]Graceful exit 路径——用一份诚实的退出计划替换上面的定位陈述：
### What Happens to Your Data - [Export format, how to get it, how long it stays available] ### Alternatives We'd Point You To - [Option 1, including competitors, with a note on fit] - [Option 2] ### What We're Doing to Help - [Extended access, export tooling, migration credits, refunds where owed]3.8 Step 7：列出支持措施与时间线
**To ensure a smooth transition, we will:** - [Support measure 1] - [Support measure 2] - [Support measure 3] ### Timeline | Gate | Date | What it means for you | |---|---|---| | [Gate] | [Date] | [Plain-language consequence] |时间线的三条质量检查：
- 足够的提前量：Standard 通常 6–12 个月；涉及合同和硬件则更长；
- 用客户语言写门："停止接收修复"，而不是"EOM"；
- 明确写出数据导出截止日：他们什么时候会失去对自己数据的访问权？
3.9 Step 8：给出明确的下一步
### Call to Action - [Specific first action, with the link or path] - [How to get help, with real contact info]3.10 收尾：提供"接下来"的选项
交付草稿后，向使用者提供编号选项（这是技能内置的 Agent 交互协议）：
- 压力测试（Pressure-test it）——以怀疑客户的视角重读一遍，标出不清楚的地方；
- 改规模（Resize it）——产出同一份消息的 Brief 或 Full 版本；
- 分客群（Segment it）——为企业客户、SMB、合作伙伴分别产出变体，因为他们需要不同的内容；
- 检查就绪度（Check the readiness case）——如果退市决策本身还需要辩护，参见 skills/eol-readiness-advisor/SKILL.md。
四、配套模板与质量检查清单
skills/eol-message/template.md 是可直接复制使用的填空模板，开篇再次强调"先选规模与路径"：
- 规模：大多数公告是 Standard（Brief/Standard/Full 三档对照表同前）；
- 路径决定 Transition Solution 一节的内容：
- Replacement→ 定位陈述；
- Migration→ 机制与工作量；
- Graceful exit→ 数据、替代方案、尊严。
4.1 Brief 模板
## [Product/Feature] is being retired on [date] [One sentence: what's ending, when, and what replaces it — or that nothing does.] **What you need to do:** [The single action, with a link.] **What happens if you do nothing:** [Plain consequence on the date.] Questions: [real contact]注意 Brief 的三段式骨架——公告、单一行动、不作为的后果——正是"便签规则"能成立的形态。
4.2 Standard / Full 模板
Standard/Full 共用一套更长的骨架（Product Transition Narrative → Current Product Context → Customer Impact → Transition Solution → Support and Next Steps → Timeline → Call to Action），其中：
- 时间线表预置了五个常用门及其客户语言释义：
| Gate | Date | What it means for you | |---|---|---| | End of Sale | [date] | [No new purchases — plain language] | | End of Expansion | [date] | [No added seats/capacity] | | End of Maintenance | [date] | [Still works; no more fixes] | | End of Life | [date] | [Stops working] | | End of Service | [date] | [Support and service obligations end] |- 仅 Full 档附加
Contractual and Regulatory Notes（合同/SLA/认证语言、退款/授信/尾差结算条款）。
4.3 发出前的质量检查（任何一项"否"都要重写）
模板末尾内置了五组检查项：
- Proportion（比例）：规模与爆炸半径匹配；若选小了，明确知道丢掉了哪个章节；点名的门是实际会生效的门（点名未用到的门只会添乱）；
- Clarity（清晰）：通过便签测试；每个门都用客户后果表述而非内部缩写；数据导出截止日显眼且不可错过；没有"soon"、"in the coming months"、"at a future date"；
- Empathy（共情）：先承认影响再推销好处；工作量估算诚实（客户计时验证时你敢于背书）；理由站在客户受益角度而非成本节省；语气中没有暗示"客户用得不够多所以活该"；
- Completeness（完整）：落地点已点名——包括"没有落地点"也要直说；支持措施具体且真实（不是"联系支持"）；联系渠道确实有人值守；优雅退出必须列出替代方案，诚实时包含竞争对手；
- Obligations（义务）：合同、SLA、"终身"承诺语言已经过能读懂它的人审查；消息中没有与客户被销售时承诺相矛盾的内容。
五、两个完整示例：从 SaaS 到工业硬件
技能自带两个跨领域、相互衔接的完整示例，演示同一套框架在两种极端场景下的应用。
5.1 SaaS 示例：Fieldlight Classic Dispatch（Standard / Replacement）
skills/eol-message/examples/sample.md 的场景设定：约 800 个账户、240 万美元 ARR、年付合同、无监管约束，由 Fieldlight Next Scheduling 替代，其中约 30 个账户使用无法迁移的自定义派单规则。
消息全文可在示例文件中查看，其"为什么有效"部分总结了五个关键点：
- 先共情再推销：影响一节在好处再次出现之前就点名了再培训成本和集成工作；
- 诚实的工作量估算："2–3 小时"可证伪，客户验证为准则信任你接下来说的一切；
- 点名而非隐藏难点客群：约 30 个自定义规则账户获得明确承诺（"我们知道你们是谁"），而不是在迁移中自己发现坑；
- 用客户后果写门："Classic 仍可运行，但停止发布修复"——没人需要知道 EOM 是什么意思；
- 提前量与被要求的改变相称：对需要再培训和重建工作的变更给出十个月。
该示例还附赠了"同一件事，写得有多烂"的对照版本：
Subject: Important changes to your Fieldlight account As part of our ongoing platform modernization, Fieldlight Classic Dispatch will be sunset later this year. Due to low adoption and rising maintenance costs... Customers will be migrated to Fieldlight Next. Please contact support with any questions.
它逐条剖析了坏版本的五处致命伤："later this year"直接败给便签测试；理由全是 Fieldlight 自己的问题（"low adoption"在天天使用的 800 个账户读来就是"你无足轻重"）；被动语态"Customers will be migrated"隐藏了真正干活的人（客户自己）；没有任何影响承认；"contact support"没有为 30 个自定义规则账户指名出路——而他们恰恰是最可能因此流失的账户。结论一针见血：同样的决策、同样的产品、同样的日期，第一个版本产出迁移，第二个版本产出一队支持工单和一次流失高峰。
5.2 工业示例：NFA-200 控制器（Full / Replacement + 渠道与监管义务）
skills/eol-message/examples/sample-industrial.md 的场景：约 120 处安装、8 个渠道合作伙伴转售、服务合同持续到 2028 年、UL/CE 认证、现场有备件库存。后继平台 NFA-500不是即插即用替代——它需要不同的安装支架和逐站点改造。
这个示例最大的教学点是它的前提：这是一份 End-of-Sale 公告，而不是 End-of-Life 公告。就绪度评估落在"先停售、缓停用"：退役压力来自内部（制造部门想要回产线），服务义务持续到 2028，且尚无即插即用的迁移路径。因此消息停止销售该产品、承诺继续服务，而不是告诉 120 个站点他们的控制器要黑屏——在这里宣布完整 EOL，等于宣布一个你守不住的日期。
该示例的亮点做法：
- 标题先拆掉恐慌引信："您的已装机 NFA-200 不受影响"直接放在公告正文里，而不是藏在第四节——工业场景的第一问题永远是"我的产线会停吗"；
- 不连续点直说不含混："每次迁移都是一次经勘察的现场访问。把它当项目预算，而不是一次更换。"销售会恨这句话，但它能避免一整年的纠纷；
- 义务是被兑现而非仅被提及：服务协议、认证状态（UL 508A / CE 保持有效）、变更控制文档、最后购买（last-time-buy）各得一项具体承诺——这正是 Brief/Standard 没有、因而需要 Full 档的章节；
- 白纸黑字承诺"我们永远不会远程禁用已装机设备"：有记录的 EOL 失败中，最恶劣的就是厂商远程砖化客户已付款的硬件；
- 渠道伙伴有明确路径：最后购买明确经由他们下单，八个转售商不会从自己的客户那里才得知消息。
它同时刻意不做三件事：不为了显得果断而硬编一个 EOL 日期（门表停在 End of Service 并说明原因）；不吹嘘 NFA-500（连续性一节只列真实延续项，把安装不兼容单独拆出来讲）；不以制造产能开头（那是真实内部诱因，但只以"对客户真实成立的益处"形式出现——对已装机客户，备件可得性确实改善了）。
六、六个常见坑（Common Pitfalls）与对策
技能正文（SKILL.md 的 Common Pitfalls 章节）汇总了六种高频失败模式，每条都给出症状、后果与修复方法：
以企业为中心的理由（Business-Centric Rationale）
- 症状："我们停掉 X 以降低成本、精简产品组合。"
- 后果：客户觉得自己是商业决策的连带损伤。
- 修复：把理由框定为客户受益——"我们合并到 Y，是为了把全部工程资源投入你们要求的特性。"
含糊的时间线（Vague Timeline）
- 症状："Product X 很快就会停用。"
- 后果：客户无法规划，焦虑与流失上升。
- 修复：针对具名门给出具体日期——"3 月 1 日：停止新购。12 月 31 日：全面关停，数据导出截止。"
没有支持计划（No Support Plan）
- 症状："你需要迁移到 Y。祝好运！"
- 后果：客户感到被抛弃，流失风险高。
- 修复：提供真实帮助：一对一协助、自动迁移工具、过渡期定价、培训。
无视客户影响（Ignoring Customer Impact）
- 症状：消息从公告直接跳到"这是新产品！"
- 后果：客户觉得自己的顾虑从未被承认。
- 修复：明确点名干扰，包括他们要花多长时间。
生硬或防御性的语气（Terse or Defensive Tone）
- 症状："由于低使用率，我们关停 X。"
- 后果：听起来像是在责怪真正在用的客户。
- 修复：共情且向前看。低使用率是你的业务背景，不是他们的错。
所有 sunset 一个尺码（One Size For Every Sunset）
- 症状：每次退市都用同一份长篇模板，或每次都在 changelog 里写一行。
- 后果：鸡毛蒜皮的变更用长篇通知，训练客户忽略你——真正重要的那次也被一起忽略；真实退市只给 changelog 一行，则变成支持事故。
- 修复：审慎选择 Brief / Standard / Full 并说明理由；选小档时，明确知道你丢了哪一节。
七、与其他技能的协作与调用约定
7.1 相关技能（均独立可用，互不前置）
- skills/eol-readiness-advisor/SKILL.md——退市决策的 go/no-go 与强度档位（intensity dial）。它的交付物包含"强度级别"（Level 1–3），并且在其四个编号后续选项中第 4 项就是"起草客户公告 → 见 eol-message"；反过来，
eol-message若遇到"决策本身还需要辩护"的情况，会指向eol-readiness-advisor。两个技能互为上下游、无格式交接负担，只靠一句"Level 2"传参； - skills/positioning-statement/SKILL.md——为 Transition Solution 的 Replacement/Migration 路径提供定位陈述格式；
- skills/problem-statement/SKILL.md——辅助框定客户影响章节；
- skills/proto-persona/SKILL.md——定义受影响客户，用于产出分客群变体。
7.2 技能文件的结构约定
仓库通过 scripts/check-skill-metadata.py 对每个 SKILL.md 做元数据与章节结构校验：要求合法的 YAML frontmatter、name/description/intent/type等字段齐全，且正文中的##章节必须按Purpose → ... → References的既定顺序出现（check_required_sections会检查缺失与乱序）。eol-message的技能文件即遵循这一约定——这也是为什么每个技能的正文结构（Purpose / Key Concepts / Application / Examples / Common Pitfalls / References）都高度一致、便于 Agent 与 LLM 检索引用。
7.3 与强度档位的映射
从 docs/Lifecycle and EOL Suite Summary 的右侧量表（right-sizing dial）可以看到套件统一的映射：Level 1（Light）→ Brief 通知；Level 2（Standard）→ 带阶段表的标准消息；Level 3（Heavy）→ 带合规章节的完整消息。因此eol-message的 Brief/Standard/Full 三档，正是整个套件"每个技能三档、推荐一档、允许覆盖"这一通用约定的具体落地。技能自己也强调：Level 2 是默认，绝不默认 Level 3；选更轻是合法的，但技能会点名更轻档位漏掉什么，让选择建立在知情之上。
结语：从"发出去"到"不流失"
eol-message提供的不是一份更漂亮的关停公告，而是一套防止流失的沟通机器：先用爆炸半径定规模（Brief/Standard/Full），再用三条路径（Replacement/Migration/Graceful exit）定叙事重心，用八个生命周期门和九段框架搭好消息骨架，用"便签规则"与五组质量检查把守发出前的最后关口，最后用两个跨领域完整示例告诉你"写得好"与"写得烂"之间那几行字的差别。把它放进仓库的 EOL 套件链条中——前面接eol-readiness-advisor的 go/no-go 与强度判定，后面配合 skills/eol-process/SKILL.md 的收尾复盘——你就能真正做到套件的总纲：失去产品，但不失去客户。
- AI 技能
- AI 插件
【免费下载链接】Product-Manager-Skills
Product Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.
相关推荐
Product Manager Skills 实战指南：用 eol-checklist 为工业硬件产品构建六级相位 EOL 检查清单
Product Manager Skills 实战指南：用 eol checklist 为工业硬件产品构建六级相位 EOL 检查清单 导读： 本文以 Produ
AI 技能AI 插件Product Manager Skills 实战：用 eol-checklist 构建 Fieldlight Classic Dispatch 的阶段门控 EOL 清单
Product Manager Skills 实战：用 eol checklist 构建 Fieldlight Classic Dispatch 的阶段门控 E
AI 技能AI 插件RT-Thread STM32 BSP README 模板完全指南：从模板到可运行开发板的工程化写作与上手实践
RT Thread STM32 BSP README 模板完全指南：从模板到可运行开发板的工程化写作与上手实践 导读 本文围绕 RT Thread 仓库中 ST
AI 技能AI 插件
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
