Incident postmortem
Reconstructs a technical incident from timelines, tickets, chats, monitoring evidence, and impact data, then produces a blameless postmortem with causes, gaps, and owned corrective actions. Use for service outages, security incidents, production failures, incident reviews, and lessons-learned reports.
Published Aug 21, 2026 · Updated Aug 26, 2026
Requirements
Add the incident taxonomy, severity policy, and postmortem template. Define impact metrics, timestamp convention, and required time zone. Set action ownership and closure-evidence rules.
Skill document
The full SKILL.md your agent reads and follows.
Incident postmortem
Purpose
Turn fragmented incident evidence into a precise account of what happened, what customers or internal users experienced, why safeguards failed, and which actions reduce recurrence. Keep facts, inferences, and unresolved questions distinct.
Scope
One incident from first signal through recovery and follow-up evidence, including technical and operational contributors. Excluded: assigning blame, changing systems, contacting customers, or declaring legal or regulatory conclusions.
Data basis
- Incident timeline, tickets, chat or bridge transcript, and monitoring extracts.
- Impact measurements such as duration, affected users, transactions, or revenue.
- Postmortem template, severity policy, and prior related incidents.
Result
A postmortem document, an action-item sheet with owners and evidence, and a factual external-summary draft when the source scope supports one.
Quality criteria
- Every timeline event cites its source and timestamp.
- Impact numbers reconcile to the supplied measurements.
- Root cause is separated from trigger and contributing conditions.
- Every action has an owner, target date, and completion evidence.
Instructions
Use neutral descriptions of decisions and conditions. Mark any inferred cause as a hypothesis and list the evidence supporting it. Do not turn silence in the record into proof that a control worked. Preserve uncertainty and conflicting timestamps. Use the severity vocabulary in the incident policy; otherwise state that no policy mapping was available.
The review should make the population, calculation basis, and exception treatment understandable to a second operator. Preserve source identifiers in every working table, and state the effect of missing evidence on the decision. A reviewer must be able to reproduce each material result from the cited rows, clauses, dates, or policy rules. Where two sources disagree, show both values and explain which source was treated as authoritative.
Adapt before use
- Add the company postmortem template and incident-severity policy.
- Define the required impact measures and time zone for timestamps.
- Specify action-owner naming, target-date, and closure-evidence conventions.
- Decide whether an external summary is allowed and which details must be excluded.
Related skills
- Access provisioning checklist
Converts employee roles and lifecycle events into a system-by-system provisioning or deprovisioning checklist with approvals, dependencies, and audit evidence fields. Use for joiner, mover, leaver, role-change, access-request, and identity-control preparation.
- Audit evidence pack
Organizes audit requests into evidence tests, evaluates supplied documents for coverage and period, and produces a traceable evidence tracker with control narratives and gaps. Use for SOC, ISO, internal control, customer audit, certification, and audit-readiness preparation.
- Backup and recovery verification
Checks backup coverage, retention, failures, and recovery-test evidence against system criticality and recovery objectives, then produces a verification report and remediation list. Use for backup audits, disaster-recovery readiness, RTO/RPO reviews, resilience checks, and recurring IT control evidence.
- Change release record
Turns a proposed production change into a structured risk, test, approval, rollback, and verification record with traceable evidence. Use for change management, release readiness, deployment review, CAB preparation, rollback planning, and audit documentation.