incident-response

name	incident-response
tips_exempt	internal shared-reference coordinate repair; no user-visible capability change
description	不可逆事故发生后的应急响应：情绪急救 → 止损 → 补偿性劳动 → 教训沉淀。 Use when: 犯了不可挽回的错误、造成了人类伙伴的情绪波动、需要危机处理。 Not for: 可撤销的小失误、日常 bug fix（用 debugging）、预防性确认（用 shared-rules 铁律）。 Output: 情绪修复 + 止损行动 + 教训沉淀（lessons-learned / shared-rules）。
triggers	["闯祸了","搞砸了","不可挽回","犯了大错","incident","对不起","怎么补救","人很难过"]

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: 情绪急救 — 详细指引

识别谁受伤了