用途
create-postmortem 用于在用户要求撰写事故复盘、记录故障经过、分析事故或进行 5 Whys 分析时，生成一份无责（blameless）的事故复盘文档。其方法遵循 Google SRE 原则，将 5 Whys 根因分析与瑞士奶酪模型（Swiss cheese model）的安全屏障分析结合，强调关注系统性成因，而非寻找单一根因，并统一使用角色而非个人姓名，以维护无责文化。
主要能力
该技能的工作流覆盖事故复盘的完整撰写过程：
- 读取事故上下文：扫描 .chalk/docs/engineering/ 目录中与所描述事故匹配的事故报告，若存在则使用其时间线、影响数据与初步根因作为输入，并检查既有复盘以识别重复出现的模式。
- 解析事故：从 $ARGUMENTS 及关联事故报告中提取发生了什么、发生时间、受影响范围以及如何解决。若细节不足，会进行一轮澄清提问，覆盖时间线、影响范围与解决步骤。
- 校验无责性：撰写前检查所有输入是否包含个人姓名，将姓名替换为角色（如将具体人名替换为“the on-call engineer”）。复盘描述的是系统、流程与决策，而非个人。
- 识别成因：避免指定单一“根因”。多数事故由多个成因叠加导致（瑞士奶酪模型），需识别每一层失败，包括流程、工具、监控、测试、沟通与架构。
- 对每个成因执行 5 Whys：从症状追溯至系统性问题，直到找到可行动且系统性的因素为止，而不是止于某个人的决定。
- 分析安全屏障：依据瑞士奶酪模型记录存在与失效的安全屏障，分类为检测（监控、告警）、预防（代码评审、测试、功能开关）、缓解（回滚、熔断、优雅降级）、沟通（状态页、事故频道、升级路径）。
- 检查复发：在 .chalk/docs/engineering/ 中搜索是否有相似成因的既往复盘或事故报告，若属重复主题则显式标记并引用既往文档。
- 编写行动项：每条行动项必须归类为 Detect、Prevent 或 Mitigate，并带有负责人（角色或团队，而非个人姓名）与截止日期，优先处理最深层系统性问题，而非仅针对直接触发因素。
- 记录做得好的方面：识别响应中有效的部分，如快速检测、有效沟通、成功回滚、团队协作，该部分为必需项。
- 确定下一个文件编号：列出 .chalk/docs/engineering/ 中的文件，找到最大编号并加 1。
- 写入文件：保存至 .chalk/docs/engineering/<n>postmortem<incident>.md。
- 确认：呈现复盘，并附上成因摘要、行动项数量以及复发警告。
复盘文档结构
文档包含以下章节：标题与元信息（事故日期、复盘日期、状态、严重级别、关联事故报告）、摘要、影响（表格：受影响用户、面向用户时长、收入影响、数据影响、SLA 违约）、时间线（统一时区）、成因（每个成因附 5 Whys）、失效的安全屏障（检测 / 预防 / 缓解 / 沟通）、行动项（按 Detect / Prevent / Mitigate 分表，含 ID、行动、负责人、截止日期）、做得好的方面、复发检查。
输出
- 文件路径：.chalk/docs/engineering/<n>postmortem<incident>.md
- 格式：纯 Markdown，无 YAML frontmatter
- 首行：# Postmortem: <Incident Title>
反模式（该技能明确避免的做法）
- 指责性语言：用个人行为归因，改为描述系统失败，并以角色而非姓名指代。
- 单一根因：将复杂系统故障简化为一个根因，应寻找多个必须同时成立的成因。
- 缺少负责人或截止日期的行动项：每条行动项必须同时具备负责人与截止日期。
- 缺少“做得好的方面”章节：只罗列失败会打击团队并抑制事故上报。
- 不检查复发：若曾发生相似事故，最关键的问题是既往行动项为何未能阻止本次事故。
- 浅层 5 Whys：不应止于“因为缺少测试”，而应继续追问测试流程为何未要求该测试。
- 没有跟进落实的复盘：行动项必须跟踪至完成。
适用场景
适用于需要撰写正式事故复盘、进行根因与成因分析、执行 5 Whys、分析安全屏障失效、检查事故复发的工程团队场景，尤其适合采用 Google SRE 无责文化与瑞士奶酪模型的团队。
限制
关于收费、价格、平台支持范围与效果等信息，资料中暂未提供。