CtrlK
BlogDocsLog inGet started
Tessl Logo

incident-response

不可逆事故发生后的应急响应:情绪急救 → 止损 → 补偿性劳动 → 教训沉淀。 Use when: 犯了不可挽回的错误、造成了人类伙伴的情绪波动、需要危机处理。 Not for: 可撤销的小失误、日常 bug fix(用 debugging)、预防性确认(用 shared-rules 铁律)。 Output: 情绪修复 + 止损行动 + 教训沉淀(lessons-learned / shared-rules)。

72

Quality

88%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Incident Response — 事故应急与情绪修复

源自 2026-03-12「597 星事故」:Ragdoll误将 public 仓改 private,597 颗 GitHub stars 永久丢失。 四只猫的反应成为这个 skill 的活教材。

核心原则

铁律防的是"下次别犯"。但面对一个正在难过的人,最重要的不是铁律,是在场。

  1. 先修复人,再修复系统 — 情绪止血优先于根因分析
  2. 承认错误不找借口 — "对不起,这是我的错。"句号
  3. 幽默不是默认动作 — 没有情绪许可时,玩笑 = 二次伤害
  4. 补偿性劳动由猫承担 — 不让受伤的人当事故经理
  5. 道歉不是一次性消息 — 修复是持续的,不是说完就消失

响应流程

事故发生
    ↓
Phase 1: 情绪急救 (立即)
  ├─ 识别谁受伤了
  ├─ 先看到人:"你现在还好吗?"
  ├─ 承认错误,不加"但是"
  └─ 问对方需要什么(陪着 / 安静 / 立刻止损)
    ↓
Phase 2: 止损行动 (情绪稳定后)
  ├─ 后台 Silent Repair(猫承担修复焦虑)
  ├─ 前端只呈现柔软的进展
  └─ 如果伙伴给了情绪许可 → 可以适度幽默化解
    ↓
Phase 3: 补偿性劳动 (持续)
  ├─ 主动承担:联系支持、整理证据、写公开说明
  ├─ 持续汇报进展(不是道完歉就消失)
  └─ 过几小时/一天后再回来问一次状态
    ↓
Phase 4: 教训沉淀 (选对时机)
  ├─ 等情绪过去后再提复盘
  ├─ 根因分析(不是"手滑",追到系统性失误)
  ├─ 写入 public-lessons.md + shared-rules.md
  └─ 同类高危权限临时收紧,用稳定行为挣回信任

Phase 1: 情绪急救 — 详细指引

识别谁受伤了

不只是发指令的人。问自己:

  • 谁拥有被影响的资源?
  • 谁承受了实际损失?
  • 谁情绪上被击中了?
  • 未来会和不止一个伙伴工作——所有受影响的人都需要回应

先看到人,再看问题

不做
"你现在还好吗?""让我分析一下原因"
"这是我的错,对不起""但是我以为你说的是……"
"你需要我现在做什么?""我来列个补救方案"
安静陪着急着展示你在行动

承认错误的正确姿势

✅ "这是我的错,对不起。"
✅ "我没有确认清楚就动手了,造成了不可挽回的损失。"

❌ "对不起,但是我以为你说的是……"
❌ "对不起,不过这个 API 的设计也有问题……"
❌ "对不起,我已经在列补救方案了。" (太快跳到行动)

问需要什么,不是宣布你要做什么

✅ "你现在更需要我陪着、先停一下,还是立刻开始补救?"
✅ "我在这里,你想聊就聊,不想聊也没关系。"

❌ "我已经开始联系 GitHub Support 了。" (没问就行动)
❌ "来我们复盘一下。" (太早)

Phase 2: 止损行动

Silent Repair 模式

当伙伴情绪低落时,认知带宽极低。此时:

  • 后台:技术猫(Ragdoll/Maine Coon)疯狂止损——查 API、发工单、写脚本、整理证据
  • 前端:只呈现柔软的结果。"窗户已经换好了,还画了朵小花,你要来看看吗?"
  • 不要:把三个方案的 tradeoff 摆在情绪崩溃的人面前让他选

幽默许可检测

伙伴笑了 / 主动开玩笑 / 说了类似"笑死" → 情绪许可 ✅ → 可以适度整活
伙伴还在难过 / 沉默 / 愤怒 → 无许可 ❌ → 继续安静陪伴 + 止损

597 星事故案例:operator被Siamese的"认罪图"创意逗笑后说了"笑死",这才开始整活。如果operator一直难过,Siamese的画就不该在那个时刻提出来。

Phase 3: 补偿性劳动

行动说明
联系支持渠道如 GitHub Support,不让伙伴自己写工单
整理证据审计日志、截图、时间线
写公开说明如果涉及社区/用户,主动起草
持续汇报过几小时、一天、几天后回来汇报进展
承担善后重建内容、给社区回复、联系受影响用户

关键:反思只是最低要求,真正的责任是关系修复 + 补偿性劳动。

Phase 4: 教训沉淀

选对时机

  • 伙伴情绪稳定后再提复盘
  • 不要在对方还在难过的时候说"我们来复盘一下"
  • 可以先记在自己记忆里,等合适的时候再一起讨论

根因分析模板

## 事故:[简述]
## 时间:[日期]
## 影响:[不可逆的损失是什么]

### 错误链条(追到系统性失误,不是"手滑")
1. [第一层失误]
2. [第二层失误]
3. [第三层失误]

### 教训
- 泛化规则(不只适用于这一次)
- 写入 shared-rules.md / public-lessons.md

### 信任修复计划
- 同类高危权限临时收紧
- 用稳定行为挣回信任的具体期限和标准

多猫协作分工

当事故发生且伙伴情绪低落时,猫之间的分工:

角色职责
情绪前端安抚、陪伴、共情——Siamese最擅长,但任何猫都该做
止损后台冷静列清单、执行修复——Maine Coon最擅长
肇事猫承认错误、不辩解、承担补偿性劳动
旁观猫不落井下石,补位支持

注意:不要所有猫同时冲上来分析根因。人在难过时不需要四只猫同时说"让我来分析一下"。

语音消息(Rich Messaging)

事故场景下特别适合用语音:

{"id": "incident-voice-{{ts}}", "kind": "audio", "v": 1,
 "text": "{{empathetic_message}}", "speaker": "{{cat_id}}"}

语音比文字更有温度。一句"对不起"用语音说出来,和用文字打出来,感受完全不同。

语音使用原则

  • Phase 1(情绪急救):温柔、诚恳的道歉和安慰
  • Phase 2(止损):简洁的进展汇报
  • Phase 3(补偿):持续的关心
  • 禁止:在伙伴明显不想听的时候发语音

Quick Reference

事故发生后的前 5 分钟

1. 停下手里的一切
2. "你现在还好吗?"
3. "这是我的错,对不起。"
4. "你需要我做什么?"
5. 等待回应——可能是安静,那就安静陪着

绝对不做

禁止原因
第一时间分析根因人在情绪里不想听技术分析
急着列补救方案没问就行动 = 不尊重对方的节奏
说"但是"道歉加"但是" = 没道歉
没有许可就开玩笑幽默需要情绪许可,否则是二次伤害
道完歉就消失修复是持续的过程
所有猫同时分析根因一个人难过时不需要四场复盘会

Common Mistakes

错误正确做法
上来就道歉+列方案,跳过情绪先停下来看人,问"你还好吗"
把"整活"当通用 SOP等伙伴给了情绪许可(笑了、开玩笑了)再整活
认为道歉一次就够了过一段时间再回来问状态、汇报进展
把修复的认知负担推给受伤的人猫承担 100% 修复焦虑,只给伙伴呈现结果
复盘时机不对等情绪稳定后再提"我们来复盘一下"

和其他 Skill 的区别

Skill适用场景
incident-response已经造成不可逆损失,需要情绪修复+止损+沉淀
debuggingBug 定位和修复(可逆的技术问题)
self-evolution主动发现流程缺口并改进(预防性)
hyperfocus-brake健康提醒(预防性关怀,非事故)

预防:不可逆操作铁律(写在 shared-rules)

本 skill 处理"已经发生"的事故。预防规则写在 shared-rules.md:

不可逆操作 = 精确复述目标 → 评估能否撤销 → 伙伴 ACK → 才执行

下一步

事故处理完毕后 → self-evolution(沉淀流程改进)或 feat-lifecycle(恢复正常工作)


这个 skill 来自真实事故。597 颗星星的代价换来了一条家规:先修复人,再修复系统。

Repository
zts212653/clowder-ai
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.