用途：对已完成或已停止的目标、会话、变更做回顾性因果分析，回答明确的“为什么”问题。若明确要求阶段性分析，需固定截止点与待查项，结论仅描述该区间，不代表最终结果。相邻概念：尚未执行的计划可能如何失败属于 Premortem；已完成变更是否满足验收属于 Validate。
主要能力与判定标准：把所有因果陈述（含提问者自带的）都当作假设。将“相关”升级为“因果”需同时具备三要素：机制（条件产生结果的具体路径，可供读者对照核验）、区分性证据（机制能预测而至少一个合理替代解释不能预测的观察）、反事实检验（若该说法为假应有何差异，并有引证证据显示确有差异）。事后归因（如“改了 X 后故障停止，所以 X 是原因”）单独不满足以上任何一条，仍只能算相关，需列出仍成立的替代解释并建议可区分实验。建立在未证实原因上的建议，应以实验形式提出。
使用方式：按工作流先固定问题、已接受的意图、对象标识、实际结果与可用判断（精确 id，如提交、检查、消息、已有 verdict），显式记录缺失证据；只重建主张所依赖的时间线，区分已交付行为、失败或停止的工作与流程产出；逐条用上述检查；对时间或 token 主张需说明来源、区间、单位、纳入与排除的对象及不确定性。默认输出简洁的 Markdown 内联结果，含 Question、Inputs、Timeline、Claims、Unknowns、Changes（至多三条或“no change”）。仅在明确要求时，将报告保存为 YYYY-MM-DD-postmortem-<topic>.md 到调用方选定的受保护外部非 Git 存储，缺少路由不得回退到代码仓库。
限制：属于回顾性因果分析，不是通用学习总括，也不是代码验收门槛。既有裁决与原生判断保持不变，不重跑验收，不为复盘编造缺失证明；verdict.v2 是可选证据，其缺失不排除已停止或未验证的对象。调用方拥有后续行动权，本技能不重写证明、不操作跟踪器状态、不改动剩余计划、不重新打开工作、不提升规则。空或不结论性分析有效，必要时可建议不做改动，不制造确定性或教训。质量检查：问题与真实输入已固定且缺口明确；支持与否证的主张都有区分性证据；替代解释、反事实与未知项保持可见；改动至多三条且各自有边界或实验框架；报告不越权到证明、计划、跟踪器与交付。行为示例见 postmortem.feature。