用途：在事故、重大发布或项目结束后开展结构化复盘（postmortem、retrospective），产出可执行的教训而非仅一份文档。适用于任何级别事故之后、每次重大发布之后、项目收尾或冲刺/季度回顾时，以及重复出现的问题需要深入调查、某决策未达预期时。不适用于正在发生的事故（应使用incident-response）、发布前规划（应使用launch-runbook），以及不值得广泛分析的一次性修复。
核心原则：无指责分析。关注系统而非个人，假设每个人在当时所知信息下都做了合理决策；问题不是“谁搞砸了”，而是“为何这个决策当时看起来是合理的”。无指责不等于不追责、不面对硬真相或不设标准，行动项仍需负责人。
六大板块：摘要（2-3段，含经过、影响、根因与重点行动项）；时间线（事故用T-0检测、确认、定级、调查、缓解、解决等节点，发布与项目记录里程碑与决策）；根因分析（可用连续五问法或因果链，多因素导致则多因素并列）；促成因素（监控、文档、流程、工具、知识缺口等“本可更早发现”的因素）；做得好的地方（有效检测、响应、决策与工具流程）；行动项（具体、有负责人、有截止日期、有类型，可关闭）。
工作流：事件后1-2周内安排复盘会议（60-90分钟），会前收集时间线、日志、聊天记录、工单、参与者书面陈述与影响数据；会议由主持人推进，主持人非记录员；会后数天内写出完整文档；在内部可搜索位置分发，高严重度事故可考虑对外摘要；持续跟踪行动项直至关闭，未关闭项在下次复盘中重新浮现。
输出为Markdown文档，命名aar-[date]-[event-name].md，含事件名称、日期、严重度/范围、主持人、参与者，以及摘要、影响、时间线、根因分析、促成因素、做得好的地方、行动项表格与教训等章节。参考文件为references/aar-template.md。
限制：该技能依赖输入数据、测量或工具结果，无法自行生成。所需输入、工具或数据源不可用或无法验证时，应在交付物中明确说明缺口（需要什么、实际获得或验证了什么、影响输出的哪些部分），不得捏造、估算或插值。
常见失败模式：小事故跳过复盘、指责个人、行动项笼统、行动项长期不关闭、走过场式复盘、跳过“做得好的地方”、把责任归给外部、单人完成复盘、只对失败做复盘、拖延太久。