用途：在 postmortems/ 目录下撰写一次事件的、可长期保存的无责难复盘。复盘不是状态更新也不是追责清单，而是基于证据重建系统失败模式，并产出有人会真正验证的行动项。同一子系统的复盘之间应相互链接，重复类问题才不会被忽略。
主要能力与约束：知识库是由 OpenKnowledge MCP 管理的 markdown，含 proposals/、decisions/、specs/、postmortems/、guides/。复盘一事件一文件，命名 YYYY-MM-DD-name.md（日期为事件日），模板 id 为 postmortem。范围 markdown 用 exec（exec("ls -A postmortems/")、exec("cat postmortems/2024-03-02-auth-outage.md")）与 search({ query: "..." }) 读取，用 write、edit 创建编辑，用 links 查看链接图；不要用原生 Read/Edit/Grep/Glob/cat 处理范围内 markdown。源码、日志、仪表盘、部署历史与聊天记录在知识库之外，用宿主原生工具读取。
流程：先设置无责难门禁，只写系统与角色不写个人，把人的行为视为当时信息下的合理行为；若用户要求追责式写作，应明确拒绝并重新框定为系统问题。然后收集证据（告警、部署历史、指标、聊天记录、事件时刻的代码配置），时间线每条都要有可指出的来源，无证据的重建需标注。撰写前扫描既有复盘判断是否为重复类。用 write({ document: { path: "postmortems/YYYY-MM-DD-name.md", template: "postmortem" } }) 创建，并填写 Summary / Timeline / Root cause / What went well / Action items。总结先写用户可见影响再写原因；时间线标注时间戳、证据，并明确检测与缓解时点及其差距；区分表象、触发因素与根因；列出放大影响或延迟检测的促成因素；诚实写出做得好之处；行动项要有责任方（角色或团队）、真实日期与可验证的完成条件，并分为预防、缓解、检测三类；指南型行动项可先生成 runbook 存根。最后补充 Related 链接，更新目录索引，并用 audit({ path: "postmortems/YYYY-MM-DD-name.md" }) 校验至无违规与断链。
限制与未提供项：具体定价、平台、效果数据以及官方集成细节暂未提供。