Incident Postmortem is a skill published by agensi that takes raw incident data — Slack threads, PagerDuty alerts, logs, and metrics — and produces a structured, blameless postmortem document. It is designed to assist engineering and SRE teams after production outages, data loss events, or security breaches.

The skill reconstructs a chronological event timeline by consolidating inputs from multiple sources. It then applies the 5 Whys method to move beyond the immediate technical trigger and surface underlying process or architectural gaps. From the same inputs it calculates Time to Detect (TTD), Time to Mitigate (TTM), and total incident duration, giving teams quantified metrics without manual spreadsheet work.

Output is a markdown-ready document structured for two audiences: an executive summary for stakeholders and a detailed timeline with impact analysis for engineering teams. It also generates a prioritized table of action items classified as P0, P1, or P2, each with suggested owners and due dates, focused on systemic fixes rather than attributing fault to individuals.

This skill is appropriate when a team needs to move from raw incident artifacts to a shareable postmortem quickly and consistently, and when maintaining a blameless framing matters. It is not a log aggregation or alerting tool — it processes data that has already been collected and does not connect directly to observability platforms.

Use cases

Convert a chaotic Slack incident thread into a chronological event log

Run a 5-Whys root cause analysis after a production outage

Calculate TTD and TTM metrics from incident timestamps

Generate a P0-P2 action item table with owners and due dates after a security breach

Produce a markdown postmortem document ready for leadership review

Draft a blameless incident report for a data loss event

When to use it

After a production outage where raw data exists in Slack, logs, or alert tools and needs to be synthesized

When a team needs a consistently structured postmortem format across multiple incidents

When blameless framing is a cultural requirement and manual writing introduces risk of blame language

When engineering time spent on postmortem writing is a bottleneck after incidents

When not to use it

When real-time alerting or log aggregation is needed — this skill processes already-collected data

When direct API integration with observability platforms is required; no tool connections are provided

When the incident has not yet been resolved and data collection is still in progress

For non-engineering incident reports such as HR or compliance incidents outside SRE scope