conducting-post-incident-lessons-learned

conducting-post-incident-lessons-learned 技能概览

这个技能能做什么

conducting-post-incident-lessons-learned 技能帮助你在事件恢复完成后，进行结构化的事后复盘。它面向 Incident Response 团队，目标是把一次事件转化为可落地的改进：更清晰的时间线、更准确的根因分析、可衡量的行动项，以及对 playbook 的更新。

适合谁用

如果你是 IR 负责人、SOC 分析师、安全经理，或者负责 after-action review 的主持人，就适合使用 conducting-post-incident-lessons-learned 技能。它最适合你已经掌握 incident 数据，并且需要一种可重复的方法来记录发生了什么、哪些地方有效、哪些地方必须改变的时候。

为什么值得安装

这不只是一个普通 prompt。仓库里包含报告模板、详细 workflow、标准参考资料，以及用于指标计算和报告生成的 scripts。相比一次性的“写一份 postmortem”提示词，conducting-post-incident-lessons-learned 技能更适合投入实际运营，尤其是在你需要跨事件保持一致性的时候。

如何使用 conducting-post-incident-lessons-learned 技能

安装并打开正确的文件

使用以下命令安装：

npx skills add mukul975/Anthropic-Cybersecurity-Skills --skill conducting-post-incident-lessons-learned

然后先读 SKILL.md，再看 references/workflows.md、assets/template.md、references/standards.md 和 references/api-reference.md。如果你计划自动化数据收集或报告生成，在提示该技能之前，先检查 scripts/process.py 和 scripts/agent.py。

这个技能需要什么输入

要把 conducting-post-incident-lessons-learned 用好，请提供完整的 incident packet：incident ID、类型、严重等级、发现时间、遏制时间、恢复时间、时间线事件、涉及团队、沟通记录，以及已知缺口。这个技能在事件已经完全解决、并且你的记录基于事实而非推测时，效果最好。

怎样提示才更有效

把模糊请求改成运营级 brief。不要只说“总结这个事件”，而是明确要求：一份无责备的 lessons-learned 报告、一张时间线表、响应指标、根因分析、带负责人和截止日期的行动项，以及与实际失效点对应的 playbook 更新。对于 Incident Response 场景下的 conducting-post-incident-lessons-learned，还要说明你要的是领导层摘要、技术复盘，还是完整的主持人草稿。

实用工作流与质量检查

先使用 assets/template.md 里的模板，填入时间戳和指标，再按 references/workflows.md 的流程组织会议或复盘。把输出与 references/standards.md 中的标准对照，确保复盘保持无责备、聚焦改进。如果报告遗漏了负责人、截止日期或发现缺口，在对外分发之前，先让该技能修订这些部分。

conducting-post-incident-lessons-learned 技能常见问题

这只适合成熟的 Incident Response 团队吗？

不适合只限定在成熟团队。conducting-post-incident-lessons-learned 技能也适合小团队，因为它提供的是一套可重复的结构。关键在于你是否有足够的 incident 数据可供复盘；要发挥它的价值，并不需要完整的 GRC 项目。

它和普通 prompt 有什么不同？

普通 prompt 通常只会生成叙述性总结。conducting-post-incident-lessons-learned 技能更适合进行真正的 post-incident review，因为它支持完整工作流：指标采集、时间线回顾、根因分析和行动跟踪。这样一来，当输出不仅要“留档”，还要推动变化时，它会更可靠。

什么情况下不该用？

不要在处置仍在进行、或者 incident 还没解决时使用它。如果你没有时间线、没有参与者，或者对行动项没有后续执行路径，它也不太合适。在这些情况下，先补齐数据，或者改用更轻量的 incident recap prompt。

它符合标准安全框架吗？

符合。参考内容对齐了 NIST SP 800-61、SANS PICERL、ISO 27001 持续改进，以及无责备的 post-incident 实践。这让 conducting-post-incident-lessons-learned 技能很适合那些需要证明流程改进，而不只是保留内部笔记的团队。

如何改进 conducting-post-incident-lessons-learned 技能

提供更强的证据材料

质量提升最大的来源，是更好的原始材料。请提供按时间顺序排列的 timeline、真实时间戳、告警样本、分诊记录，以及最终 remediation 清单。如果你只给一段短摘要，conducting-post-incident-lessons-learned 技能仍然能工作，但根因部分和指标部分会明显变弱。

让输出更便于决策

直接要求能帮助审阅者行动的结果，例如：“按风险降低幅度给行动项排序”、“把流程、人员和技术层面的修复分开”、“把每条 lessons 映射到对应的 playbook 更新”。这类指令会比泛泛地要求一份 retrospective，更能产出有用的 conducting-post-incident-lessons-learned 使用结果。

注意常见失败模式

最常见的问题，是把事实和猜测混在一起。另一个常见问题，是行动项过于空泛，比如“改进沟通”或“加强监控”。要推动技能明确写出负责人、截止日期和可衡量的成功标准，这样复盘会后才可以持续追踪。

基于第一版继续迭代

先用第一版输出找出缺口，再结合缺少的材料、有争议的时间戳，或者更窄的受众范围重新运行该技能。如果领导层需要更短的版本，就要求 executive summary；如果 IR 团队需要执行细节，就要求 technical annex。这样的迭代循环，是从 conducting-post-incident-lessons-learned 技能获得更好结果的最快方式。