用途：在事故解决后按框架模板执行无责事后复盘。建议在解决后48小时内撰写，此时日志、面板与当事人记忆尚未衰减。要求无责表述，只写机制不写人；例如“告警被路由到夜间无人查看的频道”可写，“值班工程师漏看告警”不可写。状态字段用模板自带的 Status 跟踪：填写中为 Draft，完成后为 In Review，签核后为 Complete。
工作方式：逐节填写 resources/postmortem.template.md，使用其中原有标题，不另造平行标题。时间线从证据（日志、部署历史、告警触发时间、面板）还原，每行注明来源，凭记忆的描述不作为条目。根因用五问法追到机制（缺失的检查、未测试的路径、从未存在的告警），停在流程或系统原因。若某项贡献因素写作“人为错误”，改写为让错误得以通过的缺口。影响部分先在用户影响与业务影响表中填真实数字再写文字，未量化的影响会削弱行动项的依据。每个行动项必须有负责人、截止日期与跟踪 issue 链接，三者不得留空。预防措施按要求把根因中识别的触发条件做成测试、告警或 hook，在 enforcement ladder（prose rule < skill < hook < CI）上选择能支持的最强一级，可阻断复发的 hook 或 CI 检查优于没人重读的文字提醒。产出归档到 artifacts/postmortem_[incident-id].md。
交接：每个行动项开一个 GitHub Issue（或写入 ISSUES.md）并在 orchestrator 任务列表登记，不把整份复盘打包成一个 issue。需要设计工作的系统性修复走 /swarm-plan。行动项的 Tracking Issue 列与 issue 互相链接，双向可验证才算交接完成。相关技能：testing、swarm-coordination。