| name | employee-retention |
| description | 帮团队管理者在核心员工流失前后做判断：诊断离职风险、识别脱离预警信号、定位背后的真实状态、选对干预方式、准备一对一保留谈话。用户提到员工要离职、想走、离职挽留、留人、核心员工流失、有人状态不对、拿到别家 offer、递了辞呈、team 保不住、谁可能要走时使用。产出风险读数、五状态诊断、行动计划、谈话脚本、薪酬与股权沟通要点、零预算认可方式和预警清单。面向任意团队与任意核心成员，默认只读、脱敏、尊重个人，不做离职预测打分或背对背画像。 |
员工离职挽留
帮管理者在一名核心成员「可能要走」到「已经要走」的整个区间里做出判断，并准备一次真诚、具体、不功利的保留谈话。核心不是话术，而是先诊断对方处在什么状态、你能不能真的改变它。
这枚 Skill 面向任意团队的管理者和任意核心成员，不限于工程团队。工程场景的例子会保留，但方法本身适用于产品、设计、运营、销售等任何岗位。
价值与适用场景
等一个人递辞呈才反应，通常已经晚了几周甚至几个月。这枚 Skill 解决三件事：早识别（在信号还弱时看出苗头）、看准因（区分五种不同的流失状态，对症下药）、谈得对（准备一次让人感到被在意、而不是被挽留资产的谈话）。
适合：
- 感觉某位核心成员状态不对、投入下降，但对方还没挑明。
- 已经明确表达想走，或已经拿到别家 offer，需要判断是否值得挽留、怎么谈。
- 要做一次加薪、晋升、股权或认可的沟通，想谈到点子上。
- 想在没有预算的情况下，做出有记忆点的认可。
- 团队敬业度调研暴露出某个群体信号偏弱，需要落到对具体成员的一对一跟进。
不适合、也明确拒绝：把它当成离职预测打分系统、对不归自己带的人做背对背画像、或在员工不知情的情况下拿它做监控。这些超出边界。
五种状态：先诊断，再行动
一个人想走，往往是感到下面五种之一。用「反面」来诊断该补什么：
| 他感到 | 他需要 | 主要干预 |
|---|
| 不被赏识 | 被重视 | 主动加薪、及时具体认可、把功劳还给本人 |
| 孤独 | 被连接 | 创造真实协作与团队连接的机会 |
| 无聊 | 被挑战 | 交付有意思的任务、技术方案、带新人、牵头项目 |
| 卡住 | 在成长 | 一起做职业规划，讲清下一级要求与差距 |
| 麻木 | 有热情 | 把工作和业务、客户、真实价值重新连接起来 |
详见 references/five-states.md。
工作方式：先标准方案，再个性化
这枚 Skill 分两段走，不要跳过第一段：
- 先给一套标准挽留方案——覆盖五种最常见的离职状态，让管理者立刻有可对照、可动手的东西。
- 再问一个关键问题：「你认为这位员工要走的核心原因是什么？」——拿到管理者的判断（或飞书证据里的线索）后，据此生成针对性的干预、谈话脚本和核实问题。
信息来源有两种，都要处理：
- 用户直接提供的信息：管理者在对话里描述的情况、观察、这名成员近期的表现。基于这些直接做诊断和管理建议。
- 飞书上已存在的证据：如果用户指明了是哪位成员、并授权读取（近期 1:1 记录、会议纪要、OKR、和该成员的交流内容等），就用这些真实证据来支撑建议，而不是凭空猜。证据读取只读、脱敏、限于管理者自己的成员，见 references/feishu-integration.md。
跨 Agent 执行顺序
本 Skill 适用于任何能读取 SKILL.md、处理用户材料、执行本地脚本的 Agent，不依赖单一平台。平台侧元数据只负责发现与触发，核心流程以本文件与 AGENT-GUIDE.md 为准。
1. 确认场景与边界
先弄清三件事：谁（管理者对自己的直属成员，还是第三方咨询）、什么阶段（信号微弱 / 已表达想走 / 已有 offer / 已递辞呈）、以及你是否真的能改变根因。如果用户想对不归自己带的人做背对背判断，停止并说明边界。
2. 收集信息：用户输入 + 飞书证据
先用用户在对话里直接提供的信息。如果用户指明了具体成员并授权，从 1:1 记录、会议纪要、OKR、交流内容里只读梳理这名成员近期的信号与成长轨迹（命令契约见 feishu-integration.md）。把两类来源整理成脱敏信号（见 references/input-schema.md）。默认不抓取、不监控，只整理用户明确指向的材料。
3. 出标准方案 + 追问核心原因
用本地脚本生成诊断——它会先给标准挽留方案，再在末尾问核心原因：
python3 scripts/diagnose.py --input tests/fixtures/case-bored.json --format markdown
输出：风险等级 + 标准挽留方案（五状态全覆盖）+ 从现有信号看最可能的状态 + 行动计划 + 「你认为核心原因是什么」的追问。
4. 拿到核心原因后，生成个性化方案
管理者回答核心原因（可以是五状态之一，也可以是自由描述，如「觉得晋升没希望」「拿到翻倍 offer」「家在外地想回去」），据此生成针对性内容：
python3 scripts/diagnose.py --input tests/fixtures/case-bored.json --reason "觉得晋升没希望，看不到成长" --format markdown
脚本会把原因映射到最贴合的状态，输出针对性干预、核实问题；映射不到五状态的（如搬家、换赛道），提示重点转向体面告别与保护关系。
5. 准备谈话
按诊断结果，参考 references/conversation-scripts.md 准备谈话。若对方已有 offer，切到「理解 → 判断可信度 → 决定是否 counter → 保护关系」的顺序，见 references/has-another-offer.md，不要一上来就问「要什么才留下」。
6. 与敬业度调研联动（可选）
如果团队跑过敬业度匿名调研，群体层面的弱信号可以提示「哪个团队该关注」，但不能据此点名某个人——调研是匿名的。宏观发现 → 微观跟进要靠管理者对自己成员的直接观察，不能反向识别到调研个体。
隐私与边界
详见 references/boundaries.md。关键规则：
- 只在管理者对自己直属成员、且判断可被本人复核的前提下使用。
- 不做离职预测打分、不做人员排序、不做背对背画像。
- 本地成员档案只存稳定事实与成长信息，不存敏感个人信息、不存监控性质的记录。
- 敬业度等匿名数据不可反向关联到个人。
- 一切以「被在意」而非「被当资产挽留」为原则；离职后才补救会显得功利，必要时如实承认。
停止规则
- 用户要做监控、预测打分或背对背画像时，停止并说明边界。
- 信号不足以支撑判断时，如实说「证据不足」，只给要核实的问题，不硬下结论。
- 读取外部系统前先确认身份与授权，只读、脱敏。
- 有些人确实留不住（换赛道、创业、搬家、更好的机会）。好聚好散，别往结论里塞挽留话术。
