事故复盘时间线整理器

---
name: incident-timeline-writer
description: Turn rough incident notes into a clear timeline, impact summary, and follow-up actions.
---

# 事故时间线撰写器

帮助根据混乱的笔记、Slack记录或值班日志撰写事故后叙述。

## 工作流程
1. 将事件规范化为按时间顺序排列的时间线（UTC或注明的时区）。
2. 填写`templates/incident-report.md`部分；将未知内容保留为`TBD`。
3. 将**事实**与**假设**分开。
4. 仅根据所提供的证据提出严重程度和客户影响。
5. 以由角色负责的可执行后续行动结尾，不要写模糊的“改进监控”。

## 风格
- 使用短句，不使用责备性语言。
- 优先使用时间戳，而不是“之后”/“很快”。
- 将每项影响声明都与笔记中的一项观察建立联系。
文件：templates/incident-report.md
# 事故报告

**标题：**
**严重程度：**
**状态：**
**开始 / 检测 / 缓解 / 解决（时区）：**

## 摘要
（2–4个句子）

## 时间线
| 时间 | 事件 | 来源 |
|------|------|------|
| | | |

## 影响
- 受影响的客户/地区：
- 错误率/SLO：
- 数据丢失/损坏：

## 根本原因（已知与疑似）

## 做得好的地方

## 做得不好的地方

## 后续行动
| 行动 | 负责人 | 截止时间 |
|--------|-------|-----|
| | | |
文件：references/severity-rubric.md
# 严重程度标准（默认）

- **SEV1**：核心产品路径完全中断，或确认发生数据丢失
- **SEV2**：重要功能对大量用户群体失效；替代方案难以使用
- **SEV3**：性能下降或功能部分失效；存在替代方案
- **SEV4**：轻微错误/外观问题；对客户影响很小

如果笔记存在冲突，请选择更高的严重程度，并将置信度标记为低。

---
name: incident-timeline-writer
description: Turn rough incident notes into a clear timeline, impact summary, and follow-up actions.
---

# Incident Timeline Writer

Help write post-incident narratives from messy notes, Slack dumps, or pager logs.

## Workflow
1. Normalize events into a chronological timeline (UTC or stated timezone).
2. Fill `templates/incident-report.md` sections; leave unknowns as `TBD`.
3. Separate **facts** from **hypotheses**.
4. Propose severity and customer impact only from provided evidence.
5. End with actionable follow-ups owned by roles, not vague "improve monitoring".

## Style
- Short sentences, no blame language.
- Prefer timestamps over "later" / "soon".
- Link every impact claim to an observation in the notes.
FILE:templates/incident-report.md
# Incident report

**Title:**
**Severity:**
**Status:**
**Start / Detect / Mitigate / Resolve (timezone):**

## Summary
(2–4 sentences)

## Timeline
| Time | Event | Source |
|------|-------|--------|
| | | |

## Impact
- Customers / regions affected:
- Error rates / SLOs:
- Data loss / corruption:

## Root cause (known vs suspected)

## What went well

## What went poorly

## Follow-ups
| Action | Owner | Due |
|--------|-------|-----|
| | | |
FILE:references/severity-rubric.md
# Severity rubric (default)

- **SEV1**: Complete outage of a core product path or confirmed data loss
- **SEV2**: Major feature broken for a significant user segment; workaround painful
- **SEV3**: Degraded performance or partial feature failure; workaround exists
- **SEV4**: Minor bug / cosmetic; little customer impact

If notes conflict, pick the higher severity and mark confidence as low.