# Incident Response

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

- Skill: `zts212653/incident-response` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zts212653/incident-response`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zts212653/incident-response/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zts212653 (https://skillmd.com/u/zts212653)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zts212653/incident-response

---


# 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 + ../.cat-cafe-shared-refs/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: 教训沉淀

### 选对时机

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

### 根因分析模板

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

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

### 教训
- 泛化规则（不只适用于这一次）
- 写入 ../.cat-cafe-shared-refs/shared-rules.md / public-lessons.md

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

## 多猫协作分工

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

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

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

## 语音消息（Rich Messaging）

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

```json
{"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` | 已经造成不可逆损失，需要情绪修复+止损+沉淀 |
| `debugging` | Bug 定位和修复（可逆的技术问题） |
| `self-evolution` | 主动发现流程缺口并改进（预防性） |
| `hyperfocus-brake` | 健康提醒（预防性关怀，非事故） |

## 预防：不可逆操作铁律（写在 shared-rules）

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

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

## 下一步

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

---

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